Skip to content

[M2/P0] Add governed commands for bindings, extents, verification, and reference imports #185

Description

@samovers

Parent: #167
Depends on: #171, #172, #173, #174, #175, #176, #178, #179, #180, #184
Serbia consumer: #162

Problem

M2 defines ReferenceSnapshot, ExternalRegistryVerificationTrace, AgronomicIdentityBinding, and PartialExtent, but several production-capable creation paths stop at helpers or write directly to storage:

  • reference imports can insert snapshots/cache rows and gate logs without one authenticated command result, complete idempotency receipt, or RuntimeBundle pin;
  • SI binding helpers return payloads while tests and demos complete the path with raw inserts;
  • PartialExtent is principally exercised through direct fixtures;
  • evidence insertion has bespoke paths, separately owned by [M1/Security] Add governed EvidenceRecord ingestion and a closed promotion matrix #179;
  • the runtime cannot yet demonstrate one governed traversal from preserved source artifact to snapshot, verification, binding, local identity, accepted operation, and immutable result.

This makes the schema look more complete than the executable command surface.

Goal

Add the smallest closed, public command set needed to create and revise M2 reference state through the Kernel control plane. Adapters/providers translate source material; they do not own storage semantics.

Command inventory

Implement and document exact request/result contracts for:

  1. import a ReferenceSnapshot from a preserved source artifact;
  2. verify an external record and create or revise its AgronomicIdentityBinding atomically;
  3. create or revise a PartialExtent against an accepted parent scope.

EvidenceRecord ingestion must use #179. If observations or measurements have no governed command in the accepted M2 capability, report them as unsupported rather than adding speculative APIs.

Common command invariants

Every command:

ReferenceSnapshot acceptance criteria

  • The request binds preserved source artifact bytes or an immutable artifact digest, source identity, resource/vintage identity, acquisition time, claimed effective interval, parser identity/version/digest, and RuntimeBundle.
  • Successful import persists the immutable snapshot, exact source/parser provenance, record count, diagnostics, and any derived lookup accelerator in one atomic result.
  • Accelerators are disposable and reconstructable from the immutable snapshot; they are never the sole proof.
  • A changed artifact, parser, source vintage, tenant, or RuntimeBundle cannot collide with an earlier idempotency result.
  • Partial parse, timeout, malformed source, duplicate vintage conflict, and storage failure leave no accepted partial snapshot/cache.
  • Currentness is evaluated by explicit policy at use time; import success alone never claims current or authoritative truth.

Verification and binding acceptance criteria

  • Verification trace and binding revision commit atomically and bind the exact local subject, external record, source snapshot/artifact, verifier identity/version, evidence set, decision, validity interval, knowledge time, profile, and RuntimeBundle.
  • The binding role and identity family follow [M2/P0] Close the Core semantic reference graph #184; product identity and regulatory authorisation cannot be conflated.
  • Revision/supersession yields at most one accepted current binding for the exact tenant/local-subject/scheme/role key, with deterministic concurrent behavior and complete lineage.
  • A failed or insufficient verification creates the governed refusal/trace required by policy but no accepted binding.
  • Real resolver-produced data can traverse this command and the public operation path without fixture-only inserts.

PartialExtent acceptance criteria

  • Creation/revision proves exact tenant, parent identity, anchor/geometry basis, containment, temporal applicability, lifecycle state, evidence/provenance, and RuntimeBundle.
  • Unsupported geometry, overlap, uncertainty, or containment semantics refuse explicitly.
  • Revision retains immutable history, exact supersession lineage, and invalidates every affected materialization/output dependency.
  • Concurrent incompatible revisions have one deterministic winner and a governed loser result.

Provider boundary

  • Define a narrow provider-facing translation interface and a provider-independent Kernel command boundary.
  • Fake providers exercise the common contract; the existing SI provider proves parity.
  • RS4: Implement governed Serbian reference and evidence ingestion #162 must consume this mechanism for Serbia later. It must not create an RS-specific alternate importer, verification writer, binding store, or extent mutation path.
  • Scheduling/orchestration is owned by the separate scheduler ticket; this issue supports an explicit/manual/injected trigger only.

Tests

Cover success, replay, conflict, rollback, parser failure, insufficient evidence, revocation race, stale/superseded binding, two-current-binding race, cross-farm, cross-tenant, extent escape, invalidation, deleted accelerator/rebuild, and end-to-end resolver-to-operation traversal.

Direct-insert fixtures may remain only where clearly marked as storage-level fixtures; they do not satisfy command-capability acceptance.

Validation

Run and report:

.venv/bin/python -m pytest kernel/tests/ -q
python3 -m kernel.manifest --verify-generated
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

Codex stop conditions

Stop and report if a command requires inventing a legal/currentness rule, weakening #175/#179 evidence or authority, changing a frozen contract, allowing provider-owned storage mutation, or claiming a surface merely because its schema/helper exists.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    tracking-epicProgramme containing multiple independently reviewable capabilities; owns no implementation PR.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions