Structure the product richly and the process minimally, because a wrong schema refuses and a ceremony becomes the subject
Wildo puts its structure into the thing being built and keeps it out of the way the thing is built. The product model is typed down to the reference: every family has a schema, a validator, and a cross-family report. The process that produces it is deliberately loose: no digests, no acceptance ledger, no sealed records, no ceremony an operator must complete before their own edit counts. Safety comes from the artifact schemas, the family validators, the application’s own TypeScript build and the coherence report, never from constraining what an agent may try. Acceptance is a git commit, and a commit is something a person can read, diff and revert.
The problem it answers
A schema is a commitment, and that is exactly why it is dangerous in the wrong place. Prose that is wrong is merely misleading; a schema that is wrong refuses, and what it refuses first is legitimate work. If a structured model is good, the temptation is to conclude that a structured process must be better: seal every artifact, checksum every record, refuse anything that does not match its manifest. Taken far enough, the ceremony becomes the subject. Wildo’s own history records that failure: an earlier design over-structured the process while the product model went unbuilt, and the digests, receipts, preconditions and acceptance protocols it accumulated ended up refusing correct work. Sixteen files whose working tree was clean once required an operator ceremony because a ledger disagreed with the filesystem. Nothing was wrong with any of them.
The distinction that decides everything is between two things both called validation:
| Keep | Delete | |
|---|---|---|
| Content validation: does this artifact say something coherent? | yes | |
| Bookkeeping validation: does my ledger agree with the filesystem? | yes |
Content validation is what caught a generated market snapshot that was schema-valid and still carried a large number of references to entities that did not exist, which is why that snapshot had never once produced a usable result. Bookkeeping validation is what asked a human to re-accept bytes that were already correct. If a refusal’s remedy is “re-accept something that is already right”, it is bookkeeping, and it goes.
What it rules in, and what it rules out
- Validation happens at four points, and all four are about content. At generation, where the provider is constrained by the family’s Zod schema and cannot emit the wrong shape. Before a generated value becomes a file, where the family validator checks that the artifact’s parts agree with each other. On rejection, where the validator’s findings go back to the model verbatim and drive the next attempt, within a bounded number of attempts. For code, where the application’s own TypeScript build is the floor. Rejected: a fifth point that checks the process itself.
- Git is the only accepted state. A specification is a file; a committed file is accepted; an uncommitted file is a working edit. Rejected: a manifest, a journal, an acceptance record or a digest naming what was accepted. None of them can merge across two branches, and all of them describe the branch you just left.
- No digests, of any kind, for any purpose. Rejected: content-addressed artifact identities, head-set digests, basis pins, compare-and-swap preconditions on a journal. Each was built, each grew into the ledger it was meant to avoid, and the operational test that now governs any proposal is whether two branches can carry different versions of it and merge.
- Reports, not refusals, for the questions that admit deliberate answers. The coherence report computes coverage gaps and dangling references and hands them to a human. Rejected: promoting a report row into a gate. A criterion deliberately deferred is a gap and is correct.
- Records are written only if something reads them. A trace exists for a person to understand what happened; nothing in the system decides from it, and everything stored outside git is disposable. Rejected: sealed evidence, receipts and audit chains for the creation process. They can return when there is an auditor asking for them, against a system that works.
- Mutation is free; protection comes later as a guard, not as a refusal. Landing a generated
file over an authored one replaces it, because the recovery is one
git checkoutof the path. Rejected: refusing to overwrite. Every such refusal shipped became an acknowledgement a caller had to thread through.
What it means for someone building with Wildo
- Your specifications package is an ordinary set of TypeScript files in your repository. There is
no side database recording which of them are “accepted”.
git statusis the answer. - A generated artifact that reaches your disk has already passed its family’s schema and validator. What it has not passed is your judgement, which is why the last step is your commit.
- You can edit a landed family by hand and nothing will ask you to re-accept it. The eligibility board and the coherence report read whatever is in the tree.
- A malformed model output is retried with the validator’s findings, not with a vaguer prompt, and a family that cannot be produced in three attempts is reported as a schema or prompt problem rather than hidden by a longer loop.
- The fully automatic mode in which the system commits on your behalf is described and not built. Until it is, acceptance is yours.
For engineers
Where it lives in the framework
- Schema-constrained generation.
PlaybookStructuredGenerationPort.generatereceives the family’s Zod schema alongside the composed prompt, so the provider constrains the output instead of the prompt asking politely for a format. The run generates every declared output first and lands none until all validate, so a failed third output never leaves two half-written files. - Family validators. Each family under
_coreships a*-validation.ts. The market snapshot validator is a pure typed graph walker with a rule table of eighteen issue kinds, orphan references first among them; the domain plan validator enumerates ten issue codes, from a resource with no main owner to a relationship whose endpoints are not in the inventory. Shared structural assertions for the definition-backed families live indefinition-specification-validators.ts, each stamping the exact field path that failed. - The retry that carries findings. Rejections are fed back to the model as that attempt’s findings, so each attempt is a different request, up to three per output; a family still failing after two findings-guided repairs is a prompt or schema problem, and looping harder would hide which. Validation runs twice on purpose: once so the rejection can become a retry, and again inside the landing gate, so the retry loop could be deleted and nothing invalid would reach the disk.
- The landing gate.
landApplicationSpecificationArtifactparses the value against its render profile’s schema, refuses a target path outside the specifications package, writes the file, and stops. Its own source lists what it deliberately lacks: no digest, receipt, manifest entry or authority record; no commit; no acceptance ceremony. It replaced roughly three thousand lines of staging, preview, echo and protocol whose combined effect was to move bytes into a machine-local manifest. - Eligibility from the working tree.
PlaybookArtifactStateholds what the application exports for each family, read from the tree; its contract states that nothing consults a ledger, a journey record or an accepted manifest, because none exists. - The coherence report as the cross-family check. The family validators can resolve
cross-family references only when handed a reference set, so
buildApplicationCoherenceReportis where those checks actually run. It reports; it never gates. - Acceptance as a commit. The three autonomy modes (guided, light automatic, fully automatic) are described in the journey schemas as authored intent with no runtime reader. Today the runtime writes files and a human commits them; nothing in the runtime performs a commit.