Reference

Generalized Patterns

On this page

1 Durable state and work record
2 Decomposition and work units
3 Contracts and obligations
4 Verification and acceptance
5 Configuration control
6 Traceability and lineage
7 Decision records
8 Risk and failure
9 Boundaries and enforcement
10 Governance documents and layout
11 Roles, authority, and human checkpoints
12 Reusable procedures and document skeletons

The Generalized Patterns are the 79 structural forms that the research adopted from engineering practice. Each clause of the Normative Structural Specification traces to one or more of them. The tables below put the patterns into 12 families. For each pattern, they give its name, a summary of its mechanism, and the clauses that realize it.

1 Durable state and work record #

Pattern	Name and summary	Realized in
GP-01	Versioned execution plans as the system of record Plans and all other state that direct the work are kept as versioned files; an instruction outside those files has no force.	§4.1, §4.2, §4.6
GP-02	Verify-and-record iteration discipline Each pass reads the record, finishes one bounded unit, checks it, and writes the checked result back before the next pass starts.	§4.2, §4.7
GP-03	The binding work-unit document One document for each work unit states both the rules to follow and the work that remains, and it overrides spoken instructions.	§4.6
GP-04	Structured work record over fragile prose Dependent work is tracked in one structured record that can be queried, because an agent loses its memory between sessions.	§4.5
GP-05	Typed dependencies and derived readiness Each dependency has a declared type, and a unit is ready to start when no blocking dependency remains.	§4.5
GP-06	Documents as the sole coordination medium Agents coordinate only through shared, durable documents and never through hidden shared state.	§4.1

2 Decomposition and work units #

Pattern	Name and summary	Realized in
GP-07	Product-anchored decomposition with a dictionary The breakdown follows what the project delivers, not who does the work, and a dictionary defines each element.	§5.1
GP-08	Purpose-defined units with owner and binary verification Each unit states the need it serves, and one place holds its obligations, its owner, and a pass-or-fail check.	§5.2
GP-09	System-level contracts before component detail Interactions across the system and contracts at its boundaries are fixed first; the inside of each component comes after.	§5.3
GP-10	Work-unit sizing Each unit fits one bounded effort by one agent; a unit that is too large is split before work starts.	§5.5
GP-11	The verifiable task as the unit of work A unit of work is a bounded task that ends in an outcome that can be checked, not an activity or a period of time.	§5.7
GP-12	Blast-radius-bounded work units Before work starts, the area that each unit can affect is estimated, and units that run in parallel must not overlap.	§5.6
GP-13	Nested levels of intent, each with acceptance criteria Intent is nested in levels; each level has its own acceptance criteria, and the top level holds the purpose.	§3.1, §3.3, §5.8
GP-14	Milestone decomposition with repair-before-progression Long work is cut into milestones; a milestone must pass its checks, with failures repaired, before the next one starts, and the specification stays frozen.	§5.9
GP-15	Numbered design generations Each major redesign becomes a numbered generation, identified by declared changes to a few tracked parameters.	§9.6
GP-16	Four recursive process groups Four recursive process groups, which include contract agreement and verification, are the test for a complete project structure.	§1.2, §1.4

3 Contracts and obligations #

Pattern	Name and summary	Realized in
GP-17	Specification-first, self-contained contract before execution A complete, self-contained contract exists before work starts, and writing the contract is a separate step from doing the work.	§6.13
GP-18	Human-approved plan gate Work starts only after a human reviews, edits, and approves the plan; no change is permitted until then.	§6.13
GP-19	The specification is the durable alignment artifact Alignment and change are managed in the specification, and the realization follows from it.	§6.4
GP-20	Unique, verifiable obligation statements Done means that every statement in an approved set of commitments is met; each statement is unique, measurable, has a declared check, and traces up and down.	§6.5, §16.2
GP-21	Fixed structure for obligation statements Each obligation states one commitment in a fixed sentence form, so it can be checked and has one meaning.	§6.5, §16.2
GP-22	Obligation hierarchy with fixed record attributes Obligations form levels that match the decomposition, and each carries the same fixed attributes: owner, reason, and verification method.	§6.6, §6.17, §16.2
GP-23	Named owner for every obligation Each obligation names one accountable person, so someone can be asked to justify it.	§6.7, §16.2
GP-24	Constraint provenance marking Each constraint is marked as imposed from outside or set by the project; the mark tells whether it can be challenged.	§6.8, §16.2
GP-25	Verification method assigned at authoring An obligation enters the baseline only when its verification method is declared.	§6.9, §16.2
GP-26	One fixed lens for every interface Every interface is described in the same fixed form: what crosses it, in which terms, and who can change it.	§6.10
GP-27	Public contract, private design, co-updated realization Each component shows a public contract and hides its design; an agent sees only its own contract and its neighbors' contracts; specification and realization change together; and approval authority grows with the reach and irreversibility of a change.	§6.3, §6.15, §6.16, §7.19, §9.2, §15.3
GP-28	Adversarial expansion of the contract Before acceptance, adversarial cases are generated against the contract, and the contract is approved in its expanded form.	§6.14
GP-29	Named key design parameters, no added coordination roles A few named design parameters are tracked down to component level, and the agent doing the work keeps structural authority instead of new coordination roles.	§6.18
GP-30	Artifact-gated phase sequence Work moves through fixed phases; each phase produces one durable artifact, and the next phase starts only when that artifact passes verification.	§8.1

