Orcher · Architecture

Component Schematic v1

One directive, traced from the moment a professional states intent to the moment the record becomes permanent — and the intelligence stays with the firm.

The metered loop of directive, verification, commit and evidence — One directive, traced from stated intent to permanent record.

Orcher Component Schematic v1 — the directive execution path

Fig. ORC-19

Layer 1 · Accountability — sequential, halt-by-default

L0 · Entry
Directive
A professional states intent in plain language, inside a declared role.
C1 · Layer 1 · Gate 1
Directive Interface
Intent is parsed into a scoped, bounded task with explicit limits.
C2 · Layer 1 · Gate 2
Role Identity Fabric
The task is bound to accountable identity and its entitlements.
C3 · Layer 1 · Gate 3
Logic Scrubber
Policy and systems of record are checked before anything commits.
C4 · Layer 1 · Gate 4
Immutable Audit Ledger
The decision path is hashed into evidence that survives challenge.
OUT · Exit
Committed action + Dipp Intelligence
The action executes under verified authority; the record stays with the firm.

Layer 2 · Control — continuous, applied to every stage above

C5 · Layer 2
Data Control Gateway
Data boundary, redaction and no-training guarantees enforced in path.
C6 · Layer 2
Cost Governance
Economic ceilings bound autonomy before spend runs away.
C7 · Layer 2
Observability
One view across every model, framework and agent in flight.

Halt is the default outcomeProvider-neutral executionMetered in Verified Execution Cycles

Orcher™ · Dipp AI Technologiesdippai.com

Fig. ORC-19Orcher Component Schematic v1 — four sequential gates decide whether an action commits; three continuous controls govern data, cost and visibility while it runs.

Layer 0

Entry: a professional states intent.

Layer 0 is the entry point — a human in a role, issuing a directive in plain language. Nothing enters the execution path without one.

Layer 1 · sequential, gating, none optional

Four checks, in order, before anything commits.

L1.1

Directive Interface

Plain language becomes the permanent record of what was asked — before interpretation, before execution.

L1.2

Role Identity Fabric

The directive is bound to a named human and their role, cryptographically and revocably.

L1.3

Logic Scrubber

The proposed action is verified against systems of record in a separate process boundary. 'Will not' becomes 'cannot'.

L1.4

Immutable Audit Ledger

The verified action is hashed permanently. Evidence, not logs.

Layer 2 · continuous, non-blocking

Three controls that run alongside every cycle.

L2.1

Data Control Gateway

Training exclusion and data boundaries are verified before routing; egress is controlled, not asserted.

L2.2

Cost Governance

Routing by stakes, with runaway loops halted rather than invoiced. 40–85% spend reduction in deployment.

L2.3

Observability

Real-time cross-provider trace: which model, which role, what cost, what outcome.

Halt semantics

Nothing partial is ever written.

If any Layer 1 step fails — an ambiguous directive, a revoked role, a reconciliation mismatch against the system of record — the directive halts. There is no partial commit, no compensating transaction to unwind, and no orphaned write for an investigation to discover weeks later. The halt itself is recorded.

This is the difference between a model that will not misbehave and a system in which it cannot. Guardrails persuade; a gating boundary refuses.

Two outputs

Every cycle produces evidence and intelligence.

OUT.A is the verified action and its hashed record. OUT.B is Dipp Intelligence — the verified execution path, retained by the enterprise rather than absorbed by a model provider.

Figure · Orcher™

From “will not” to “cannot”

FIG. P13-02

Control style	Where it lives	What happens under pressure
Prompt or policy text — “will not”	Inside the model context	Degrades with context length, jailbreaks and model swaps.
Guardrail filter — “usually will not”	Alongside the model	Catches shapes of text; cannot check a system of record.
Pre-commit verification — “cannot”	A separate process boundary	The action does not execute unless the gate returns a pass.

Orcher™ · Dipp AI Technologiesdippai.com

Vol. I · p.13From models that will not misbehave to systems that cannot

Cycle metrics

Verified Execution Cycles

OUT.A

Verified action, permanently hashed

OUT.B

Dipp Intelligence, retained by the firm

components engaged per cycle

named human accountable, always

Figure · Orcher™

The Verified Execution Cycle as the unit of value

FIG. P27-01

