Data Flow

How data actually moves through Hoziron — from an inbound trigger through competency/workflow execution to a mediated, billed outbound write at a carrier system of record. Grounded in ADR-042 (outbound mediation seam), ADR-047 (unified outbound egress), ADR-049 (unified PII policy authority), ADR-043/046 (billable event detection), and ADR-061 (inbound ingress authority).

End-to-End: FNOL Trigger to Billed Carrier Write

Two structural facts this diagram encodes:

  1. There is exactly one mediated egress, regardless of transport. MCP tools/call, direct REST, and direct SOAP carrier writes all express as the same transport-agnostic OutboundCall{tool_name, target_server, arguments} and cross the identical CoreOutboundMediator.mediate() chokepoint (ADR-047 generalizes the ADR-042 MCP-only seam to every carrier transport). A structural test (the "C3" invariant) asserts there is exactly one call site to the underlying transport and that mediate() precedes it — this is enforced at build time, not by review discipline.
  2. Billing and PII are the same seam, not two. CoreOutboundMediator resolves destination trust once and does two things with it: transforms the arguments (hydrate for a trusted SoR, tokenize/reject otherwise) and — on a complete write signature to a licence-specified target — draws credits (ADR-043, amended by ADR-046 to bill per value-event signature rather than per individual write). A stranded, incomplete write (RunState::Escalated) is unbilled by the same rule that makes it PII-safe: partial completion never crosses the line that triggers hydration or billing.

Inbound PII: One Unified Carrier Policy (ADR-049)

PII policy is not agent-configurable. It is a single operator-owned, file-sourced (carrier-pii-policy.toml) policy with two dimensions:

  • Unconditional substrate: any PII bound for a cloud LLM or an unlisted tool destination is tokenized before egress, always — this is not a configurable choice.
  • LLM dimension — binary: local_only (named types may not leave the box even tokenized) or the default cloud_permitted (tokenized form may reach a cloud model).
  • Tool dimension — default-tokenize, with explicit per-(destination, PII-type) hydrate or reject escalations. There is no path to hydration except an explicit rule.
  • No runtime mutation. There is no PUT /agents/{id}/trust-policy or agent-level set_agent_trust_policy API — agents have no input into PII egress at all. Deny-by-default extends to API responses too: hydration back to the calling client only happens if "api" is explicitly in the policy's trusted destinations (ADR-027, generalized by ADR-049).
  • local_only is the sole force-local source for PiiPolicyEngine::evaluate().

Workflow Step-to-Step PII Boundary

Memory Isolation

Cross-agent memory access is a compile-time impossibility at the handle's own API surface — not a runtime-rejected call. Data crosses agent boundaries only through step outputs, tokenized at each hop.

Provider Interaction and Fallback

Audit Trail Flow (ADR-039, v2 preimage per 2026-07-05 amendment)

Every policy-relevant event — kernel-emitted MechanicalEvent and core-emitted PolicyEvent — lands in one hash chain:

The preimage is length-prefixed, not delimiter-joined, so a byte occurring inside a variable-length field can never be mistaken for the field separator. There is no migration path for a chain built under a different preimage encoding — verify_chain() flags a mismatch at the very first entry as the signature of an encoding mismatch, not tampering.

Credential Flow

Provider credentials resolved during routing are Zeroizing-wrapped end-to-end from AES-GCM decrypt through ResolvedModelTarget to the driver — ResolvedModelTarget carries a manual redacting Debug impl so a derived Debug can never leak the key.

Related: