DESIGN CONTRACT
Project boundaries
A small, independent format. External search engines and datasets do not become hidden product requirements.
Responsibilities of the supply format
Tessembly follows Clearra-like queue inputs and structure to parse, validate, normalize and exchange supplies, supply state, visibility and D/U relations. F1/F2 are implemented supply constraints, not review plans.
Setup selection, PC objectives, metric values, policy graphs and dataset contracts are outside supply. Q1/M1 and MATCH are not added. Existing reference/select records remain compatibility data, not a gateway to policy expansion.
What the consumer provides
PC search, geometry, rotations, reachability, gameplay, see-n evaluation, weighted sampling, stateful supply execution and replay reconstruction belong to external programs. They are not an internal unfinished-feature backlog.
Conformance tools are for external developers
tessembly-conformance is an independent developer tool for a consumer application’s real I/O boundary. It is not a required runtime or search engine. Running it against the reference CLI in repository CI is a regression check of the shipped tools and reference implementation.
Finite test success is not a universal correctness proof or certification. Connect real application paths, not a test-only alternative parser. Consumer developers provide GUI E2E adapters.
Capabilities and semantic versions
RFC3 fixes < as earlier. F1/F2 capabilities are filters.logic.v1, filters.count.v1, filters.window.v1 and filters.occurrence.v1. Unknown mandatory relations must fail. Wire=1/semantic=3 and npm Wasm ABI=3 are different contracts.
Pages publishes implemented-user documentation, not unimplemented proposals. Use migration for RFC2 data; never infer the historical version of an unlabelled snippet.