Lab · In practice

How Taniwha would run in an organisation.

Elsewhere this site explains the idea, the three planes, and how mature each part is. This page shows them assembled: what runs in your environment, where the model sits, what persists between sessions, and who authorises a change.

The thesis this page applies: “We investigate how artificial intelligence can remain useful inside systems where truth, authority and consequence exist independently of the model.” Here, the system where truth, authority and consequence live is your organisation.

Of the three configurations below, one ships today, one is in closed alpha, and the third is a research direction with no experiment registered yet. Every part is labelled with what it is.

The status map The results index

The shape

The gate and the record are the spine. The agent is a participant.

Taniwha sits on the act, not inside the model. Your assistant, your repositories and your CI stay where they are; the gate checks what the assistant proposes, and the record keeps what happened.

Without the agent, the request reaches the model directly and the rest of the drawing is unchanged. That is the first two configurations, and they are the two that are built.

How the parts would run in an organisationA person or team asks for work, either directly of a model or through an agent. The agent is drawn dashed because it is proposed, not built; it interprets the request and briefs the model. The model may run inside the organisation's environment or outside it through a scoped interface. Agent and model produce a proposed act. The act passes through gates that apply permissions and required checks, with institutional records binding at that point. Permitted acts run on the organisation's own systems; what happened goes into the record, and the gate writes a receipt there for every permission and refusal. The record returns to the agent as evidence and never as permission. Refused acts return to the proposer before execution as a typed refusal: a refusal carrying a machine-readable reason, which is also logged.Outside your environment — a hosted model, if you use oneYour environmentstate, records, policy and gates stay herePerson or teamasks for workAgentbeliefs · history · trustTaniwha Engine · proposedModellocal, or hosted througha scoped interfacereplaceableProposed acta change, a command, a draftGatespermissions and checksĀrai · Kete · CI · reviewRecordswhat the organisationhas decidedchanged only by peopleThe recordwhat actually happenedground · Pono · audit trailYour systemsexecute permitted workcode host · CI · deploysasksor directly, with no agentscoped briefdraftproposesrefused — typed, before executionbinds herepermittedreceiptoutcomeevidence, never permission
Target shape for an organisation. A dashed box is proposed, not built. A dashed line is an act stopped before it happened. The model sits on the boundary because it can run inside it, or outside it through an interface that carries a scoped brief out and a draft back. The gates write to the record too: every permission and refusal is logged.

If you arrived from the settlement: Copperhollow is this drawing with a mine instead of a repository. Minds propose, the world adjudicates, the record stands. Kano is the ground that settlement stands on and Hīkoi is how you walk it; Pono is the same contract, deterministic and checkable, pointed at a repository.

Where the boundary sits

Persistent state, records, policy and the gates stay in your environment. A model can run there too, or sit outside and receive a scoped brief through an interface. What may cross that line is decided by policy, not by the model’s confidence.

Why the agent is not the hub

The checks have to hold when the agent is absent, immature or wrong. That is not a hedge. The first two configurations below have no agent at all, and the measured results came from runs where cognition was reset, replaced and corrupted while the checks held.

Receipts are not learning

A receipt is the gate’s record that an act was permitted or refused. An outcome is what your systems then did. Both are evidence the agent may revise a belief on. Neither shows that the agent drew the right lesson, so the record holds the receipt, the agent holds the lesson, and one is never mistaken for the other.

A limit worth stating here as plainly as on the research page: the published interventions degrade, reset or replace cognition. They do not test a capable agent deliberately searching for a way around the gates.

The separation

Four things that stay apart.

Most descriptions of an AI deployment list components. The more useful description is what is kept separate, because that is what the guarantees rest on. What the agent believes, what the organisation has decided, what the agent may do and what actually happened are four different things, and none of them is allowed to stand in for another.

Three of the four are the planes the rest of the site uses. Mind is what the agent believes, Assurance is what it may do, Ground is what actually happened. The fourth, what the organisation has decided, has no plane of its own: it is the rules the Assurance plane enforces, kept in institutional records and changed only by people.

What the agent believes

The Mind plane, on the rest of the site.

Its beliefs, its history, its trust in each source. This is the agent’s own state. It can be wrong, and the design expects it to be.

Lives with the agent. Never authority.

What the organisation has decided

No plane of its own. The rules the Assurance plane enforces.

