# Contract Authoring Reference

Read this only while authoring or structurally revising the one `delivery-contract.yaml` Draft.

## Source And Semantic Boundary

- Every declared Source file contains at least one Material Source Item. Mark items in original Markdown without rendering or changing meaning. Every other non-empty line belongs to the one schema-valid `design-resource-handoff-v1` formal block or a closed-grammar background block: `markdown-structure` permits only text-free anchors/horizontal rules and `provenance` permits only `ty-source-provenance` comments with fixed `input`, `mode`, conditional `source` and optional `sha256` fields. A text-bearing heading or free-form provenance field may carry authority and cannot be background. Arbitrary background prose and every other unclassified line fail closed.
- Marker keys and `source_claim` keys are set-equal and globally unique. `statement` preserves marked text after line-ending normalization, surrounding blank-line removal and trailing-space cleanup.
- Typed dispositions keep Result, Requirement, Control, Technical Obligation, Non-completing Claim, Acceptance, Global Constraint/Non-goal, Forbidden Shortcut, Risk, External Confirmation and Decision distinct.
- Every non-decision Source item owns exactly one same-kind, text-identical canonical target; no target may collapse multiple Source items. `out_of_scope` is not a resolution.
- A Source AC maps criterion-identically to one named Assertion and proves at least one independently Source-backed non-Result Claim.
- At least one `technical_obligation` Source Item has `aspect=architecture`, maps text-identically to a named architecture obligation and is independently provable; a generic Result or unmarked architecture review cannot substitute.
- Missing headings or keys from a pre-existing planning document never blocks authoring. Raw/mixed inputs enter this Contract Draft immediately; apply `source-authoring.md` alongside mapping until real Source, provenance and markers converge. Missing mandatory Material Source Item markers still blocks Preflight/Compile.
- A revised initial proposal and selected design resources are parallel Source inputs. Preserve their stable resource/surface/control/state/target keys, declared conditions, provider/project/run/entry provenance and immutable digest/snapshot; do not flatten visual meaning into an untraceable prose summary.
- `delegated` in an input proposal is provenance, not a Contract disposition or new Claim kind. An instruction to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent material tradeoff preferences. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. If such a preference is unknown or ambiguous, ask a concise targeted question before research or selection and keep the item `decision_required` until answered; do not impose a fixed questionnaire or re-ask preferences already supplied by the user, Source, Context or controlling constraints.
- Once the material preference envelope is clear, use current authoritative or primary evidence for external capability, price, quota, license, compatibility, region, security posture or support claims. When one defensible recommendation exists, record the authoring instruction, preference/evidence or conservative-default basis and exact added meaning in real Source, then preserve that keyed item as ordinary Source of its semantic kind. If ordinary prose is the Source, append the delegated item without rewriting the user's original text; never place the choice only in Contract YAML.
- A delegated plan choice is not action authorization. Payment, contracting, production deployment/publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named External Confirmations. Conflicting authority, an explicitly user-reserved choice, a missing material preference or the absence of a defensible recommendation remains `decision_required`; high impact or multiple options with known criteria alone does not.
- A rolling implementation blocker is not an External Confirmation merely because work is difficult, delayed or unavailable through the current implementation path. Reclassify or remove machine-verifiable scope only through an explicit marked Source change and protected exact approval; otherwise keep the requirement and revise the implementation/evidence path.
- Exactly one Source-embedded `semantic-fact-manifest-v1` is mandatory. Root `semantic_fact_manifest` binds its key, declared Source path and immutable digest. Its scope includes every Outcome and every Material Source Item; ordinary Material Source cannot be `supporting_only`, while independently validated design-owned Source may be `ui_design`. Full Controlling Context inventory and every other declared attachment/specification/repository/external/delegated input are classified with exact digest, Fact refs or explicit basis-backed disposition.

## Non-UI Semantic Fact Projection

