Skip to main content
delta/mandate
v0.4 draft

System architecture & flow

End actors on the left drive the request. The premises split sits to the right: delta-hosted services on top, client on-prem on the bottom. Numbered arrows trace the workflow.

NEUTRAL · END ACTORS
Autonomous

Agent

Searches for a solution that satisfies the user's intent. Submits a proposal to the Guardrail Prover.
Human

User

Creates the intent. Signs it before submission to Server.
DELTA · HOSTED
Delta serviceDelta

Orchestrator

Accepts signed intent & solution. Orchestrates the Evidence Layer and ZK Prover, assembles the composite Proof and streams it to the Verifier. Manages client-authored Templates.
JSON APIgRPCTemplate management
Delta serviceDelta

Intent Prover

Produces a ZK proof (to be embedded inside the composite Proof) which proves that the user's intent was satisfied by the agent's proposal.
gRPC
Delta serviceDelta

Evidence Layer

On request, it pulls the required raw data from Server and returns it re-structured in the evidence schema.
CLIENT · ON-PREM
Client-owned

Server

Application server. Hosts the UI the User interacts with, owns intents (uuid-keyed), relays signed intents to GP, and receives verified proofs.

Its operator is assumed to be the Template author.
Deployed on-premDelta

Verifier

Verifies the proof stream. Maintains an audit log. Notifies Server and serves GET /proof by intent uuid.
Storage
Audit log (Proof archive)
gRPCJSON API

Request flow

  1. User → Server. User forms the intent in Server's UI which could get signed client or server side; Server stores the signed intent (uuid-keyed).
  2. Server → GP. Server relays the signed intent to the Guardrail Prover.
  3. Agent → GP. Agent submits a solution proposal for the intent uuid.
  4. Guardrail Prover → Evidence Layer. Guardrail Prover asks the Evidence Layer for scoped evidence for the agent-submitted proposal.
  5. Evidence Layer → Server. Evidence Layer pulls the raw data it needs from Server, if necessary maps it to the evidence schema, and returns as evidence for that particular uuid to the Guardrail Prover.
  6. Guardrail Prover → ZK Prover. Once evidence is read, the Guardrail Prover hands the proving input (intent, evidence, template) to the ZK Prover. The latter returns a ZK proof that guardrails are satisfied.
  7. Guardrail Prover → Verifier. The Guardrail Prover assembles the composite Proof and streams it to the Verifier.
  8. Verifier → Server. Verifies, writes audit log to its internal Storage, notifies Server, serves GET /proof.

Proof object

Composite object assembled by the Guardrail Prover.

signed_intent
Representation of the user's intent with the corresponding signature. Also contains the template_id that corresponds to this intent.
zk_proof
The actual ZK Proof bytes.
proposal
The agent-submitted proposal for the user intent.
evidence
The evidence that was extracted via the Evidence Layer for the submitted proposal.

The Verifier will check the validity of the zk_proof and the correctness of the signature of the signed_intent.

Legend

DeltaBuilt by delta
Built by client
External actor
Background tint indicates where it runs.