4 Verification and acceptance #

Pattern	Name and summary	Realized in
GP-31	Done is a checkable criterion, never self-assessment A human writes the done criterion, a party other than the executor checks it, and the strength of the gate follows the risk.	§7.1, §7.19
GP-32	Verifiability governs what may be delegated Work may be delegated only when its verification can be reset, repeated at low cost, and gives a clear verdict.	§7.3
GP-33	Acceptance check authored before work begins The acceptance check is written first and fails first; the work is done when it passes, and the check then stays to catch regressions.	§7.4
GP-34	Establish the verification baseline before changing anything The existing checks run before any change, and failures that already exist are recorded before new work starts.	§7.5
GP-35	Durable verification corpus Expected behavior is kept as a growing set of named scenarios, each with a checkable assertion, stored with the system description.	§7.6
GP-36	Layered verification mirroring decomposition Verification has layers for component, interface, and system, and the checks at each layer also document the expected behavior.	§7.7
GP-37	Verification correspondence for every decomposition level Each level of the decomposition has a matching level of verification, and the match is explicit.	§7.8
GP-38	Governing verification plan One plan sets the scope, responsibilities, and completion criteria of all verification before it starts, with rigor set by the declared integrity level.	§7.9
GP-39	Recorded criticality class determines rigor A human assigns a risk class from several declared dimensions, and that class sets how much obligation and verification rigor applies.	§1.6, §6.6, §7.10, §7.19, §9.2
GP-40	Generator and verifier are independent The party that makes a work product does not verify it; an independent party verifies it, and a human accepts it.	§7.11, §12.2
GP-41	Acceptance artifacts are inviolable Nobody may weaken the acceptance criteria without authorization; doing so is a named contract violation that supervision looks for.	§7.12
GP-42	Every contract clause linked to its check Each contract clause has a unique identifier that links it to the executable checks for it.	§7.13, §16.2
GP-43	Structure outputs for verification When a result is hard to check, its structure is changed into checkable units with provenance, not only the check.	§7.14
GP-44	Evidence before, verification after, every phase Each phase starts with a read-only survey of the current state and ends with validation of what it produced.	§8.2
GP-45	Linked stage checks across production Checks at consecutive production stages form one linked chain with human-set control limits, and their measurements are recorded and compared.	§7.15
GP-46	Model-based verification before costly realization When physical tests are costly, slow, or cannot be undone, behavior is first verified against a validated model.	§7.16
GP-47	Reference realization with drift detection A maintained reference example shows the current reading of the contract; the system is compared with it, and a human screens any drift before correction.	§7.17, §16.2
GP-48	Durable execution records Execution leaves durable records that let an independent party diagnose what happened.	§7.18, §16.3
GP-49	Event-based gates with recorded closure Each phase transition has written entry criteria, and it closes only with a recorded human decision on every open discrepancy.	§8.3, §8.4, §16.2

5 Configuration control #

Pattern	Name and summary	Realized in
GP-50	Approved baselines at defined levels The system description is frozen at defined levels by human review at a gate; after that, only controlled change is allowed.	§3.2, §9.1, §16.2
GP-51	One controlled change gate A change to a baselined contract passes one controlled gate with recorded human approval; changes are classified by impact, and exceptions are recorded.	§3.2, §9.2, §16.2
GP-52	One configuration status ledger One ledger holds the status and history of every change, deviation, waiver, and audit result.	§9.3, §16.2
GP-53	Explicit deviation matrix Each departure from the standard process is stated explicitly in one matrix attached to the governing plan.	§1.5, §9.4
GP-54	Separate structural and behavioral change A change either restructures without changing behavior or changes behavior, never both.	§9.5, §16.2