The semantic manifest is the task-local Source index, not a second Contract or durable value authority. It must already close the complete standard/custom semantic family floor, stable subject/relation/population Census, exact applicable condition axes/values/combinations, atomic property partitions, Fact Cells/Facts, proof obligations, Oracles/environments/blockers and complete-generation identities before Compile. Values stay at their Source locators; Contract freezes identities, located digests and comparison authority.

For every Outcome:

- `semantic_fact_bindings.manifest_ref` equals the root manifest key;
- `semantic_fact_bindings.facts` is set-equal to that Outcome's manifest Facts. Each row binds one `fact_ref` to exactly the generated `semantic_fact.<fact_ref>` Claim and one matching atomic applicability profile;
- `semantic_fact_bindings.proofs` is set-equal to that Outcome's Fact × required-method obligations. A machine row preserves method, proof surface and all evidence capabilities, binds one owning Check and one single-Claim Assertion at the same applicability, and is legal only when Compile can project it to one package-admitted current-Actual authority. An external row binds one typed External Confirmation whose impacts include the full Fact Claim;
- every declared observer resolves to an execution target and admitted package adapter capable of observing the furthest independently failing boundary; a project-authored Oracle, product/self-reporting proxy, wrapper or submitted capability record cannot impersonate that observer;
- the Claim/Assertion/Check projection must be bijective. Missing, extra, duplicate, reused, narrowed or orphan Fact/proof identities block Authority Lock.

The exact invariants are:

`Expected Semantic Facts = Source Indexed Facts = Contract Indexed Facts`

`Source Fact × required-method obligations = Contract proof bindings = current Final-Gate result identities`

Do not copy raw semantic values into Contract, merge multiple atomic facts into one Claim, use one Assertion for several Fact obligations, turn a machine-verifiable Fact external because implementation is difficult, or accept a default/sample/aggregate path. A protected Fact uses digest-only expected authority and a policy-bound redacted/digest observation with no raw persistence. Genuine decision/external authority remains explicit and target-blocking as required.

Compile derives one internal observation-authority row for each machine proof. Current admission has only two choices: `package_static_json_exact` for plain `exact_value + exact` static implementation/configuration content in a pre-run-frozen UTF-8 JSON production carrier, and `package_process_json_exact` for plain exact output observed while Harness directly spawns the declared `process` product root. Every other proof—including custom/`named_external_tcb` Oracles, project wrappers, protected data, tolerance/mask, custom locators and browser/native/device/layout/pixel/accessibility/motion observations—must be authored as a blocking External Confirmation. This projection is not a new Contract field, Authority, state or registry, and unsupported machine rows fail Compile rather than auto-migrating.

## Outcome Boundary

Create an Outcome only when its result is independently observable, decidable, target-verifiable, dependency-expressible and localizable to its own Claims, Assertions, Checks and owner boundary. Requirement coupling, acceptance/verification-ready projection, targeted verification, precise failure localization, semantic resume and stale-result invalidation are valid reasons to decompose. Outcome boundaries never restrict implementation order. File count, implementation layer, context length, desired parallelism and Agent capacity are not.

For every Outcome declare:

- one complete observable result;
- atomic requirements and actually applicable controls/states;
- non-completing claims;
- owner Context/surfaces and expected/support/forbidden path envelopes;
- stable technical obligations, Bindings, forbidden shortcuts and recovery requirements;
- risk facts;
- executable Checks and named AC Assertions.

Global non-goals, constraints and forbidden shortcuts remain Global authority and use Global Checks/Assertions when machine proof is required.

Declare only real applicability, not a blind Cartesian product. Each global or Outcome profile names one exact execution target, journey role, a non-empty duplicate-free set of atomic dimension assignments, keyed Given condition/input/state facts and ordered When actions. One profile cannot bundle phone/tablet, light/dark, default/loading or other multiple values of the same dimension. Every Claim-bearing fact lists all and only its applicable profile refs. Every Claim-bearing Assertion proves exactly one Claim in exactly one matching profile, and every required proof surface of every actual applicable cell has an attributable Assertion. Two cells may share one Check execution only when their individual Assertion failures remain distinguishable; risk-based, pairwise, representative or sampled coverage never substitutes for a declared applicable cell.