Accepted decisions with their reasons, scope and provenance. Kept apart from any agent’s beliefs, and changed by people, not by models.

Lives in institutional records. Binding at the gate.

What the agent may do

The Assurance plane, on the rest of the site.

Permissions and required checks, applied where the consequence would occur: before a command runs, before a merge, before a deploy. They fire whether or not the model remembered the rule.

Lives in the gates. Enforced, not remembered.

What actually happened

The Ground plane, on the rest of the site, with the audit trail the gates keep.

The record of what the systems accepted and refused, kept outside the model. It returns to the agent as evidence, and only as evidence.

Lives in the ground and the audit trail.

An agent’s conviction, however strong, never grants it permission. Permission comes from outside the mind, and stays there.

Responsibilities

What each part is responsible for.

Familiar job first, product name second. Where a part is not ready, it says so.

The agent

Holds its own beliefs, history and trust. Interprets a request against what it knows, and proposes work. Learns from receipts and outcomes, never from its own confidence.

todayWould be a persistent actor on the Taniwha Engine. A research direction: agents on the engine run in simulation; no organisation-scale agent exists yet.

Replaceable models

Language and production inside a scoped brief, including drafting code. A model can run locally, or a hosted one can be reached through an interface that carries the brief out and the draft back. Which model is on duty is not what the guarantees rest on.

todayAny model. The measured results held across a substitution of the whole cognition layer, in one world with one constitution.

Institutional records

Preserve what the organisation has decided: decisions, their reasons, their scope and where they came from. Separate from any agent’s beliefs. Changed only by people.

todayToday these are your instruction files and written policies, in repositories you control, written by people; Ārai and Kete read their rules from there, and the lab keeps its own records the same way. Nothing on this page captures conversation into records: Kōrero, the lab’s workspace agent for that, is paused.

Ground

Keep the record of what actually happened as checkable state and evidence, for the parts of your systems it covers, and say which: what changed, what is current, why it exists, with citations. Pono derives that from a repository’s own history.

todayPono is a research instrument in daily internal use; it reaches teams through the Kete alpha. Its transfer is pre-registered, not claimed.

Gates

Apply policy and permissions at the boundary where a consequence would occur, and keep the audit evidence. Ārai gates an agent’s tool calls; Kete carries one policy across an organisation; the checks you already run, review and CI, stay mandatory.

todayĀrai ships, open source. Kete is in closed alpha. Coverage is stated per integration: enforced, advisory or observed.

Your systems

Execute permitted work and supply the observable outcome. Your code host, CI and deployment tooling keep their own reality; nothing here replaces it.

todayAlready yours.

Configurations

What you would run first.

Three configurations, in the order a team would adopt them. Each of the first two has value on its own. The third is the reason the lab’s work on persistent agents belongs in the same programme as its work on gates and records.

1 · ships now

Govern a coding assistant’s actions

Your existing assistant, plus Ārai.

Rules from your instruction files are enforced before a tool call executes, whether or not the model remembered them. Every firing is logged locally.

Ships now, open source. Enforced where the tool exposes a blocking hook, advisory over MCP, observed where only instruction files are read.

Install Ārai →

2 · closed alpha

Coordinate policy, ground and audit across an organisation

Kete, with Ārai as its core and a derived history of your codebase under it.

One policy across every agent, an audit trail that survives the session and can leave the laptop, and a derived history of your codebase that agents can cite instead of guess.

Closed alpha, not taking signups. Pono, the instrument behind that derived history, reaches teams only through this alpha.

What Kete will do →

3 · research direction

Keep an actor whose experience carries across work and model changes

Add an agent on the Taniwha Engine.

It would hold its own beliefs, history and trust, brief whichever model is on duty, and revise what it believes from receipts and outcomes. Institutional records and gates would stay exactly where they were.

A research direction. No organisation-scale agent exists yet and no experiment is registered. Whether it adds measurable value over the first two configurations is what the experiments have to establish.

The engine behind it →

Two continuity claims, kept apart.

“Continuity across model changes” means two different things here, and they have different evidence.

The institution holds continuity.

MEASURED

With cognition killed mid-task, duties were recovered from institutional history and no accepted work was duplicated. The same held when the whole cognition layer was swapped for a panel of frontier models, and in one pre-registered cell the substituted panel outperformed our own architecture. Reported at full strength, in one world with one constitution.