Dimension	Industry default	Verified Execution Cycle
Unit measured	Seats, tokens, messages	One directive verified and executed to outcome
Evidence produced	Logs that can be edited	A hashed ledger record, 1:1 with the cycle
Failure behaviour	Partial writes, silent retries	Halt — nothing partial is written
What it proves	That the system was used	That the action was authorized and correct

56% of CEOs report no revenue or cost change from AI~25% of programmes deliver the expected returnThe metric of 2025 was users; the metric of 2026 is auditable outcomes

Orcher™ · Dipp AI Technologiesdippai.com

Vol. I · p.27Verified Execution Cycle metrics versus industry defaults

Runtime workflow

Authority per directive.#

Routing is not a developer preference resolved in a config file. For every directive, Orcher resolves who is accountable, selects the cheapest model class that authority permits, carries the data boundary along the chosen route, and hashes the whole decision into one evidence chain that reads the same across every provider.

Authority is resolved before a model is chosen

Who is accountable, and what may they authorize?

The directive arrives with a named issuer. The Role Identity Fabric resolves that professional's current entitlements and binds them to this cycle, so the routing decision is made against a known authority rather than a service account. Anything outside the role halts here — before a single token is spent.

Enforced by

Directive Interface Role Identity Fabric

Emits
A role-bound authorization token scoped to this directive.

The routing decision is a policy decision

What is the cheapest model class this directive's stakes permit?

Cost Governance classifies the workload by stakes, sensitivity and reasoning depth, then selects the cheapest sufficient model class within the ceiling in force for that role. Roughly nine in ten workloads clear on routine classes; frontier capacity is reserved for complex work. The chosen class, the alternatives considered and the ceiling applied are all recorded as part of the decision.

Enforced by

Cost Governance Protocol Stack

Emits
A signed routing decision: class chosen, ceiling applied, rationale.

The data boundary travels with the route

May this payload reach that provider, in that region?

The Data Control Gateway applies data-boundary, redaction and training-exclusion rules to the route that was chosen, not to a default path. If a class is otherwise optimal but its provider cannot satisfy the boundary, the route is refused and the next sufficient class is selected. Consistency across providers is enforced by the gateway, not negotiated per vendor SDK.

Enforced by

Data Control Gateway Integration Fabric

Emits
A per-call boundary attestation: region, redactions, no-training terms.

Every decision lands in one evidence chain

Can this be replayed and defended months later?

The Immutable Audit Ledger hashes the directive, the authority, the routing decision, the boundary attestation and the committed action into a single tamper-evident chain. Observability streams the same run across whichever providers were involved, so one query answers what was asked, who authorized it, where it ran and what it cost — regardless of vendor.

Enforced by

Immutable Audit Ledger Observability

Emits
A replayable, hashed execution record with cross-provider cost and latency.

Interactive · routing simulator

Enter a workload. See where it routes.#

Each workload type carries a different level of stakes, sensitivity and reasoning depth. Select one to see which Orcher component owns the decision, which model class it routes to, which gates run, and what that does to tokens and cost against a frontier-default baseline.

Workload type

Routing decision

Document classification and routing

High-volume intake: label the document, extract identifiers, route it to a queue. No irreversible write, no judgement call.

Decided by

Cost Governance

Routed to

In-house small model

Runs inside the tenant. No egress, lowest unit cost, deterministic latency.

Token reduction

42%

1,800 → 1,044 tokens

Cost per directive

$0.00013

baseline $0.0432 on frontier model

Cost saving

100%

2360ms faster median

Gates that run before commit

Role scope check
Cheapest-sufficient class
In-tenant execution
Hashed record

Stays inside the tenant entirely — the payload never reaches an external provider.

Indicative class prices per 1M tokens: In-house small model $0.12 · Open-weight mid model $0.60 · Commercial mid-tier $4.50 · Frontier model $24.00. Illustrative only; the 4,500× spread across 400+ models and 70+ providers is from The Enterprise Superintelligence Report, Vol. I, p.25.

Output B · Dipp Intelligence

Every verified cycle leaves an asset behind.

OUT.B of the Verified Execution Cycle is Dipp Intelligence — the verified execution path, retained by the enterprise rather than absorbed by a model provider.

Path

The exact sequence that produced a verified outcome.

Role

The authority under which the action was permitted.

Cost

The model tier that actually proved sufficient.

Proof

The hashed evidence a regulator will accept.

Explore Dipp Intelligence Immutable Audit Ledger

The schematic is the product.

Nothing in Orcher is optional decoration; each component exists because a documented failure mode required it.

All seven components Request access