## Feedback-cost boundary

Declare each Check's `input_paths` and Binding carriers as the smallest sound causal envelope for that Check. Do not use a repository, application or platform root merely because it is convenient: a broad pattern is justified only when any matching change can actually invalidate the declared result. If independent capabilities have different invalidation surfaces or useful feedback boundaries, assign them to the owning Outcomes/Checks rather than making every early Stage gate stale.

Every Counterfactual mutation path must be a current production carrier with a defensible route from the declared target root to the asserted behavior. A Binding or `input_paths` declaration is not reachability proof. A static-structure proof mutates and observes the frozen structure object itself and cannot be promoted to runtime behavior; a runtime proof requires Harness mutation of the declared carrier, direct execution of the same process product root and package-observed actual change. Declare the expected affected Facts, preserved Facts and allowed fan-out Facts; baseline and mutation must retain the same obligation universe, all expected Facts must change, preserved/liveness Facts must not change and every other change must be listed fan-out. A machine-closing Check with no admitted baseline or mutated observation fails rather than skipping. Review `verify --explain` before an expensive first execution and repair obsolete routes, barrels, fixtures or duplicate Main/Counterfactual invocations.

Declare cheap machine-checkable prerequisites through existing environment requirements and verification inputs. Product/API readiness probes, incremental build caches, streaming phase output and timeout heartbeats belong to the project-owned runner when they depend on its runtime. The admitted direct-process observer is the narrow exception: Harness owns bounded stdout capture plus process-tree inspection and cleanup because those are part of its host execution TCB; this remains containment rather than an absolute hostile-code sandbox.

## Stage And Target Profile

- Declare one ordered `stages` DAG in the same Contract. Every Outcome belongs to exactly one Stage; every Stage names one gate Outcome; the gate transitively depends on every other Outcome in that Stage; and every later Stage Outcome transitively depends on every prerequisite gate.
- A Stage Gate is not a second Final Gate or Receipt. It is one or more `stage_gate` Checks owned by the gate Outcome, and its status/frontier is derived from ordinary Outcome Progress.
- A multi-Outcome Stage Gate declares `cross_surface_consistency`. Its diagnostic runtime record names at least two distinct `surface_ref` values, may use the same runtime target for several pages and reports one matching state version. Because the current slice has no package derivation for that capability, the owning machine obligation remains a blocking External Confirmation.
- `task.target_profile` declares `required_state` plus a non-empty, duplicate-free `required_target_refs`. Each ref resolves to a `product` execution target with one bounded runtime family, root entrypoint, complete `root_argv` and explicit capabilities. Give every required target one Source technical obligation whose canonical target is `execution_target.<key>` and whose exact normalized statement preserves key, role, family, root, complete argv and capabilities; the Source Claim disposition, execution target and production Binding must agree. A required process root and every argv path admitted by the finite production-Binding match belong to the production owner and a Binding, not merely to the runner, a fixture, verification input or `input_paths`. The match examines a standalone argument or explicit `--key=value`, resolves a safe repository-relative value from declared `cwd`, and accepts exact or pattern Binding coverage, including glob-owned and extensionless files. Unmatched safe relative values are labels/outputs rather than inferred dependencies and are not copied. Absolute paths, repository escapes, `file:` URLs and network URLs fail closed unless explicitly routed to the external TCB/External Confirmation boundary. An exact planned root, matched argv file or process carrier may be absent through Preflight/Compile, but Final Gate requires it to exist; materializing the already-declared path does not revise Authority. Do not guess from file extensions, substrings, output flags or a language dependency graph. Root/family/role/argv/capability declaration change is a protected Source/Contract and Authority Revision. Current machine `target_runtime` proof exists only for a Harness-direct Source-backed `process` product root; required browser/native/desktop/device targets and other unsupported families retain target-blocking External Confirmation. Every Stage Gate and every `critical_user_path` Outcome accounts for every required ref through admitted root proof or that External Confirmation. Optional support/observer targets never substitute.
- Use `implementation_complete` only when code-level implementation is the selected target, `target_profile_usable` when the declared required targets must be usable, and `production_release_ready` only when release gates are part of the selected target. These are terminal target qualifications, not Outcome progress states.

