Contract first
A machine-readable Component contract gives every target and tool one public surface to satisfy. Generation removes mechanical translation, and validation turns drift into a concrete failure instead of relying on reviewers to notice divergence.
The contract owns obligations, not rendering internals. React and Flutter implementations remain free to use their platform's appropriate component structure, rendering, semantics, and lifecycle mechanisms.
Sources for block 1: product-component-contract-term, projection-norms
Target-neutral assembly
Composition records assembled UI independently of React or Flutter syntax. Stable node identity and typed bindings let layout, behavior, editing, generation, and validation refer to the same structure.
Screens, Shells, and Composition-backed Components reuse one assembly model while retaining different identity and ownership rules. This keeps application structure distinct from reusable Component contracts.
Sources for block 1: product-composition-term, studio-composition
Shared semantics, native hosts
The shared Rust core makes behavior and motion results portable across WebAssembly and Dart native FFI. Host adapters supply platform inputs and apply outputs; they do not independently reinterpret the semantic contract.
This boundary concentrates deterministic logic while allowing React and Flutter to remain native host environments rather than lowest-common-denominator renderers.
Sources for block 1: shared-runtime-topology
Foundation and parity
Schemas, generators, compatibility facts, and validation witnesses are reusable infrastructure. Building them before multiplying Components lowers the marginal cost of every later addition and makes failures explainable.
Parity means conformance to declared contracts and obligations. It does not require identical source code, identical platform APIs, or a claim that an unreleased channel is available.
Sources for block 1: projection-norms, catalog-bundle
Private and shared Catalogs
A product-private Catalog uses the same manifest, contract, Composition, Behavior, and validation model as a broadly shared Catalog. Reuse and promotion are therefore explicit ownership decisions rather than format migrations.
Sources for block 1: product-catalog-term