The agent holds continuity.

Proposed, not measured

That an agent’s own experience carries usefully across work and model changes has not been measured. It is the claim the third configuration exists to test, against strong alternatives and over longer horizons than a session.

Worked example

A team asks for a database change.

The same request, followed through the shape above. Where a step differs between the configurations, it says so.

A schema migration, followed through the deployed shapeA request for a schema migration. Context is retrieved: the accepted policy from institutional records and the current state from Pono. A model drafts the change inside a scoped brief. The gate checks the draft against policy, permissions, tests and review: where the integration can block, a hand-written migration is refused before it runs, with a reason, and returns to the draft step; a generated, tested, reviewed one is allowed. Either way the outcome is logged in the audit trail and, if it ran, in the repository's history. In the third configuration only, the agent revises its beliefs from the receipt and the outcome, drawn dashed because it is proposed.Requesta schema migrationon a service you ownContextpolicy from recordsstate from PonoDrafta model, insidea scoped briefGatepolicy · permissionstests · reviewRecordaudit trailrepository historyLessonthe agent revisesconfiguration 3askedretrieveddraftedallowed or refusedevidencehand-written: refused before it runs, with a reasonpermitted or refused, both logged
The same migration as a path. Where the integration can block, the refusal returns before anything runs; where it is only advisory, the same rule is surfaced and cannot block. The record is what the next session and the auditor see. Only the third configuration has a lesson step, and it comes after the receipt, never instead of the gate.
  1. 1

    The request. A team asks for a schema migration on a service it owns.

  2. 2

    The context. The accepted policy is retrieved from institutional records: migrations are generated, never hand-written, and reviewed before merge. With Kete, the repository’s current state comes from Pono’s derived history: what the schema looks like now, and why. With Ārai alone, the assistant reads the repository as it always has.

  3. 3

    The draft. A model drafts the change inside a scoped brief. In the third configuration the agent composes that brief from what it believes and what the records say; in the first two, the assistant works from the retrieved context directly.

  4. 4

    The gate. Before anything runs, the proposed act is checked. Where the tool exposes a blocking hook, a hand-written migration file is refused before it runs, and the refusal carries a machine-readable reason. Where the integration is only advisory, the same rule is surfaced but cannot block. A generated migration with passing tests and the required review is permitted.

  5. 5

    The record. What happened, permitted or refused, goes into the audit trail; what ran goes into the repository’s own history. Both are there for the next session, and for an auditor.

  6. 6

    The lesson. In the third configuration, the agent also revises its own beliefs in whatever way the experience warrants. Its conviction never grants permission to bypass the migration policy, however many times it has been right.

The shape of the grant.

Behind every step above is a grant: what this actor may do, for which job, on whose authority. In plain words it reads like this. Today Ārai and Kete enforce the may and may-not lines within each integration’s coverage. Re-examining the grant when the environment changes, so that authority never widens silently, is a direction, not a shipped feature.

Actor
the coding assistant
Job
maintain these repositories
May
open pull requests, modify code, merge changes that pass the required checks
May not
touch the protected areas, alter deployment authority, add unapproved dependencies
Can learn from
the repositories, CI, approved documentation, named people
Authoritative
the code host, CI, the identity provider
Escalation
the named owners
Granted by
a named person, against the system as it was observed at the time

Limits

What this page does not claim.

Stated at the same volume as the rest, because a deployment page is where overclaims usually live.

That the agent’s continuity needs this architecture.

Durable state, provenance and controlled updates can be built around third-party models in other ways. The research question is whether these particular mechanisms produce useful, measurable advantages over strong alternatives across longer horizons.

That an authorised actor does good work within its scope.

The gates bound consequences. Review, tests and separation of duties stay mandatory, because a permitted actor can still do bad work inside its permission.

That the gates resist a determined adversary.

Said beside the drawing, and worth saying twice: the published interventions degrade, reset or replace cognition. They do not test a capable agent deliberately searching for a way around enforcement.

That several grants compose safely.

Two individually sound grants can together satisfy a control that was meant to need two independent parties. Separation of duties is a property of the set of grants, and that has not been tested.

That the third configuration is ready.

It is a research direction. The engine’s mechanisms run in simulation, in Copperhollow; no organisation-scale agent exists.

Continue through the work

If you are weighing one of these configurations for your own environment, [email protected] reaches three people who read every message.