## Engineering Quality Deliberation And Closure

Architecture Deliberation occurs once for every implementation delivery before formal Compile and the first implementation edit; risk changes depth, not occurrence. Surface concise conclusions and repository evidence rather than private chain-of-thought. A preservation result still names the concrete owner/extension point, applicable engineering-quality attributes or their concrete preservation basis, and why durable boundaries and debt do not worsen. Material work covers module ownership, unique source of truth, dependency direction, API/schema/data boundary, state/resource lifecycle, persistence/recovery, security boundary, compatibility/migration, selected and rejected alternatives, one plausible future-change challenge, touched technical debt, forbidden bypasses and triggered failure/load/threat scenarios.

Correctness/invariants and maintainability/changeability always receive at least preservation. Reliability/resource lifecycle, concurrency/consistency, performance/capacity/cost, security/privacy/safety, compatibility/migration/rollout and operability/observability/testability activate only when the Source or implementation risk makes them material. Exact expected predicates remain in Semantic Facts or selected-design authority. A performance claim additionally binds workload, metric, baseline or budget, environment, comparator/tolerance and a project-owned benchmark/probe; static shape cannot prove runtime performance.

Represent every material independently falsifiable architecture or engineering-quality invariant with existing Contract fields:

1. a Source-backed technical obligation, global constraint or forbidden shortcut;
2. owner Context and expected/support/forbidden paths;
3. a Binding to the implementation carrier when Counterfactual sensitivity is required;
4. a project-owned executable type, compiler, lint, AST, dependency, contract, behavior, benchmark or probe Check; and
5. a separate Assertion when functional behavior could pass while the quality invariant fails.

New or worsened debt is unacceptable unless a project-owned bounded exception identifies owner, rationale, tracking and removal/expiry condition. Unrelated legacy debt does not automatically expand delivery scope, but debt touched, relied on or worsened by the implementation cannot remain hidden. Material changes to scope, owner, Context, dependency direction, selected design or debt disposition refresh the deliberation and, after Authority Lock, use protected revision.

Do not encode subjective “clean architecture”, `quality == true`, a functional pass or generic quality prose as machine authority. If no reliable observation can falsify it, keep it as durable Context/review judgment or return `decision_required`. Harness routes repository-native checks; it does not become a language-generic dependency, quality or performance analyzer. Final Gate is the only Long-Task Engineering Quality/Architecture Conformance carrier and reruns these declared Checks on its current snapshot. It proves only the declared project-check-bound invariant set, not overall code quality. Do not add a default-workflow closure, quality matrix, Source aspect, Claim/risk kind, Contract field, second Gate, state or Receipt.

## Proxy And Target Runtime Independence

When a declared result can pass on a proxy surface while failing in its target runtime, author independent target-runtime proof for the exact required target ref. Put it in the earliest Outcome that owns the first runnable target boundary rather than postponing it to a terminal release/quality Outcome; this assigns proof ownership and does not dictate implementation order. Under the current admitted slice, machine runtime proof is available only through Harness direct-process observation; all other runtime families remain target-blocking External Confirmation.

Use existing Contract semantics:

