[earthshiner]

What

Release 2.0.0 of the consumer contract, prepared and not tagged. This PR is based on #77 (feat/portable-design-standards) and must merge after it; its diff against that branch is the whole of this change.

It does two things.

1. Publishes the contract. A versioned release bundle (release/v2.0.0/: contract, bindings, examples and conformance-check indexes), a compatibility policy and a migration note, and a deployed StandardDeclaration so a deployment says which version of the standard it implements. A 1.1.0 was prepared earlier and never tagged; its content is part of this release.
2. Closes four gaps in the metadata an agent reads, on Postgres, DuckDB and Teradata:

   • Stable identities. Logical and placement-independent (domain.ticket, domain.ticket:current); physical location sits in separate columns.

   • Composite-key grouping. Keys and relationship column pairs are ordered rows (KeyColumn, RelationshipColumn); a relationship is the join group. A composite natural key, which was a comma-joined string, is now its ordered rows.

   • Ordered paths. RelationshipPaths returns one row per step and key position; the concatenated join_path string is removed.

   • Access-column mappings. AccessColumn gives one mapping row per output column of a consumer view.

   • Composite joins can be declared. A design author writes [-> Target.attribute] on each source attribute; attributes of one entity pointing at one target form one join in declaration order, and [join: name] separates two joins to the same target. The lint requires the named attributes to be exactly one key of the target, of matching types. The standard declares its own: ValidationArea to ValidationRun on three columns. The resolver now also registers the joins of standard-owned relations, so every product's relationship catalogue and path view are larger than before (23 relationships in the IT Service Desk reference, up from 7).

It also adds the comment-coverage check (every container, object and column carries a comment) and the invariants INV-SEMANTIC-016 to 020.

How it sits on #77

The Semantic relations are defined in design/modules/semantic.md and placed by the resolver, so the design change creates the new relations on every platform. The resolver derives identities, keys, relationship pairs and one consumer-view column list once; each binding registers them, creates the views and declares the checks. binding.py and render.py gain two check scopes (contract, product).

This is a breaking change

Removed attributes, renamed identities, and a rows-based path view. Business data tables and the Domain module's keying and temporal mechanics are unchanged. There is no migration script: a 1.x deployment re-registers. release/migrations/v2.0.0.md gives the identity rule and the steps.

How to Test

python -m pytest tooling -q
python tooling/release/build_release.py --check
python tooling/validation/design_lint.py

About three minutes. Result here: everything passes except 2 failures, with the Postgres and Teradata engine tests skipped. The two failures are present on #77's own head (two Teradata template checks on catalogue-interface), unchanged by this PR. The 60 skips are the Postgres and Teradata engine tests.

Verification, stated plainly

Platform	Evidence
DuckDB	Reference products deployed; every rendered check run. A test breaks each of the five contract checks and the coverage check, and others cover a composite natural key, a composite join, the mappings and the declaration. Conformance report regenerated: 46 passed, 0 failed, 0 skipped
Postgres	Renders and shares registration with DuckDB; a static audit finds every schema, table, view, function and view column commented. The engine tests are written but not run (no POSTGRES_TEST_DSN)
Teradata	Renders under strict undefined variables and passes the dialect tests. No DDL, view or check has been run on a Teradata system. Risks I could not check: REGEXP_SIMILAR semantics; REPLACE VIEW with a column list and LOCKING; COMMENT ON DATABASE/PROCEDURE; and the size of the unrolled RelationshipPaths view (about 54,000 characters, ten branches)

Review points

• Merge order. After Feat/portable design standards #77. The CONFORMANCE.md for Postgres and Teradata are out of date (this PR adds tests) and need regenerating on a machine with those engines; I regenerated only DuckDB's, to avoid recording their engine tests as skipped.
• Teradata path view. It follows Feat/portable design standards #77's own approach (one branch per path length) but is much larger. If Teradata rejects its size, a small helper view for the edges would shrink it, at the cost of one more standard-owned view.
• Teradata registration. The registration template is now shared with the other bindings, so the new rows are populated at deployment.
• Composite references. A reference attribute carries one source column, so a reference to a composite identity pairs the first column and reports the rest as a gap.
• Not tagged. Tag v2.0.0 after the Teradata live run.

Checklist

• Commit messages follow discipline
• No secrets committed
• Tests pass, apart from the two failures already on Feat/portable design standards #77
• Documentation updated (design, platform READMEs, release notes, DuckDB conformance report)
• No new file types needing .gitignore changes

🤖 Generated with Claude Code

[NathanG-TD]

the metadata contract is a great addition.