6 Traceability and lineage #

Pattern	Name and summary	Realized in
GP-55	Traceability as a structural property Identifiers, names, and placement in the system description carry the traceability, so no separate trace file can drift.	§6.11, §10.1, §16.2
GP-56	Bidirectional traceability, verification and validation separate Traces run up to parent obligations and down to realization and checks, and verification and validation are traced apart.	§10.2, §16.2
GP-57	Versioned input lineage for reproducible results Every input to a result is versioned, and the result names the exact versions it used.	§10.3
GP-58	The realization system is traced like the product The processes, supply chain, and support that produce the product are described with the same rigor as the product, and changes on each side trace to the other.	§10.4
GP-59	One canonical source of truth per concern Each concern has exactly one authoritative artifact, and every agent is pointed at the same declaration of what governs what.	§4.3

7 Decision records #

Pattern	Name and summary	Realized in
GP-60	Numbered, immutable decision records Binding decisions are numbered, unchangeable records kept beside what they govern; they state context, options, rationale, status, and a compliance check, and only a new record can reverse one.	§8.4, §11.1, §11.2, §11.3, §11.4, §16.2

8 Risk and failure #

Pattern	Name and summary	Realized in
GP-61	Continuous risk register with documented human acceptance One register tracks risks continuously, and each risk has an owner, a mitigation plan, and a recorded human acceptance.	§12.1
GP-62	Failure closure by numbered corrective actions A failure report links root causes to numbered corrective actions, and work does not pass the failure until a human accepts each verified action.	§12.2

9 Boundaries and enforcement #

Pattern	Name and summary	Realized in
GP-63	Invariants as mechanically checkable constraints Invariants are written as constraints that a machine checks continuously, and each failed check tells the agent how to fix it.	§13.2, §16.1, §16.2
GP-64	Declared executor scope Each agent works inside a declared scope of permitted actions, permitted access, and forbidden boundaries, and the structure enforces that scope.	§13.1
GP-65	Disposable executors, durable work, structural boundaries Agent instances can be replaced; the work, the append-only decision record, a single merge point for concurrent work, and enforced boundaries remain.	§4.2, §4.8, §13.2
GP-66	Directives as controlled artifacts Standing instructions to agents are versioned, reviewable artifacts that humans edit directly, not settings hidden in tools.	§4.9
GP-67	Delegated work stays isolated behind a summary interface Delegated work runs in isolation and returns only a short result through a declared interface.	§13.3

10 Governance documents and layout #

Pattern	Name and summary	Realized in
GP-68	One governing-principles document A human writes one principles document first, and it is the acceptance background for all later work.	§3.1, §14.1
GP-69	Governance content discipline Governance documents hold only what agents cannot find in the system, stay short, refer instead of copy, and mark specifications of work not yet built.	§14.2, §16.2
GP-70	Short entry point into a versioned documentation tree A short entry document acts as a map into a versioned documentation tree, which mechanical checks keep current.	§14.3, §14.8, §16.2
GP-71	Governance bound to component boundaries Each component carries its own governance document, and the nearest document applies inside it.	§14.4
GP-72	Placement and naming are declared structure Where an artifact is placed and what it is called have a declared meaning, so both are part of the contract.	§14.5, §14.8
GP-73	Documentation lives on the artifact it governs Documentation and constraints sit on the artifact they govern, because documentation kept apart drifts.	§14.6

11 Roles, authority, and human checkpoints #

Pattern	Name and summary	Realized in
GP-74	One named owner plus a standing flaw-checker Each project or component has one accountable owner and a standing independent function that looks for flaws in its work.	§15.1
GP-75	Durable human breakpoints in the control flow Long-running work has durable stop points between decision and action, where a human can review.	§8.5
GP-76	Human-owned contract, machine-readable surfaces The human owns the contract and top-level decomposition, agents build below it, and every surface an agent acts on is machine-readable and checkable.	§4.4

12 Reusable procedures and document skeletons #

Pattern	Name and summary	Realized in
GP-77	Reusable task definitions with postconditions and prohibitions Each recurring kind of task is written once with its procedure, postconditions, prohibitions, required human input, and a summary that shows when it applies.	§5.10
GP-78	One registry; unregistered does not exist One machine-readable index lists every component and content item; an item that is not registered does not exist.	§14.7, §14.8, §16.2
GP-79	Why–What–How document skeleton Each design document separates purpose, method, and realization, and states success criteria, human decision points, committed resources, and rejected alternatives.	§6.19, §11.4