1. require `runtime_behavior` or the other proof surface that matches the actual Claim;
2. for machine proof, use a `project_binary` runner whose target exactly equals the declared `runtime_family: process`, `role: product` root entrypoint, has no wrapper and permits read-only or test-sandbox execution;
3. let Harness own the process handle and capture exactly one bounded `ty-context-product-observation-v1` envelope from product stdout. It proves only exact values that the root itself emits on that declared JSON output surface; project-authored instrumentation/mapping cannot reclassify arbitrary internal/UI facts as package-observed, and any Claim that cannot bind directly to the surface requires External Confirmation. Do not declare or consume an observation-path, challenge or protocol environment variable; the execution nonce is internal host-attestation data. Project-submitted v3 actual/comparison/verdict and capability records remain diagnostic only;
4. declare runtime-affecting entrypoints, modules/configuration and Claim/Counterfactual carriers through the production owner and Binding. For argv, use a standalone argument or explicit `--key=value`; Harness resolves a safe repository-relative value from declared `cwd` and includes it only when an exact or pattern production Binding covers the result. Glob-owned and extensionless files are valid, an unmatched safe relative value is not copied, and absolute/escaping/file-URL/network values fail closed unless explicitly external. `input_paths` still describes Check scope/freshness but is neither broadly role-scanned nor promoted into the process snapshot. Compile rejects any actual closure member that overlaps Source/Context/Contract/canonical expected, verification, expected-output/artifact, evidence/status/report/comparison/Receipt/Long-Task or historical-session roles. Global closure records keep `<outcome>.<binding>` logical identity while physical files deduplicate by path; authored Contract Bindings remain local and unchanged. Harness copies only this compiled closure, and a dependency that cannot be explicitly production-bound remains External Confirmation rather than triggering extension, substring, output-flag or language dependency guessing; and
5. otherwise bind the Claim to a blocking External Confirmation instead of inventing a project-verifier proof.

This process path relies on the host OS/filesystem/process APIs, Node runtime, snapshot copy/digest checks, stdout decoder and process-tree inspection/cleanup. It is not a security sandbox and does not claim containment against a malicious executable using ambient filesystem/network resources or evading every process-tree mechanism. If the Contract requires that threat boundary, use an independently controlled sandbox and keep its acceptance external until a package adapter is separately admitted.

A proxy check, project-verifier payload, static repository shape, tracked status report, prior screenshot, binary, historical run or new `session_id` cannot be the sole proof of a Claim that can fail independently in the target. The required target family must equal the admitted observer family. Use only the bounded execution-target runtime families and required refs in the Contract; do not add open-ended `platform_impact` flags or per-platform Progress state.

## Success, Degradation And External Boundaries

- Set `success_path_required` and `degradation_path_required` explicitly. A Result Claim is proved only by a `success` Check; the same Check cannot be both success and degradation, and an honest unavailable/pending/recovery state cannot replace required success.
- External confirmations declare `kind`, exact `impact_claims` and `blocks_target`. A `functional_prerequisite` blocks the selected target; a `production_release_gate` blocks a production-release target but may remain non-blocking for a lower target. Reclassification or impact changes are protected authority.
- External Confirmation coverage is exact for ordinary/global Claims and Semantic Fact Claims; it creates no machine Assertion or result. For a fully unsupported Outcome, set `success_path_required: false`, omit machine Checks, include every affected Claim in `impact_claims` and keep each Semantic Fact proof explicitly bound to that confirmation. A Stage Gate may omit its machine Check only when a `blocks_target: true` confirmation impacts that gate's `result` Claim. A non-blocking confirmation or one missing the result impact cannot substitute, and `success_path_required: true` still requires a real success Check. The final status is `blocked_external`, never machine accepted.
- `boundary_invocation` and `external_side_effect` still require a declared independent `observer` target, but the current slice has no package derivation for either capability. Their project records are diagnostic and their obligations remain External Confirmation; product self-report never proves the downstream effect.

## Visual Delivery Authoring

When the selected delivery includes a new/redesigned screen, primary layout/navigation/theme/component system, high-fidelity implementation or other material production UI, resolve Design Authority before Compile and author the result through existing Contract semantics. The complete design Fact universe remains mandatory Source authority, but the current machine observer does not admit browser/native/device/layout/pixel/accessibility/motion or protected/tolerance/mask observations; those Fact × method obligations must be blocking External Confirmations rather than project-verifier machine rows:

