How it works
Three questions, answered with the engine running
Every page in this section that shows a number, a diff, or a finding produced it by running the real machinery at build time — over committed contracts and committed captures. Start with the question you came here with.
How are properties added?
A hand edit on either surface becomes a reviewable contract patch; promotion regenerates both sides. The full lifecycle, replayed with the real emitters and the real differ at build time.
How are nested components addressed?
Contracts stay per-component; parents embed children by reference. Session linking, honest stubs with observed geometry, and the upgrade path — replayed over the committed Dialog → Button → Icon captures.
What about 100 components with nested dependencies?
The dependency graph of a real 1,618-set enterprise kit, computed at build; deterministic build order; the whole-kit census — and a plain statement of what a contract does not cover.
Foundations
The positions and machinery under those answers, in six short pages.
The model
Why the truth is neither surface, and the arbitration rule that keeps both honest.
The protocol
Contracts-in-git are canon, CI is the enforcement point, and authority belongs to the layer that can mechanically refuse.
How styles are applied
Names, not values: two-stage application on the code side, bound variables on the canvas — the same statement in two dialects.
Determinism & receipts
Golden manifests, refusal by name, and degradation codes — how “generated” stays checkable.
The instruments
The census, the visual-parity instrument, and the enterprise gauntlet — with their real numbers.
Round-trips
Code→contract→canvas and back: the executed promotion loop, with receipts.