[M2/P0] Close the Core semantic reference graph

[samovers]

Parent: #167
Design dependency: #168
Implementation dependencies: #170, #171, #173, #174
Database carrier prerequisite: #174

Problem

M2 has the right domain nouns, but the executable reference graph does not yet prove that an accepted operation is one coherent semantic statement.

At the review baseline:

• the submission/assertion subject and time can disagree with the ExecutionRecordPayload subject, interval, and extent;
• the real product-authorisation resolver emits a REGULATORY_AUTHORISATION binding while the active operation path requires a CROP_PROTECTION_PRODUCT binding, so resolver-produced data cannot satisfy the same path demonstrated by direct fixtures;
• operation materialRef, AppliedResource identity, material quantity, product binding, crop/cycle, equipment, and target extent are not closed into one exact graph;
• binding selection can degrade to first-match behavior and does not consistently prove exact role, local subject, lifecycle/currentness, profile/bundle, or promotion lineage;
• external identity is represented through three different mechanisms: embedded identifiers, AgronomicIdentityBinding, and bare scheme-prefixed values;
• interval ordering, event-time coherence, extent containment, and ambiguous reference aliases are not completely enforced.

A schema-valid payload is therefore not yet enough to prove a semantically valid operation.

Required decision record

Before implementation, write one reviewable M2 semantic map covering:

1. the authoritative local identity for Farm, Field, CropCycle, AppliedResource, Equipment, and any other accepted operation subject;
2. which external identifiers are embedded attributes versus governed bindings, with one rule per identity family;
3. exact reference roles and cardinalities for every accepted operation class;
4. the relationship among top-level subject/time/scope, carrier subject/effective interval/extent, and materialized state;
5. lifecycle/current-binding and ambiguity rules;
6. the role distinction between product identity and regulatory authorisation;
7. the supported extent-containment and temporal-applicability model.

Do not silently edit frozen v0.1 law or extracted contracts. If the accepted contract cannot express the required invariant, stop and open an explicit ERRATA/RFC or versioned-candidate ticket with migration and compatibility consequences.

Acceptance criteria

• Top-level subject, farm/field scope, and event time equal or are deterministically derived from the carrier; any mismatch refuses with a stable problem code.
• Operation references resolve to exact tenant-local identities. An external binding attaches to a local identity and never substitutes for AppliedResource, Equipment, Field, or CropCycle.
• Each operation class has one executable role/cardinality matrix. Missing, duplicate, extra, or wrong-role references refuse.
• Product resolution distinguishes product identity from regulatory authorisation and requires the exact roles the operation policy needs; no first-match semantics remain.
• Every binding proves exact tenant, local subject, identity family, scheme role, accepted lifecycle state, profile/RuntimeBundle, validity/knowledge cut, and promotion/supersession lineage.
• The crop binding matches the referenced CropCycle; material quantities match the referenced AppliedResource and its accepted product bindings; equipment matches the farm, type, and lifecycle required by the operation.
• Referenced extents prove the required anchor/parent relationship, temporal applicability, and containment in the target scope. Unsupported partial-overlap semantics refuse rather than approximate.
• Effective interval start is not after end, and event-time/effective-time coherence follows the rule accepted in [M1/ADR] Specify valid-time and knowledge-time semantics #170.
• Canonical reference fields are unambiguous. Compatibility aliases, if retained, normalize to one representation and contradictory aliases refuse.
• Consume [M1/Security] Enforce tenant isolation and record-graph integrity in PostgreSQL #174's neutral tenant/batch/lane reference carrier and add the accepted extraction/path/kind/cardinality enforcement through an immutable forward migration. [M1/Security] Enforce tenant isolation and record-graph integrity in PostgreSQL #174 does not implement or claim this semantic matrix.
• Hostile substitution tests cover same-farm wrong subject, cross-farm, cross-tenant, wrong role, stale/revoked/superseded binding, multiple-current bindings, crop mismatch, resource mismatch, equipment mismatch, extent escape, and temporal mismatch.
• Existing valid SI scenarios remain assertion-equivalent except where a fixture was proving an invalid graph; every changed fixture is documented as a corrected invariant, not a policy expansion.

Validation

Add focused unit, property, and end-to-end tests through the public submission path. Include at least one fixture produced by the real resolver/verification path rather than raw direct inserts.

Run and report:

.venv/bin/python -m pytest kernel/tests/ -q
python3 conformance/ofarm_pkg_contract_check.py
git diff --check

Use the repository-supported equivalent if the documented virtualenv is unavailable and report the exact command.

Boundaries

• No Serbian law, source, adapter, profile, route, or activation work.
• No manifest, ActiveArtifactSet, or affirmative capability-claim change.
• No PWA, M3, or M4 work; M3.x/M4.0: Operational Action Surface descriptor layer #153-Backlog plan: Reconnect OFARM2 app surfaces to canonical Layer 6 archetypes/templates/interaction specs #156 remain parked.
• No UI or new operation family.
• No silent canonical-law, extracted-contract, or schema mutation.
• Do not weaken evidence, authority, temporal, or tenant checks to preserve an invalid demo.

Codex stop conditions

Stop and report if closing the graph requires changing law, inventing a country rule, guessing an ambiguous contract meaning, accepting multiple-current bindings, or widening a runtime capability.

[samovers]

Tracker-only disposition: this issue is marked needs-refinement rather than prematurely classified as a Delivery issue or Tracking Epic. The deciding test is whether identity closure, product/authorization role closure, extent containment, and temporal coherence share one authority, threat model, and atomic rollback story.\n\nWhat is next: perform that boundary check before opening any implementation PR; keep one Delivery issue only if the whole graph is one coherent capability, otherwise reclassify and split it.

[samovers]

Backlog reconciliation against main at a1e2d343b59a5715e07fcb550a459b61dc6541da

This issue remains necessary, but it is not one Delivery issue. It combines several independently reviewable outcomes: product identity versus regulatory authorisation, operation reference roles/cardinalities and carrier coherence, binding identity/currentness/lineage and alias rules, and extent/temporal containment.

The current executable mismatch is still present: the SI resolver emits REGULATORY_AUTHORISATION, while the operation validation and sufficiency path looks for CROP_PROTECTION_PRODUCT. Direct fixtures therefore prove a path that resolver-produced data does not.

The issue is now classified as a Tracking Epic. No implementation PR should target #184 directly. Create one complete Delivery child only when its semantic decision and dependency inputs are ready; do not create a decision-only or fixture-only companion PR.

What is next: use the concrete product-identity/authorisation mismatch to define the first end-to-end child when #184 becomes the active workstream.