Evidence Streams

Discover, ingest, monitor, and verify schema-bound ordered evidence while keeping source authentication, structural validity, chain integrity, operational health, and downstream business authority as explicitly separate conclusions.

BUSINESS CASES

Where this module fits

audit and provenance event ingestion
schema-governed evidence exchange
bounded timeline and integrity verification
source enrollment and liveness monitoring
alert and quarantine triage
rule-based operational observation
commitment handoff into separately authorized business workflows

PRIMARY CONSUMERS

Who integrates it

auditors and assurance teams
event producers and processors
verification and monitoring agents
compliance, settlement, governance, and operational systems consuming evidence

PREREQUISITES

What must exist first

evidence:read for implemented monitoring reads and separately promoted evidence write scopes for mutations
a bearer-derived workspace and stable owner-scoped stream identifier
an active committed schema with bounded complexity and compatibility policy
an enrolled proof-of-possession source with current signing policy for ingestion
caller-owned rules for freshness, chain continuity, source assurance, factual confidence, and downstream fitness

RECOMMENDED WORKFLOW

Compose the module safely.

01
ingest live OpenAPI, authenticate to the bearer-derived workspace, and discover stable stream and schema identifiers
02
load the exact executable schema and verify its canonical commitment before producing or interpreting evidence
03
reconcile enrolled-source lifecycle, last activity, rejection counts, aggregate health, open alerts, and quarantine posture
04
when ingestion is promoted, canonicalize, sign, and append one replay-protected event or a bounded explicitly atomic batch
05
verify payload, previous-chain, chain, and server-signature commitments across enough history to establish continuity
06
triage alerts and quarantine through separately authorized versioned decisions without changing the underlying evidence
07
apply any downstream payment, settlement, disclosure, governance, custody, or operational decision only through that domain's own current policy and authority

AGENT INTEGRATION

Machine-use boundaries

Evidence records describe observations and processing outcomes; they do not authorize the actions they mention.
Resolve stable stream, schema, source, event, alert, quarantine, and rule identifiers before interpreting or changing workflow state; names and messages are presentation context.
Verify payload, previous-chain, chain, schema, source-signature, and server-signature commitments under the applicable key policy; a bounded page may not contain the prior link needed for complete continuity.
Treat ACTIVE sources, source_authenticated events, ACCEPTED ingestion, OPEN or RESOLVED alerts, quarantine decisions, and OPERATIONAL health as narrow workflow posture—not calibration, completeness, factual truth, regulatory approval, or permission for settlement, payment, trading, governance, disclosure, safety control, or custody.
Keep payload and metadata cleartext, rejected content, source private keys, credentials, precise locations, replay nonces, attachment ciphertext, arbitrary alert values, and owner identifiers out of shared prompts, URLs, logs, analytics, caches, and agent memory.
Publisher enrollment is not factual endorsement, subscriber access is not downstream business authority, stream pause is not event deletion, alert resolution does not retroactively validate evidence, and quarantine disposition does not release or replay a payload.
The six legacy /api/v2/streams/* POST routes are bodyless 501 migration markers. Their generic whitelist, blacklist, toggle, and caller-selected ownership shapes must never be translated into a modern request.
Never call a planned mutation until its exact operation appears in the live production OpenAPI contract.

Register only production-listed routes as executable tools, and re-fetch the deployed OpenAPI before generating or sending a request. Source-ready routes awaiting deployment are preparation references; planned contracts are non-executable.

MODULE CONTRACTS

Every mapped endpoint

Each operation states whether its request shape is authoritative in OpenAPI, reviewed as a planning profile, or intentionally left as an outline pending an owner schema.