- when selected external resources are an implementation handoff, place one strict marked `design-resource-handoff-v1` Markdown file in `task.source_paths` and run `ty-context design-resource preflight <handoff.md>` before Contract Preflight. A formal Web/App profile requires a canonical entry, exact dependency closure, complete acquisition and one frozen-Inspector Fact manifest proving `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`. The atomic unit is an explicit `subject × target × condition × variation × property` Fact Cell: stable component instances/Anatomy Parts/relations and dynamic populations; all standard/custom target-condition and subject-variation axes/combinations; the complete standard/custom atomic property catalog; explicit N/A/exclusion basis; one Fact per covered cell; and every property-required Fact × method proof. Product Controls and eight UI/UX dimensions are semantic/roll-up owners, not the Fact ceiling. Incomplete acquisition/Census, aggregate labels, initial default-page inference, sampling/truncation, unresolved locators/lineage/conflicts/blockers, unsupported evidence and stale identities block. Canonical resources own exact values; the residual handoff projects located digests, value/design-system lineage, sensitivity, evidence, comparator/tolerance/mask, Oracle/environment and asset bindings without becoming a CSS copy. Every exact target additionally requires full-target layout and pixel Facts per condition. Deliberately partial input remains an explicitly scoped constraint or blocking unresolved and never an exact target. Treat candidates and unresolved decisions honestly; only a selected exact target with a valid selection basis, complete declared Fact universe and immutable identity can be proposed for fidelity authority, and downstream UI Authority Closure still owns adoption;
- perform UI Authority Closure over stable surface/control/target keys: classify each material item as covered by owning Context/`DESIGN.md`, requiring an owner update, task-local Source, explicitly out of scope or genuinely `decision_required`. Product Surface Context owns cross-surface responsibility, Screen/interaction Context owns durable hierarchy/behavior, `DESIGN.md` owns visual-system/reference semantics and selected targets own concrete composition; Contract YAML must not duplicate or invent those owners;
- inspect owning surface/interaction Context, `DESIGN.md`, its authored token source/generation direction and material design references. Classify every reference as `exact-target`, `constraint` or `inspiration`, with its surface/route/component, path/URI and covered viewport/theme/mode/state;
- an unconfigured starter, style-only prose, inspiration-only set or conflicting target is not sufficient production authority. Resolve it by explicitly scoping Source to a prototype/non-fidelity result, recording an explicitly delegated and selected design target in real Source after material preferences are known, or keeping the unresolved/user-reserved direction `decision_required`;
- never let implementation output authorize itself: a generated implementation screenshot/diff is an Artifact, not the target. An acceptance-affecting target or baseline must be selected Source/verifier input before fidelity implementation can be accepted;
- derive the exact task-local Visual Coverage Set from declared Source, `project_context/**` and `DESIGN.md`: production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions. Do not invent an irrelevant Cartesian product, but cover every combination that is actually applicable;
- never use risk-based, pairwise, representative or sampled combinations to waive an applicable cell. Equivalent execution may be shared only when each fact/method retains an independently attributable Assertion and any omitted applicable combination remains blocking;
- encode each independently falsifiable visual expectation as an atomic Requirement, applicable Control field or named AC Assertion. Name the surface, viewport, theme/state/content condition and observable result when they matter to the claim;
- close every real Control's canonical fields independently through `field_coverage`: `surface`, `region`, `location`, `control_type`, `label_content`, `user_task`, `visibility`, `availability`, `trigger`, `input`, `validation`, `default_value`, `interaction`, `navigation_result`, `loading_state`, `empty_state`, `success_state`, `failure_state`, `recovery`, `permission`, `feedback` and `accessibility`. `specified` names concrete meaning, `not_applicable` carries a falsifiable reason, and `unresolved` blocks Compile; specified and not-applicable entries create Claims for every declared applicability profile, so omission can never silently mean non-applicable;
- close each Outcome's cross-Control/system meaning through `control_relation_closure` plus `control_relations`: shared state, dependency/order, mutual exclusion, navigation, permission, recovery, validation and feedback chains are explicit relations with Control refs, proof surfaces and applicability, while `state: not_applicable` is a negative Claim with exact applicability and an explicit assertion that no such relation applies; `unresolved` blocks;
- when an Outcome declares Controls, add the minimum aggregated Product `surface_bindings`: one stable binding per owner surface and required product target, its Control refs, existing Technical route/component Binding refs, one root-entry success Check and its real entry action. Every Control must be bound and every Control Claim must have target-local disposition. The admitted direct-process observer can derive host `target_runtime` for the real process root, but it does not currently derive `interaction_trace`; interaction plus browser/native/device journeys remain blocking External Confirmations;
- bind the declared result to the owning Context/`DESIGN.md`, one authored token source and generation direction, selected target/constraint inputs, production component/route carriers, path envelopes and project-owned target checks. Freeze acceptance-affecting selected target files, token sources and fixed prototype fixtures in `verification_inputs`; bind production carriers through `input_paths`/Bindings and reserve `artifact_globs` for generated implementation renders, diffs and reports. Detached kits, deep links, mocks or marketing specimens may be references or supplemental checks but not substitute implementation carriers or the production root journey;
- for each selected exact/constraint target inside a surface binding, use the exact handoff target key and interpretation; declare `source_paths` as exactly the handoff plus that target's immutable resource paths and `condition_keys` as exactly its handoff condition refs. Put the same files in Check `verification_inputs`; map every covered handoff Source Item through `source_claims` to method-specific Source Claims and separate single-Claim Assertions at the target's exact applicability; and bind every handoff acceptance blocker in the surface binding. Every handoff verification method binds its own Assertion and exact per-condition `evidence_artifacts`. Each cell declares the exact proof-owned `fact_refs`, `path` for its method record, `observation_path` for its primary method-native observation and a canonical `fact_expectations` row for every Fact. That row freezes subject, variation, property, `plain|protected` sensitivity, expected canonical located digest, comparator, exact/tolerance mode, parameter/tolerance/narrow-mask located digests, Oracle key/trust/identity/version/digest and environment key/identity/definition located digest. Contract stores these references and digests, never a duplicate CSS value source. Cell Fact sets close every property-required Fact × method obligation; their exact union equals the target Fact set. Current package derivation supplies only admitted plain exact/presence results and host `target_runtime`; project or Playwright `design_method`, `fact_results`, `design_conformance` and `interaction_trace` rows remain diagnostic and cannot provide authority. Because the current slice does not admit design conformance, interaction, layout, pixel, accessibility, motion, browser/native/device, protected or tolerance/mask observation, those obligations retain their exact expectations but bind blocking External Confirmations instead of fabricated machine results. Missing/extra/duplicate/stale/failed rows, authority drift, mismatched environment, widened mask/tolerance, result reuse or indistinguishable observation still fail every admitted exact Assertion. `visual_render`, handoff preflight, Inspector counts, file hashes or registry presence remain input/resource integrity and cannot substitute for implementation conformance or omitted Fact proof;
- explicitly inventory every declared design-acceptance blocker inside its surface binding. An empty array states that no blocker is declared; each declared entry preserves exactly the handoff's `source_item_refs`, `verification_methods` and non-empty `required_capabilities`. A `machine_claim` is valid only when the exact obligation compiles to a package-admitted static or direct-process exact observation and the referenced Claims have matching target-local proof; otherwise use a target-blocking External Confirmation whose impact includes the Outcome. There is no in-band not-applicable waiver: removing a blocker from scope first requires explicit revised Source and, after Authority Lock, protected Contract revision. Empty refs block Compile/Final Gate;
- retain `ui_browser` assertions only as project diagnostics during this first observer slice. Browser, Expo-Web, native, mobile and desktop UI conformance cannot machine-close a Claim; bind the affected Claim or blocker to target-blocking External Confirmation rather than treating Playwright, a project binary, screenshot or device/session payload as observer authority;
- keep subjective visual direction, taste or approval outside false machine proof. Resolve an undecided direction as `decision_required`; represent required human design or new-baseline approval as an explicit external confirmation.
- for combined design-and-implementation delivery, ordinary design Outcomes/Stages may author candidates before selection, but candidate/planned artifacts cannot authorize fidelity Claims. Append the selected result to real marked Context-reachable Source and its owning Context/`DESIGN.md` reference; after Authority Lock adopt it through Authority Revision before downstream fidelity implementation. This creates no target-selection state, second Contract or second Gate.

