Contracts and sources

The company model is written down as a contract: a versioned JSON document that Harness validates and enforces. Only an owner installs one.

#Sources

Each system is declared as a source with an authority level, the facts it may assert, a mode (pushed or pulled) and a maximum age. An observation that names a fact outside the source's allowance is refused at ingest.

POST /api/businesses/{business}/sources/{source}/observations

{ "entity": "Supplier", "subject": "supplier-b", "fact": "Supplier.active", "value": false,
  "evidence_ref": "supplier_registry:supplier-b:active", "effective_at": "…", "observed_at": "…" }

Note Today the only permitted pull binding is a loopback synthetic source. Live connectors are planned, and each real source needs its own authorization.

#Source authority

Two sources may assert the same fact. The contract decides which is authoritative, and a read reports a conflict rather than picking silently. An object with a conflicting or stale observation is listed as undecidable, with the reason.

#Canonical identity

Each entity may declare a match key and the sources that carry it. Records sharing the key resolve to one object with an obj_ identifier; every source ID that maps to it is remembered. Objects that share no declared key stay distinct. Merge and split are owner-attested, and each proposal records the identity revision it was evaluated under.

#Comparing contracts

amalgament-harness validate CONTRACT.json
amalgament-harness diff-contracts BEFORE.json AFTER.json

diff-contracts requires both files to validate and lists the structural paths that changed. It does not assess migration compatibility.