Product · Orcher
One control plane between your agents and your systems of record.
Orcher is not a model and not an agent framework. It is the enforced layer those things run through: authority bound before execution, the action verified against the record, the data boundary held, the cost ceiling respected, and the evidence written where nobody can quietly edit it.
Seven components · two layers · metered in Verified Execution Cycles
Orcher — seven components, two layers
Fig. ORC-02
Layer 1 · Accountability
C0
Directive Interface
Where intent enters, attributed.
C1
Role Identity Fabric
Authority bound to a person.
C2
Logic Scrubber
Pre-commit verification.
C3
Immutable Audit Ledger
Hash-chained evidence.
Layer 2 · Operations
C4
Data Control Gateway
Data boundary and redaction.
C5
Cost Governance
Routing and spend ceilings.
C6
Observability
Cross-provider execution telemetry.
Features
Seven components, each enforcing one thing in the execution path.#
Layer 1 gates a directive in sequence before anything commits. Layer 2 runs continuously across every task, every provider, and every hour of the day.
Layer 1 — sequential, gating
Directive Interface
Plain language becomes the permanent record of what was asked.
Layer 1 — sequential, gating
Role Identity Fabric
Binds the directive to a human and a role, cryptographically and revocably.
Layer 1 — sequential, gating
Logic Scrubber
Verifies the proposed action against systems of record before commit.
Layer 1 — sequential, gating
Immutable Audit Ledger
Hashes the verified action permanently. Evidence, not logs.
Layer 2 — continuous, non-blocking
Data Control Gateway
Training exclusion and data boundaries verified before routing.
Layer 2 — continuous, non-blocking
Cost Governance
Routes by stakes and halts runaway loops.
Layer 2 — continuous, non-blocking
Observability
Real-time cross-provider trace: which model, which role, what cost, what outcome.
Use cases
Where an enforced control plane changes the outcome.#
Every one of these is a workflow where the question after the fact is not 'what did the model say?' but 'who authorised this, and can you prove it?'
Claims and case adjudication
An agent drafts the determination, the Logic Scrubber checks it against the policy record, and the adjudicator's own authority is what commits it.
Financial close and reconciliation
High-volume matching runs on cheap models; anything that moves a balance is routed up and bound to the controller who signs the close.
Clinical operations and prior authorisation
Patient data never crosses a boundary the Data Control Gateway has not verified, and training exclusion is enforced before routing, not promised after.
Contract and obligation review
Every clause finding carries a hashed evidence entry naming the model, the role, and the record it was checked against.
Supply and procurement execution
Concurrency and recursion ceilings stop a runaway loop from issuing a thousand purchase actions while a human is asleep.
Regulatory evidence and audit response
Export the ledger for a regime-specific window instead of reconstructing what happened from application logs.
Pricing
Metered in Verified Execution Cycles, not tokens.#
One cycle is one directive: role bound, action verified, boundary checked, cost recorded, evidence hashed. You pay for governed work that completed, not for text a model generated.
Pilot
One workflow, one role, one system of record.
- A single directive class instrumented end to end
- All seven components engaged
- Evidence package exported at the end of the pilot
- Founding-team engineering contact
Department
A function's worth of directives under one role model.
- Role-scoped authority mapped to your delegation model
- Budget ceilings per role and directive class
- Cross-provider observability and cost attribution
- Quarterly evidence review
Enterprise
Control-plane deployment across regulated operations.
- Multi-jurisdiction boundary and training-exclusion enforcement
- Regime-specific evidence export
- Dipp Intelligence retained in your own estate
- Named accountability model reviewed with your risk function
1
directive per Verified Execution Cycle
7
components engaged on every cycle, including in Pilot
0
tenant records released for third-party model training
100%
of verified actions written to the immutable ledger
Talk to the founding team
Tell us the workflow, the role that answers for it, and the system of record it touches. We reply with how Orcher would govern it — or tell you plainly if it is not a fit yet.
Follow the research
New Orcher articles, field notes and control-plane research, sent as they publish.
Orcher article updates
No product marketing — research and release notes only.
Questions
What people ask first.#
What is Orcher?
Orcher is an agentic control plane: a layer between your AI agents and your systems of record that binds each directive to a named human role, verifies the proposed action before it commits, enforces your data boundary, routes work by stakes under a cost ceiling, and writes a hashed evidence entry for every verified action.
How is Orcher priced?
Orcher is metered in Verified Execution Cycles — one directive, role-bound, verified, and permanently recorded — across Pilot, Department and Enterprise deployments rather than by token volume.
Does Orcher replace our model provider?
No. Orcher is provider-neutral. It routes each task to the model that matches its stakes and records which provider executed it, so you can change providers without losing the evidence trail.
Is enterprise data used to train third-party models?
No. The Data Control Gateway verifies training exclusion and the enterprise data boundary before a task is routed, and refuses the route when a provider cannot satisfy it.
Autonomy at machine speed, with someone still accountable for it.
Press and analyst enquiries reach the desk at comms@dippai.com. Everything else starts with a briefing request.