External design resources authorize fidelity only when they become a selected exact target with a validated handoff; they remain ordinary upstream Source rather than a Contract Draft, verification result or alternate authority. The revised initial proposal plus selected immutable canonical resources and the residual `design-resource-handoff-v1` is the recommended implementation input; no standalone intermediary authoring handoff is required. Map each exact fact set into method/condition evidence, each covered Source Item into the root conformance Assertion and each declared verification method to its own independently failing Assertion; carry blocker Source Items and methods unchanged into a target-local machine Claim or target-blocking External Confirmation. Any pre-existing planning document remains valid ordinary Source if supplied. The single Product `surface_bindings` projection is an aggregated cross-reference over existing Source, Controls, Technical Bindings, targets, Checks, Assertions, verification inputs and External Confirmations; it creates no `uiux_delivery` authority block, Claim kind, risk level, lifecycle state, required design directory, per-Control screenshot matrix or Gate, and it creates no copied style/value source.

## Symbolic Selected-Design Authoring

UI symbolic V2 is explicit opt-in; V1 remains the default. Accept `design-resource-handoff-v2` only when the target explicitly declares `representation: symbolic_rules_v2`. Require equal extensional disposition, located expected semantics and complete proof-obligation denotation across every subject/relation, target, reachable condition/variation, applicable atomic property and population/quantifier point; physical V1 ground-row identity is irrelevant. V2 Rules use constant located expected values and mutually exclusive exhaustive canonical regions. Applicability may retain legacy exact remainder partitions or use package-owned subject property profiles plus frozen Inspector custom-property closure and explicit unique instance exceptions; every logical subject-property point still needs exactly one disposition. Project every required method to typed current Rule-region evidence only when its Actual comes through the admitted package observer; otherwise bind the obligation to External Confirmation. Each set-valued Rule/omitted-axis certificate remains a separate fresh package-recomputed result without materializing Rule × axis edges. An omitted axis requires both Source-side and production-side proof through frozen closed-world static dependency closure, restricted-IR exact equivalence or finite complete-domain exhaustive equivalence; dynamic/reflected/unfrozen/external or sampled dependencies block. A Contract may mix V1 and V2 targets, but records cannot cross-substitute and all converge only in the existing Final Gate. V1 over-capacity diagnostics may guide an explicit V2 decision but never switch automatically. Purpose-efficiency is package admission, not terminal safety or a new Gate. Non-UI symbolic admission remains out of scope; verifier/runner observation authority is covered by the mandatory admitted-observer boundary above.

## Compact Authoring

Compact V2 may omit only deterministic defaults: empty optional arrays/nulls, `requested_level: auto`, runner `argv: []`, `cwd: .`, `timeout_ms: 30000`, `retry_policy: none`, `idempotent: false`, and empty output/artifact/assertion/environment lists. `context_snapshot_mode: full` remains explicit and is the only accepted authority mode.

Goal, target profile/required targets, ordered Stages, Source/Source Claims and non-authoritative background ownership, Context, observable results, exact applicability profiles, success/degradation requirements, owners/paths, REQ, all-field CTRL closure, Control relations and production `surface_bindings`, selected target conditions/conformance artifacts, design-blocker dispositions, OBL, proof surfaces, Given/When scenarios, journey roles, Evidence Capabilities, runner targets/effects, verification inputs, single-Claim Assertions, behavioral semantic witnesses and liveness Assertions, risk, forbidden shortcuts and typed external confirmations remain explicit.

Compiler-generated Outcome/Check/Claim identities replace handwritten mechanical cross-entity references. This does not authorize compiler inference of product meaning, owners, architecture, proof or risk.