A method for turning any implementation objective into a verified solution, by naming, forming, reversing, and comparing until no friction remains.
The process rests on two concepts from ancient philosophy, repurposed as engineering primitives.
Saṃskāra (संस्कार) — accumulated formations. Everything you know about a domain, consciously and unconsciously, gathered from experience. When you hear a word like "hangman" or "authentication," your saṃskāra is everything that word activates — every game you played, every system you built, every pattern you absorbed. Saṃskāra is finite, shaped, informed.
Ápeiron (ἄπειρον) — the boundless. The infinite field from which all saṃskāra is gathered. It is never diminished. Every formation ever gathered by anyone is drawn from it, and it remains whole. Ápeiron is the precondition — there must be a boundless field for the process to draw from. Saṃskāra is what you bring back from it.
The process is how saṃskāra becomes form.
There is one equation:
𝑃 → 𝑛(𝑎) → 𝐹
Potential → Naming (annotated) → Form.
This equation can be applied in three directions. They are not three separate processes — they are three views of the same transformation:
- Making looks forward: from potential to form.
- Revealing looks inward: from form back to potential.
- Originating looks through: from accumulated formations to what they enable.
These three views correspond to the Nama-Rupa Triptych:
I. Making: 𝑃 → 𝑛(𝑎) → 𝐹
II. Revealing: 𝐹 → 𝑛(𝑎) → 𝑃(𝐹)
III. Originating: ∑ → 𝑛(𝑎) → 𝐹′
The output of each is the input of the next. The cycle is a virtuous circle — each pass enriches the accumulated formations (∑), and richer formations enable deeper naming.
The three views are inverses. What one constructs, another deconstructs. This reversibility is what drives the process:
After applying the equation forward (Making), apply it in reverse (Revealing). Compare the result with the original input. The delta — what the reverse finds that the forward didn't name — is friction. The friction points to what must be named next.
After Revealing accumulates into ∑, apply the equation through (Originating). Compare the originated forms with the existing forms. The delta is friction again. When a round trip produces no delta, the cycle is complete.
The process does not require a plan. It requires only the ability to name, form, reverse, and compare. The mismatch between directions is the compass.
A word — the implementation objective. "Hangman." "A baby learning to walk." "An authentication service." The word is the key into saṃskāra — it activates everything you know, consciously and unconsciously, about what that word means.
Each name carries a promise. The annotation classifies what kind of promise:
| Annotation | Promise | How verified |
|---|---|---|
| Inert | It is what it is | Schema validation |
| Resolvable | It points to something real at runtime | Resolution test |
| Extractable | It contains hidden promises inside | Parse and verify each |
| Composable | It only means something in combination with others | Test the combination |
| Accruing | It builds over time through repeated interaction | Reflects accumulated history |
This vocabulary expands. When you reach for an annotation and none fits, the friction of that failure tells you a new annotation is needed. Name it. Add it. Continue. The vocabulary grows through use, not through design.
Five artefacts, created once, mutated in place throughout the process:
Manifest — the names. Every name, its annotation, and the promise it carries. This is 𝑛(𝑎). It is the single source of truth. Every name in the manifest must have all four forms.
Model — the shared core. The hub of the architecture. Every name in the manifest has a corresponding implementation here — a property, method, class, or attribute. Both the solution and the contracts depend on the model. It is the testable, importable expression of the names.
Solution — the deliverable. The thing the user asked for — an animation, a game, a service, whatever form the word demands. The solution imports from and uses the model. It does not reimplement the model's logic. If the model changes, the solution reflects the change.
Contracts — the proof. Tests that verify every promise in the manifest holds. The contracts import from the model and test it directly. They are coupled to the model — this ensures the same core that the solution uses is the core that the contracts verify.
Narrative — the story. A coherent account of what the solution is, what it promises, and why it holds together. Not an appendix. Not per-phase documentation. One story, rewritten with each pass to incorporate the full understanding so far.
The model is the hub. Everything flows through it:
Manifest
│
▼
Model ◄── the shared truth
╱ ╲
▼ ▼
Solution Contracts
(uses it) (tests it)
╲ ╱
▼ ▼
Narrative
(describes it)
This architecture enforces coupling. The solution cannot drift from the model because it imports from it. The contracts cannot test a phantom because they import from the same model. If the model is correct (contracts pass) and the solution uses the model, the solution is built on verified ground.
1. NAME
From P, name what you know.
For each name, annotate with the kind of promise it carries.
If no annotation fits → expand the vocabulary.
Add names to the manifest.
2. FORM (in this order)
a. Model — implement all names from the manifest.
b. Contracts — write tests for all names; import from model.
c. Run contracts. All must pass.
If contracts fail → fix and rerun. Do not proceed until green.
d. Run coverage on model. Must meet minimum threshold (80%).
If coverage too low → add tests and rerun. The count drives the loop.
e. Solution — write the deliverable; import from and use the model.
f. Lint the solution. Error count must be 0.
If lint errors → fix and rerun. The count drives the loop.
g. Narrative — rewrite the story to include all names.
The order matters. The model is written first because it is the hub.
Contracts verify the model before the solution is built on it.
Coverage ensures contracts actually exercise the model — not just pass.
Lint ensures the solution is valid — not just present.
The solution is built on proven ground. The narrative describes the whole.
Counts drive loops: error count, coverage percentage, missing names.
The AI does not self-assess. The tools measure. The numbers decide.
3. CHECK COMPLETENESS
For every name in the manifest, verify all forms exist:
- Does the model implement it?
- Do the contracts test it?
- Do the contracts import from the model? (coupling)
- Does the solution exist and use the model? (coupling)
- Does the narrative mention it?
If any form is missing for any name → friction.
Do not proceed. Fill the gap first. Return to step 2.
4. REVERSE
Apply the equation in the other direction.
Take F (the model) and ask: what potential does this form carry
that is not yet named in the manifest?
5. COMPARE
The delta between what the manifest names
and what the reverse reveals = friction.
6. DECIDE
If friction exists → the delta becomes the new P.
Go to 1.
If no friction → done.
Repeat until the comparison yields no delta. The process is complete when the round trip — form to potential and back — produces no new information.
The process must be driven by a program, not relied upon to be followed by an AI or a human. The lesson: an AI will skip steps, forget artefacts, and drift from the sequence. A human will do the same. The fix is to separate the orchestration from the creativity.
The program owns the sequence. It decides what step to run next. It verifies each step was completed before advancing. It runs the contracts. It checks completeness. It compares the delta. It decides whether to loop or stop.
The AI owns the creative acts. It names. It writes the model. It writes the solution. It writes the contracts. It writes the narrative. It examines the form for unnamed potential.
The program verifies before proceeding. After each AI task:
- Did the expected file appear?
- Is the file valid? (parseable YAML, runnable Python, non-empty markdown)
- Do the contracts pass?
- Is the coupling intact?
- Is the completeness satisfied?
If verification fails, the program re-requests. The AI cannot skip a step because the program will not advance without verification. The AI cannot forget an artefact because the completeness check will catch the gap.
The flow:
┌─────────────────────────────────────────┐
│ Process Runner (program) │
│ │
│ 1. NAME → [AI: name from P] │
│ ← verify: manifest valid │
│ │
│ 2. FORM │
│ a. Model → [AI: write model] │
│ ← verify: file exists │
│ b. Contracts → [AI: write tests] │
│ ← verify: file exists │
│ c. Run tests ← programmatic │
│ if fail → [AI: fix] → rerun │
│ d. Solution → [AI: write solution] │
│ ← verify: file exists │
│ e. Narrative → [AI: write story] │
│ ← verify: file exists │
│ │
│ 3. CHECK ← programmatic │
│ model implements all names? │
│ contracts test all names? │
│ contracts import model? (coupling) │
│ solution uses model? (coupling) │
│ narrative mentions all names? │
│ if gaps → [AI: fill] → recheck │
│ │
│ 4. REVERSE → [AI: find delta] │
│ ← verify: valid YAML │
│ │
│ 5. COMPARE ← programmatic │
│ delta empty? │
│ │
│ 6. DECIDE ← programmatic │
│ if delta → go to 1 │
│ if empty → done │
└─────────────────────────────────────────┘
The AI never decides what step to run next. The AI never self-verifies. The program drives. The friction drives the program.
The three proofs are not separate phases. They are what happens naturally when the process runs:
-
First pass through steps 1–6 = Making. You name what you consciously know, give it form, and verify.
-
Step 4 after Making = Revealing. You reverse the form and discover potential that was always there but not named. The delta between what you named and what the form reveals is the friction.
-
Step 1 of the next pass uses the accumulated ∑ from Making and Revealing = Originating. New names emerge that could not have been conceived without the prior formations.
-
Step 4 after Originating compares again. If there is still friction, the cycle continues. If not, the circle is complete.
The cycle terminates when the saṃskāra for the given word is fully articulated — when the round trip reveals nothing new. Simple domains (like hangman) may complete in one cycle. Rich domains may take many.
Friction appears in several forms:
-
Annotation friction: you reach for an annotation and none fits. → Expand the vocabulary.
-
Completeness friction: a name exists in the manifest but is missing a form — not in the model, not tested, not in the solution, or not mentioned in the narrative. → Fill the gap before proceeding. The missing form is the pointer.
-
Coupling friction: the solution does not use the model, or the contracts do not import from the model. The artefacts have drifted apart. → Re-couple. The model is the hub. Everything goes through it.
-
Contract friction: a test fails. → The promise and the form disagree. Fix the form or fix the promise.
-
Comparison friction: the reverse reveals names the manifest doesn't have. → Add them. The delta is the new potential.
-
Narrative friction: the story cannot coherently include a new name. → The name may be wrong, or the story needs restructuring.
In all cases, friction points the way. The process does not require a plan. The friction drives it. The absence of friction stops it.
At any point, the state of the process can be verified by checking:
For every name in the manifest:
- Does the model implement it?
- Do the contracts test it? (and do they pass?)
- Do the contracts import from the model? (coupling)
- Does the solution use the model? (coupling)
- Does the narrative mention it?
If all five hold for all names, the artefacts are in sync. If any is missing, that gap is friction — and friction points the way.
The process is complete when:
- All contracts pass.
- The reverse yields no new names.
- The model implements every name in the manifest.
- The solution uses the model and is a working deliverable.
- The contracts test the model and are coupled to it.
- The narrative tells a coherent story that includes every name.
- The annotation vocabulary is sufficient — no friction when annotating.
At that point, the five artefacts — Manifest, Model, Solution, Contracts, Narrative — are the deliverable. Together they are the answer to the word that started the process.
The runner/ directory contains the process orchestrator — the program that
drives the sequence deterministically while handing off creative acts to an AI.
Three approaches to LLM interaction were explored:
-
namarupa.py— stdout piping. The runner communicates with Claude via stdin/stdout, reading and writing directly. This is the primary runner. Fast, reliable, and the approach that works. -
auto.py— Claude CLI invocation. The runner callsclaudeas a subprocess for each step. Abandoned: too slow due to CLI startup overhead on every invocation. -
api_namarupa.py/api_model.py— OpenAI/Google API calls. The runner calls the API directly with multi-provider support. Abandoned: API latency made the iterative loop impractical compared to the stdout approach.
The lesson: the fastest path between the program and the AI is the simplest one. Pipes beat APIs when the loop is tight.
Three solutions are included in solutions/, each demonstrating a
different aspect of the process.
-
sliding-puzzle-3 — a human-conventional framing. The puzzle is described in familiar terms: a 4x4 grid, numbered tiles, adjacency, solvability. Competent, correct, and humanly conventional.
-
sliding-puzzle-5 — an AI-originated framing. When given freedom to name, the AI centered the single empty space rather than the numbered tiles. The model is built around
blank_position, deriveslegal_movefrom absence, and organizes the problem around the mobility of the gap rather than the movement of numbered objects.
The contrast between these two is the point. Same objective, same process, different naming — and the difference in naming produces a different conceptual architecture. This is what the methodology enables when the AI is not caged by imposed naming.
- solar-system — an animated solar system that demonstrates the process working in reality, with gaps.
The Revealing pass found four names that were implicit in the model but
unnamed: collision_immunity, coplanarity, perpetual_motion, and
initial_alignment. These were added to the Manifest — exactly the kind
of surfacing the reverse pass is designed to produce.
But the contracts didn't fully catch up. Those four Revealed names appear in the Manifest but are absent from the Contracts. The completeness check should have enforced this. The Narrative also overstates the scale property — saying "proportional to real values" where the implementation only preserves monotonic ordering.
These gaps are included deliberately. The sliding puzzle demonstrates the process working cleanly. The solar system demonstrates the process working in reality — with a Revealing pass that found real friction, and a contracts layer that didn't fully close the loop. That is what actual development looks like.
The imperfection is the proof. A reader who only sees clean examples might reasonably wonder if the methodology was reverse-engineered to fit a known good solution. The solar system answers that question.
Each solution contains all five artefacts: manifest, model, contracts, solution, and narrative.
The ideas behind this methodology are explored in detail at:
- We Do Not Create from Nowhere — the condensed argument, with the sliding puzzle example
- We Do Not Create from Nowhere: The Full Argument — the extended version, from Potential to methodology
One equation: 𝑃 → 𝑛(𝑎) → 𝐹
One input: a word.
One ground: ἄπειρον — the boundless from which saṃskāra is gathered.
Five artefacts: manifest, model, solution, contracts, narrative.
One architecture: model is the hub; solution uses it, contracts test it.
Six steps: name, form (in order), check completeness, reverse, compare, decide.
One driver: friction.
One stop condition: no friction.
One executor: a program that drives the sequence deterministically, handing off to the AI only for creative acts, and verifying before proceeding.