KISMET 0.4 — Authoritative interface mapping and limitations

Candidate status: Offline read-only adapter conformance, not production authority conformance.

Source-inspection evidence

The viroway-ltd/zayaz-docs main-branch material inspected on 2026-10-17 includes:

• content/key-zayaz-features/zar-artifact-framework/zar-core.mdx: ZAR Ruleset Factory uses YAML source, canonicalization and SHA-256 hash-based immutable ZAR references; governed PLAN/APPLY approvals.
• content/key-zayaz-features/zar-artifact-framework/signal-lineage-flow.mdx: describes SSSR -> CSI -> CMI -> USO -> TrustGate lineage and points to zar.signal_registry, zar.signal_csi_binding, zar.uso_instance, and TrustGate telemetry.
• code/associated-files/introduction/database-tables/compute-method-versoning.txt: documents ref_compute_method_registry, ref_compute_method_latest, and fact_compute_executions as the relevant method/execution-table lineage.

These are design specifications, not verified deployed APIs. In particular there was no verified live ALTD inclusion proof endpoint nor registered production trust keys to connect in this candidate.

Required read-only integrations

Boundary	Source-owned semantics	Evidence needed	Current status
KISMET	KEC/KBC/KRC/KPC/KCC canonical identifiers, version and approval	Exact artifact bytes, content digest, build digest, signing authority	Interface only
ZAR	Artifact identities and execution lineage	Hash-based artifact reference, retrieved payload bytes, KXID linkage	Interface only
ALTD	Merkle inclusion and finalised anchoring	Independently verified inclusion path, finalized anchor, trusted ledger root	Not configured
SSSR	Canonical column/type bindings	Immutable selected signal/schema reference and compatibility proof	Interface only
Method registry	Governed method authority/version	Approved applicable method with implementation mapping and effective date	Interface only

ReadOnlySnapshotProvider exports an offline fixture source and is always labelled fixture_only=True. Even a valid signature on a fixture is not proof of a live authoritative event. The UnconfiguredLiveProvider raises explicit verification errors and must never be used to pass a release gate.

Adapter acceptance requirements before AUTHORITY_VERIFIED

1. Retrieve records through authenticated, least-privilege, read-only access to the actual source system, not a developer-supplied JSON claim.
2. Provision independently managed source public-key trust roots with documented rotation and revocation policy; never derive roots from the same envelope being verified.
3. Cross-check versioned KISMET contract status and implementation/guard closure with the execution manifest.
4. Resolve ZAR execution edges and immutable payload bytes; check KXID, hashes, and parent/child provenance against actual records.
5. Verify ALTD Merkle inclusion cryptographically, and query a trusted finalised-anchor source to prove finality. A signed claim state=finalized is insufficient.
6. Verify SSSR type/units, and method registry applicability, using the authoritative record for the execution time.
7. Fail closed on missing or conflicting evidence; report AUTHORITY_UNVERIFIED, never automatically substitute fixture data.
8. Keep Scope 3 external contracts under the domain gate; do not block generic KISMET core validation.

Portable offline export shape (test/migration only)

index.json lists authorities.{kismet,zar,altd,sssr,method}.artifacts and .records, keyed by the requested reference and mapped to local files under artifacts/ and records/. The index is not a trust root. This is a transport adapter test format, not a new ZAYAZ database or API specification.