UOR Foundation Layout Invariants

IRI: https://uor.foundation/foundation/
Prefix: foundation:
Space: bridge
Comment: Foundation-level layout invariants complementing op-namespace theorems. Quantifies over foundation-defined SITE_COUNT arithmetic and ConstraintRef byte patterns, not over ontology-level siteBudget.

View documentation reference

This is a bridge-space namespace in the Resolve stage of the PRISM pipeline. It provides the resolution infrastructure — queries, partitions, observables, proofs, derivations, and traces that transform inputs into certified results.

Learn more: Pipeline Overview

Imports

https://uor.foundation/partition/
https://uor.foundation/type/

Classes

Name	Subclass Of	Disjoint With	Comment
`LayoutInvariant`	`Thing`		A foundation-level layout invariant. Each instance describes an arithmetic or encoding identity that the foundation's mint primitives and validate_const() pass enforce at compile time, distinct from the ontology-level theorem individuals carried by the op namespace. Violations produce GenericImpossibilityWitness citations against the specific LayoutInvariant IRI, letting consumers distinguish a layout-level failure from a theorem-level failure.

Properties

Name	Kind	Functional	Domain	Range	Comment
`layoutRule`	Datatype	true	`LayoutInvariant`	`string`	The arithmetic or encoding identity this LayoutInvariant asserts, expressed as a human-readable string for inspection in documentation and debugging output.

Named Individuals

Name	Type	Comment
`ProductLayoutWidth`	`LayoutInvariant`	PartitionProduct layout-width invariant: products introduce no bookkeeping of their own, so layout widths add. Cited by primitive_partition_product when the caller-supplied combined SITE_COUNT differs from the sum of operand SITE_COUNTs.
`layoutRule`: SITE_COUNT(A × B) = SITE_COUNT(A) + SITE_COUNT(B)
`CartesianLayoutWidth`	`LayoutInvariant`	CartesianPartitionProduct layout-width invariant: cartesian products introduce no bookkeeping either, so layout widths add the same way PartitionProduct does. The distinction between these two constructions lives at the nerve-topology level (χ multiplicative vs additive), not the layout level.
`layoutRule`: SITE_COUNT(A ⊠ B) = SITE_COUNT(A) + SITE_COUNT(B)
`CoproductLayoutWidth`	`LayoutInvariant`	PartitionCoproduct layout-width invariant: coproducts add exactly one tag site beyond the widest operand's full layout. Uses SITE_COUNT (not siteBudget) so nested coproducts whose operands carry inherited bookkeeping do not collide their outer tag with an inner tag site.
`layoutRule`: SITE_COUNT(A + B) = max(SITE_COUNT(A), SITE_COUNT(B)) + 1
`CoproductTagEncoding`	`LayoutInvariant`	PartitionCoproduct canonical tag-pinner encoding: each variant's tag-pinning constraint is the canonical Affine form with all-zero coefficients except a single 1 at tag_site, with bias 0 for the left variant and bias −1 for the right. Semantically equivalent but non-normalized encodings (coefficient ≠ 1, or alternative biases, etc.) are rejected at mint time because content-addressing depends on the normalized byte pattern, not the semantic equivalence class.
`layoutRule`: Affine { coefficients: [0,…,0, 1 at tag_site], bias: 0 (left) \| −1 (right) }