OntologicalHarness
Platform

One boundary between intent and action

The harness sits between whoever is acting and the systems of record. Nothing changes without passing through it.

Agents and humans follow the same rules. Both hold roles, both pass the same checks and approvals, and both leave the same audit record. Revoke a role and whoever held it, person or agent, stops.

The layers

Each layer does one job and hands off to the next.

Understand path through ontology and semantic layer, act path through rules, action engine and audit trail
How agents and humans understand and act.
Layer

Governed data

The data the business already trusts, with access tied to roles. Masking and row-level policies apply from the first row.

Layer

Ontology

Entities, relationships and definitions. An expense report has line items, belongs to an employee and is charged to a cost centre.

Layer

Rules as data

Thresholds and conditions are rows, not code. Each rule has a severity, an owner, an effective date and a reason.

Layer

Action engine

The only route to change anything. Requests are checked and approved, then executed and logged.

Layer

Semantic layer

Questions are answered in business terms from the same definitions the rules use.

Layer

Agents and humans

Both act as roles under the same gate. An agent is not a special case.

The governed action path

Every change follows the same steps. A BLOCK result ends the request before anything is written, and checks run again at execution so a limit that changes between preview and commit is not missed.

Request, dry run, precondition checks, approval, execute, audit record, with BLOCK stopping at checks
The governed action path.
BLOCK

Hard stop

The action cannot proceed. Example: submitting an expense over the receipt threshold with no receipt.

WARN

Flag and continue

The action proceeds with a visible flag and a reason on record. Example: a meal over the daily cap.

Approval

Separation of duty

Routing rules prevent someone approving their own request or their own rule change.

Rules as data

Because rules are data, changing a limit is an edit with an owner and a date, not a deployment. The old version stays, so you can say what was true on any day.

A rule with versions, owner, effective dates and reasons feeding the engine
A rule with its version history.

Where maturity comes from

Most teams start with policy in documents. The harness moves you up the ladder one step at a time.

Four steps: documented, modeled, enforced, learning
The maturity ladder.

Learning that cannot rewrite its own rules

The harness watches overrides, repeated warnings and near misses. It proposes a change and cites the evidence. A named steward reviews it. Only then does a new rule version take effect. The agent that benefits from a loosened rule is never the one who approves it.

A kill switch that already exists

Because agents hold roles, revoking the role stops the agent. No special shutdown path is needed, and it does not depend on the agent's cooperation.

Audit you can verify

Each action record links to the one before it with a hash. If someone edits history, the chain breaks and the break is detectable.

Put a boundary around what your agents can do

We are onboarding a small group of early access teams. Tell us what you want to ground, automate or audit.

Request early access