Appendix A · The Factory: A Formal Paper Built From Its Contract, With No Module Written By Hand
Abstract
A deterministic architecture engine declares software architecture as verifiable constraints and confronts them against real code. Since August 2026 it also builds: given a contract carrying structures, signatures and flow, its factory` plane produces the complete system, with an external verifier rejecting whatever violates the contract that requested it. This appendix documents the run that shows the plane works. A published paper defining a rewriting operator over structural states — with a well-founded measure and four theorems — was declared as a contract of 40 modules across 8 planes and fabricated: one round of 35 model calls, 40 of 40 modules verified, none stuck, no module written or corrected by hand. Five contract corrections were applied across three refabrication rounds, nine calls; two of the five consumed no call at all. The resulting system reproduces both of the paper's appendix trajectories exactly — the primitive selected at each step, the energy that motivates the selection, and the measure after each application. Three conditions carried the result, and all three are transferable: the retry must see its own rejected code; the verifier must catch what compiles and does not work; and the contract must be sufficient rather than merely well-formed. Five classes of sufficiency are identified, each by the defect it would have prevented — declared delegation, object construction, the level at which each criterion of a formalism operates, the enumeration of closed sets, and unambiguous return semantics. What the contract contributes is measured rather than asserted: 391 executable statements written by the model against 30 prose signatures, every line of which is either a structural fact about the code or a transcription of a numbered definition from the paper. The appendix closes with a negative control. Two instances of the same system, built from contracts differing in one clause of one signature, converge to the identical final state in the identical number of steps, offering the identical candidate set with identical energies at the initial state — and traverse different paths. No aggregate metric distinguishes them; the defective one violates nothing, because every state it visits is legitimate and what is wrong is the choice among transformations that are all valid. Endpoints verify the existence theorems; only trajectories verify the dynamics. Version of 14 August 2026. Section A.6.1 retracts a statement of the first version: the claim that the invariant classes of the formalism are exactly two is false. The instance concerned is ocgs_ref, the hand-corrected reference instance, not an artefact of the Factory. Its code admits four and raises on any other value, while its contract signature declares six. The disagreement is behavioural, not documentary: a state carrying an inadmissible class is legal according to the signature and fails at runtime. Which of the two is right is not settled by comparing them; that requires the published formalism, and Definition 11.5 partitions the invariants into two disjoint families rather than one flat set. The divergence was resolved on 14 August 2026 by declaration rather than correction, since the code of ocgs_ref backs a deposit. The fabricated systems do not carry the defect. ocgs_pru and ocgs_fab declare the partition of Definition 11.5 and keep the two homonymous senses of redundante apart; incompatible is absent by design, being the condition Cons(Φ_str) = ∅ rather than a label an invariant carries. This revision corrects the version of 13 August 2026, which did not name the instance and settled the disagreement with a verdict that had not been measured. The rule the section states is unaffected: a closed set that is not declared is an open set to whoever writes the code.
// Source
Authors: Diego Gabriel Impieri