A model arrives. It becomes a ComputeImage. The ComputeImage is admitted to execution. The execution produces a receipt. The receipt is the only authority.

The journey depends on three contracts. Each contract names a decision. The contracts do not overlap.

• `LogicalTensor` is the meaning. It is the tensor as the model defines it: shape, dtype, semantic family, role in the graph. Changing a layout does not change a logical tensor. Changing a representation does not change a logical tensor. The logical tensor is the model's claim about what the data is.
• `PhysicalTileLayout` is the storage. It is the tensor as the hardware stores it: tile sizes, padding, alignment, memory tier. The same logical tensor can have many physical layouts. A physical layout is a candidate transformation, evaluated against the model, the target, and the constraints.
• `ExecutionView` is the consumption. It is the contract by which a backend reads the data at execution time. An execution view names the lane, the provider, and the dispatch path. A model may have many execution views, one per lane, per provider, per plan.

A change to one contract does not silently rewrite another. A logical identity is preserved across representations because the representation is bound to the plan, not to the tensor. A physical layout is preserved across lanes because the layout is the artifact, not the kernel. An execution view is preserved across runs because the view is durable state, not runtime cache.

Compilation is a search. The search has a state space: every legal combination of representation, layout, target constraint, and numerical policy. The search has a cost model: the time, the memory, the precision, the numerical error. The search has a result: a plan, admitted as durable state.

The candidate transformations are typed. A precision change is a typed operation. A sparsification is a typed operation. A ternarization is a typed operation. A layout change is a typed operation. Search policy may be heuristic, evolutionary, learned, sampled, or cost-model driven. The admitted candidate, its constraints, and its evidence are explicit. The search process is not required to be.

The visitor sees the search space. The visitor sees the chosen path. The visitor sees the rejected alternatives. The site is not a summary of the choice; it is the evidence of the choice.

The runtime executes the plan. It does not invent decisions. It may instantiate only the runtime choices explicitly permitted by the plan: lane selection within a permitted set, scheduling within declared residency policy, queue ordering, retry within declared bounds. Anything outside those bounds is a different plan, with a new identity, and a new admission record.

Canonical world state is the authority for everything the plan does not cover: admission, ownership, leases, deadlines, fencing generations, transaction validity, terminal failure. The runtime consults both. The plan does not replace the world. The world does not replace the plan.

A result for an expired or superseded lease is rejected at the boundary, not silently accepted. A result that does not survive a restart is not authoritative. A failure is recorded. A recovery is recorded. The recording is the receipt.

The plan is the boundary between compilation and execution. The plan is sealed when it is admitted. The seal is durable. The seal is the admission record.

A re-plan is a new admission. A different representation, a different layout, a different target — each produces a new plan identity. The new plan may reuse parts of the old plan's evidence, but it is a new plan. The artifact digest changes if the materialization changes.

The boundary is not a convention. It is a type. The runtime cannot construct a plan. The compiler cannot construct a request. The two meet at the artifact and at the transaction.

The architecture is implemented. The contracts exist. The compiler exists. The runtime exists. The receipt path exists.

What is Validated on a real target: nothing in the v1 corpus. The receipt types exist as Rust definitions; the engine has not yet emitted one to publishable storage. The ValidationReceipt and SearchSelectionReceipt types are bound to the v1 schema set (per ADR-033) and are the canonical types. A follow-on ADR emits them to a stable, content-addressed path. Until then, the site names the gap and shows the schema.

What is Implemented: the source code paths for compilation, the cimage encoder/decoder, the constitutional command set, the receipt envelope (ReceiptCandidate), the world transaction layer. Each row above carries a source path; a reviewer can read the entry point and reason about its control flow.

What is Planned: heterogeneous target qualification, ANE/CUDA/NPU providers (ADR-031), end-to-end receipt emission to publishable storage, a real qualification harness output. Each is a milestone with an exit criterion in the roadmap.