Ontogrammatic System — skill

A pattern and runnable validator for systems where generated artifacts pile up faster than the chain that justifies them. The fix: every artifact carries its formation trail; the Axiomatic Machine certifies admission; the field grows by admission, not by output.

This skill is loadable by Claude Code (or any agent that consumes SKILL.md). Loading it makes the operational reference, the runnable substrate, and the Cardinal application addressable in a single context.

When to fire

• A new typed artifact kind is being introduced (skills, contracts, eval results, generated docs, agent outputs, canon proposals).
• A generator is shipping without a certifier — anything that produces records the system can't later audit.
• The system has grown surface area but trust has degraded (the "ontogram landfill" symptom).
• A reviewer asks "where did this come from and what does it now obligate?" and the system can't answer.
• Working on Cardinal canon proposals, refinements, or admits.
• Designing LLM-system infrastructure that needs evals, rubrics, or admin dashboards as first-class typed forms rather than bolt-ons.

What this skill does

1. Names what the source events are for the artifact kind (file appeared, request arrived, contradiction surfaced, operator action).
2. Authors a contract per kind: required schema, gate condition, declared propagation, forbidden forms, acceptable inference grades.
3. Runs the Axiomatic Machine (ontogrammatic/machine.py) against a candidate ontogram + applicable contracts. Seven CHECK_OPS, three verdicts, per-check receipts.
4. Persists admitted ontograms to the Field (ontogrammatic/field.py) — a directory of YAML files under cycles/.
5. Runs the scaling smell-test (ontogrammatic/smell.py) against the field to catch landfill before it accumulates.
6. Renders a dashboard (ontogrammatic/dashboard.py) — a read-cut of the field.

Operational shape

ontogrammatic-seed/
├── README.md                          ← entry point and hypothesis
├── SKILL.md                           ← this file
├── Makefile                           ← make demo / make test / make dashboard
├── pyproject.toml                     ← Python 3.10+ package
├── ontogrammatic/                     ← the substrate package
│   ├── core.py                        ← Ontogram, Contract, Operator, trust axes
│   ├── machine.py                     ← Axiomatic Machine, 7 CHECK_OPS, demo
│   ├── field.py                       ← Field as files-on-disk
│   ├── session.py                     ← Sessions as typed ontograms
│   ├── smell.py                       ← Runnable landfill smell-test
│   ├── dashboard.py                   ← Read-cut of the field
│   └── promptwriter/                  ← Phase 3 stub — the 4.0 case
├── cli/                               ← curl-shaped CLI surface
│   └── __init__.py                    ← open/record/close/replay/ask/dashboard
├── contracts/
│   ├── core/                          ← session.yaml, operator.yaml
│   ├── llm/                           ← eval.yaml, rubric.yaml
│   └── cardinal/                      ← canon_proposal.yaml, canon_admit.yaml
├── cycles/                            ← admitted ontograms land here (the Field)
├── tests/                             ← substrate + Cardinal acceptance
├── settings/cardinal/                 ← Cardinal setting source material
└── docs/
    ├── PATTERN.md                     ← operational reference
    ├── deep-scope.md                  ← stable theory layer
    ├── experiment.md                  ← 4.0 hypothesis, phases, acceptance tests
    └── worldbuilding.md               ← Cardinal application

Quickstart

make install     # set up the venv
make demo        # run the three Machine examples (admit / reject / needs_instrumentation)
make test        # run all tests, including Cardinal acceptance
make dashboard   # print a read-cut of the field
make smell       # run the landfill smell-test

make demo is the smallest verifiable thing the substrate does. If it doesn't produce three correct verdicts with receipts, nothing else in the system can be trusted.

What this skill is not

• Not a world model, schema registry, ontology, or provenance-only system. It records origin and the active obligations an artifact's existence creates. (Full reasoning in docs/PATTERN.md §7, "Not this.")
• Not a generator. It certifies; the generation is your job.
• Not opinionated about your domain. The seven-element cycle and the Axiomatic Machine are domain-agnostic; the contracts are yours to author.
• Not a finished framework. It is a discovery experiment with a failure-soft floor. See docs/experiment.md.

The two trust axes

Every ontogram carries authorship (authored vs programmatic) and inference_grade (deterministic through deliberation). The two are orthogonal. The Machine's inference_grade_acceptable check enforces what grades each contract will admit. Cardinal's canon-admit contract refuses programmatic-creative admits; LLM-eval contracts accept any grade.

The Cardinal proof case

docs/worldbuilding.md explains why worldbuilding is the substrate's stress-test domain. The short version: trust degrades fast, the failure is structural, there's no underlying compiler. If the discipline survives worldbuilding-with-AI, it survives anything.

Real Cardinal material lives in settings/cardinal/ and tests/test_cardinal_*.py. Phase 2 of the experiment is "make those tests pass with real Cardinal material."

Failure mode to watch

Ontogram landfill: surface area grows but the formation trail does not. Records exist; the relationships between them do not. Downstream consumers can't tell which artifact obligates which, so they treat all artifacts as equally weighted noise. The system reverts to fog.

Run the smell-test regularly: make smell. Exit code 0 if clean; nonzero if warning or landfill.

For agents loading this skill

If you are a coding agent (Claude Code, Cursor, etc.) loading this skill to work on the package:

1. Read docs/experiment.md once. It names what success and failure look like.
2. Read docs/PATTERN.md for operational reference.
3. Load docs/deep-scope.md only when a coherence strain needs the justification revisited.
4. Treat your own outputs as ontograms. Your formation trail (which file you read, what you proposed, what was admitted) is part of the discipline operating on its own delivery.
5. If you find yourself "improving" the substrate beyond what Phase 2 or Phase 3 require, pause. That drift is the failure mode the discipline names.