Architecture

How the open-source demo works

Instrata orchestrates a DSAR from consumer intake to an approved action. The agent handles search and reasoning; humans hold every gate that produces a side effect. Below is each layer of the pipeline.

01
Intake
Portal form → verified request
02
Orchestration
Plans steps, invokes tools
03
Agent tools
Read-only search & reasoning
04
Approval gate
Human sign-off required
Every step writes to the evidence & audit layer
1

Intake

The consumer-facing portal captures request type, identity, jurisdiction, and verification details. Each submission is normalized into a request record and placed in the operator queue with an SLA clock derived from the applicable jurisdiction.

Request recordtype, consumer, jurisdiction, verification state
SLA clockstatutory deadline set on receipt
Queue placementstatus = new, awaiting verification
2

Request orchestration

Orchestration turns a verified request into a plan of read-only steps. It decides which source systems to query, invokes the agent's tools in sequence, and collects results and reasoning — without ever performing an external action on its own.

plan = orchestrate(request) → verify_identity() → search_sources(identity) → reason_matches(results) → propose_action() // gated, not executed
3

Agent tools

Tools are the only way the agent interacts with data, and each is explicitly typed as read-only or side-effecting. Read-only tools run freely and are logged; side-effecting tools are registered as proposals that require approval.

search_sources()read-only lookup across connectors
reason_matches()explain confidence per record
propose_action()draft a gated side effect
4

Source-system connectors

Each connected system — billing, CRM, support, marketing — implements a small connector interface. Connectors declare their search capability and mark whether they can produce side effects, which the runtime always treats as gated.

registerConnector("crm", { search: async (identity) => { /* read-only */ }, sideEffects: "gated", // never auto-run audit: true })
5

Evidence & audit layer

Every input, tool call, result, reasoning step, and human decision is appended to an immutable audit trail keyed to the request. The evidence log is what makes a completed DSAR defensible on audit — it shows exactly what happened and who decided it.

Append-onlyentries are never edited or deleted
Attributedeach decision records the operator
Exportablefull trail attaches to the request
6

Approval gates

A gate sits in front of every side effect. When the agent proposes an action, the operator sees the reasoning, the evidence, and the exact operation, then approves, rejects, or requests changes. Only an approval releases the action for execution.

action.status = "proposed" if (operator.approves(action)) { execute(action) // email / export / delete audit.append("approved", operator) }
No side effects without human approval
The agent's tools are read-only. Any operation that leaves the system — email, export, deletion — is registered as a gated side effect and cannot run until an operator approves it in the dashboard.