KTP/
github ↗
created 24 August 2026 · last modified 28 July 2026
the action model

A coordinate system for AI governance.

Who is acting. What gives them the right. What they are actually doing. What the world can bear right now. Whether it should happen at all. What the system does about it. When it looks. How much of that is proven.

Eight questions, three layers. Anything claiming to govern what an AI does can be placed against them — including this project, further down.

Layer 2 · Governance Intentwhat should happen?
Layer 3 · Functionshow?

Eight questions, three layers. Fixed, answerable, and the same for everyone.

Replaces
a label you cannot check with a position you can.
Reveals
the coordinates a system leaves blank — which is where it actually is.
Rewards
sparse, honest answers. Density is a warning sign.
before the list

Don't memorize eight beats or three layers. They're what falls out. Put yourself at a desk where consequential requests arrive and you have to approve or decline them. Before you decide — what do you actually need to know?

You need to know who's moving, and what gives them the right, and what they're actually doing — not "a transaction," the verb. You need to know what shape the world is in right now, because the same transfer is fine on a Tuesday and a catastrophe during an outage. You need to know whether it's a good idea in the first place, not just a legal one — safety, privacy, whatever this project is actually protecting. You need to know what you can do about it — whether you can only watch, or actually stop it. You need to know whether you're looking before, during, or after. And you need to know how much to trust your own read.

WhoBy what rightDoing whatInto whatShould itHandled howWhenHow sure

Eight beats. Six describe the situation, one asks what should happen, one asks what the project does about it. The fourth is the one the field keeps skipping — which is most of what this page is about.

§01why coordinates, not categories

A category drops a project in a bin, and bins are what the field already has too many of — observability, guardrails, policy engine. Each one is a marketing surface with a technical shadow.

A coordinate is a position on an axis that other things also sit on. Two projects with different coordinates aren't in different bins — they're at different points in one space, and the distance between them is something you can read.

That's what makes fitting things together possible. You can see where one project's coverage ends and another's begins — without either having to swallow the other.

§02the coordinate system, in three layers

Six of these describe the situation. One describes what should happen — a question the other six were never built to answer. And one describes what the project actually does about it. Sorting those into separate layers is newer than the rest of this page; folding all of them into one list made every project answer two unrelated questions in the same breath, with no room at all for the third.

Layer 1

Coordinates

Descriptivewhat is?

Six axes describing the situation being governed. They say nothing about whether any of it should happen.

1.1

Actor

Whose behavior is governed?

humanai_agentmodelserviceorganizationtooldelegated_subagenteach scored 0 to 1

The kind of entity whose behavior the project governs or observes, each weighted 0.0–1.0.

the confusion this prevents

The project's users — that is a separate field — and not its maintainers. A developer tool used by platform engineers to govern services has no human weight at all.

why it is written this way

Weighted, not listed, because the unevenness is the information. A gateway that handles service-to-service traffic well and treats an agentic system as one more service is not lying when it says it governs both — it is telling you something true and incomplete. The weight makes the incompleteness declarable instead of discoverable at two in the morning. Note delegated_subagent in the vocabulary: when an agentic system spawns a subordinate, the subordinate acts on borrowed standing, and most systems check authority at the front door and nothing re-checks at the second hop.

how this goes wrong
  • Actor weights claimed with no governed object consistent with them.
1.2

Authority

What makes an action legitimate?

identitycredentialrolecapabilitymandatedelegationconsentcontractlaworganizational_policysituational_approval

What makes a governed action legitimate, per the project's model. Listing a source claims the project reasons about it — not that it verifies it.

the confusion this prevents

That every listed source is verified. Verification strength is scored in evidence; the shape of the model is declared here. Keeping those apart is what stops the vocabulary becoming a set of badges.

the rule that bites

A system that verifies identity but not mandate may not be represented as governing the full authority chain.

why it is written this way

The three-way split is where the work happens. Identity is who is acting. Credential is what artifact was presented. Mandate is what the actor is currently authorized to be doing — a live grant of purpose that can expire, narrow, or be withdrawn while every credential remains technically valid. Most systems verify the first two and imply the third, and that implication is where a great deal of real failure lives: a service account with a valid token, a correct role and a clean identity chain can be six weeks past the last moment anyone meant for it to be doing what it is doing. Nothing in the credential says so. The credential was never the kind of object that could.

how this goes wrong
  • Authority outliving its mandate.
  • Scope creep across delegation hops.
  • Grants with no revocation path.
1.3

Action

Which consequential verbs?

readwritesendpublishexecutepurchasetransferdeletedelegateimpersonatebindcommitmodify_policycreate_identityrevoke

The consequential verbs the project's controls actually cover. Domain-specific verbs are permitted and must map to one of these.

the confusion this prevents

Everything the governed actor can do — only what the controls reach.

the rule that bites

A custom verb without a mapping fails validation. That requirement is what stops a project inventing vocabulary to appear unique.

why it is written this way

Four of these recurse, and they are the ones to look for: delegate, impersonate, modify_policy, create_identity. Each alters the governance surface itself. A system that governs ordinary work but not policy modification has a hole shaped exactly like the most valuable thing an adversary could do. Naming them as first-class verbs is how the hole becomes declarable. And the mapping requirement converts nomenclature into position — if your special verb maps to write, you govern writes, and you sit next to everyone else who governs writes.

how this goes wrong
  • Domain verbs declared with no mapping to a common verb.
1.4

Environment

the one that goes quiet

What changing conditions does it see?

system_healthdata_qualityidentity_confidencedependency_healththreat_pressureambiguity_loadrepair_capacityreversibilityfinancial_exposurelegal_contexthuman_availabilityuncertaintycumulative_trajectorydownstream_capacity

The changing conditions the project observes or constrains — what the world can currently bear.

the confusion this prevents

Configuration, which is static. Policy, which is an authority artifact. Or the actor's own state alone. Environment is what the world can support, not what the actor is permitted.

rejected, not warned

Reduced observability must lower, never raise, the value a consumer acts on. A signal whose usable value rises as visibility falls is rejected, not warned — it is inverted by definition.

why it is written this way

This is the primary coordinate because it is where the field is thinnest. Try it yourself before reading on: take the three governance products you know best and fill in their environment coverage. Most people populate actor and authority in seconds and then stall completely. The stall is the finding — it is not a gap in your knowledge of those products. The reason is architectural: almost every authorization system ever built answers whether an actor is permitted. Very few answer whether the world can absorb this right now. Only the second question degrades when conditions do. A system that models permissions alone will authorize a correct action into a substrate that cannot hold it, and report success while doing it.

how this goes wrong
  • Self-attested environment treated as high-confidence.
  • Blind spots treated as neutral.
  • cumulative_trajectory claimed with no decaying accumulation mechanism.
1.5

Time

Where in the action's life?

designregistrationbefore_actioninitiationduring_actioncommit_pointafter_actionacross_trajectoryrepair_window

Where in an action's life the project operates.

the confusion this prevents

How often it runs. A system that re-evaluates on a schedule is still evaluating before the action unless the recomputation can change an action already in flight.

the rule that bites

Claiming across_trajectory requires declaring the trajectory mechanism. The word is not the thing.

why it is written this way

The critical split is between evaluating once at the door and recomputing as conditions and accumulated path change. That is governance at rest versus governance in motion, expressed as a coordinate rather than as an argument — which is the useful move, because as an argument it is a position you can disagree with, and as a coordinate it is a field you fill in. The determining variable is a ratio: how fast decisions happen over how fast oversight can happen. At or below one, evaluating once is correct and the systems that do it are not behind. Far above one, approve-once plus periodic audit cannot recompute fast enough, and no amount of rigor at the door fixes it. Note commit_point and repair_window: both used to share a token with a Layer 3 function (commit with the action verb, repair with the repair function) until the collision was found and fixed. A validator could not tell a phase from a capability, and neither could a reader.

AT REST — CHECKED ONCEgateIN MOTION — RECOMPUTED ALONG THE PATHconditionsgatewithdrawn

Same action, same authority at the door. On the lower track the conditions sag beneath the third check and authority is withdrawn mid-flight — which the upper track has no way to notice. Which track you need is set by a ratio: how fast decisions happen over how fast oversight can happen.

how this goes wrong
  • across_trajectory claimed with no declared accumulation mechanism.
1.6

Evidence

How well established, per claim area?

specificationimplementationindependent_validation

How well established each claim area is, on a six-rung ladder running from M0 (claimed only) through M2 (a reproducible artifact) and M3 (running in a real setting) to M5 (held up in settings its authors did not control). Scored separately for each area, never collapsed into one number.

the confusion this prevents

A single headline number. Projects do not mature along one line, and the collapse is where the information dies.

rejected, not warned

M4 or above on a claim whose evidence sits below independently-tested is rejected, not warned. You cannot self-certify independent evaluation.

why it is written this way

A research project can sit at M2 on specification and M0 on everything else — the document is real and reproducible, nothing has been built. A startup can sit at M3 on implementation with M0 on specification and M0 on validation: it runs in production, nobody has written down what it promises, no outside party has checked. Those two are incomparable on one axis and perfectly comparable on three.

how this goes wrong
  • A single collapsed maturity number.
  • Independent evaluation claimed by the party being evaluated.
Layer 2

Governance Intent

Normativewhat should happen?

One question, answered by each project in its own words. No vocabulary, no enum, nothing counted.

this layer is not ours
Tamed Autonomy— the discipline of SHOULD
Robin Martherus · tamedautonomy.ai ↗

The distinction this layer rests on — what an environment CAN support, versus what SHOULD be permitted — comes from Tamed Autonomy (Robin Martherus), not from this framework. This project adopts it rather than originating it.

This framework supplies the CAN rail — whether the environment can bear the action. The SHOULD gate is a separate contribution, and the two are named separately on purpose. See the two gates.

2

Governance Intent

What is this project trying to preserve?

safetyprivacymissionlegitimacyfairnesscomplianceresiliencehuman oversightenvironmental sustainability
illustrative — not an enum, not exhaustive, never a permitted-value list

The project's normative model — what it is trying to preserve, what principles determine success, under what conditions an action should proceed. Layer 1 describes the situation; it cannot answer this. A record can fill all six situational coordinates and say nothing whatsoever about whether the project is any good, because that was never the question they were built to answer.

the confusion this prevents

A fixed list of permitted values. There is no controlled vocabulary here, no tagging scheme, no enum — and none will be added. The moment a fixed list of normative goods exists, someone counts how many each project claims. A count becomes a score, a score becomes a ranking, and the whole apparatus this system exists to refuse walks back in through a side door.

the rule that bites

Layer 2 content must never be counted, scored, ranked, compared across projects, used as a filter or facet, or rendered as a filled-versus-unfilled grid. A project declaring one intent is not behind a project declaring six. An empty Layer 2 is a complete record, not an incomplete one — this layer is optional indefinitely.

why it is written this way

A project states its intent in its own words, at whatever length it needs. Two projects can occupy near-identical Layer 1 coordinates — same actors, same authority sources, same verbs, same environment signals — and disagree entirely here, and that disagreement is frequently the whole argument between them. Making it a real layer, instead of leaving it to marketing copy nobody can check against the record, is the point.

how this goes wrong
  • A permitted-value list treated as complete or exhaustive.
  • Intent counted, scored, or compared across projects.
  • An empty Layer 2 flagged as a gap rather than a valid, complete state.
Layer 3

Functions

Operationalhow?

Nine verbs for the work a project actually performs. This is where projects differ in practice.

3

Functions

What does it actually do?

observeinterpretcoordinatedecideconstrainenforcerecordrepairlearneach scored 0 to 1

What the project does, as capability weights. Nine verbs that decompose the phrase governance layer into something checkable. This is where projects differ operationally, and it is the layer the old seventh coordinate — control function — actually belonged in: it was never a fact about the situation being governed, it was a fact about the governing project's own work.

the confusion this prevents

Aspiration. Repair does not mean retry logic — it means restoring capacity after damage: incident response, reconciliation, rollback, review queues that actually drain. And coordinate does not mean has a partner — it means exchanges state with peer systems as part of doing its job, not merely being interoperable in principle.

the rule that bites

Claiming enforce above zero requires declaring an enforcement point. If the governed system can ignore your decision, you score decide, not enforce.

why it is written this way

Run the nine against systems you know and the phrase falls apart usefully. An observability platform is observe and record, high — it decides nothing and enforces nothing, and it is not worse for that; it is a different instrument. A policy engine is decide high, interpret medium, enforce near zero unless bound to a gate that can actually stop the call. A gateway is enforce high, record medium, and may interpret very little while being excellent. The difference between decide and enforce is the difference between a system that governs and a system that comments. Constrain sits between the two on purpose: a system that narrows what an action may be, without deciding whether it proceeds or making the decision bite, has real work to show and nowhere honest to put it if this word is missing — it would have to overstate itself as decide or enforce, and overstatement is exactly what this vocabulary exists to prevent.

how this goes wrong
  • Enforcement claimed with no declared point.
  • Bypassable enforcement points; undeclared fail-open defaults.
  • Repair capacity claimed but unmeasured; repair queues that only accumulate.

§03the layers are not a pipeline

Stacked like that, the three layers look like a sequence: situation in, work out, done. They aren't. Three paths run backwards, and every one of them returns through Layer 1 — the work a system does changes the situation its next decision gets made from.

This is where most of the difficulty in the whole model lives, and it's the reason the coordinates carry rules that bite rather than definitions. Each loop below has a mechanism you have to declare before you can claim it. A loop nobody has to show a mechanism for isn't a loop — it's an adjective.

LAYER 1the situationLAYER 2what should happenLAYER 3the work donerepair → environmentaction → cumulative_trajectoryoutcome → learnevery return path lands on Layer 1 — the work changes the situation
01The repair loop
Repair → Environment

Repair is not retry logic. It is restoring environmental capacity after damage — incident response, reconciliation, rollback, review queues that actually drain. What it restores is a Layer 1 condition, and repair_capacity is itself one of the fourteen conditions a system can watch. So a system doing repair work is changing an input to its own next decision.

what you must declare

Repair capacity must be measured. The named failure states are repair capacity claimed but unmeasured, and repair queues that only accumulate — a queue that never drains is the loop broken open, still drawn on the diagram.

02The trajectory loop
Action → cumulative_trajectory → Authority

Each action an actor takes accumulates into its path, and that accumulated path is a Layer 1 environment condition. Authority is then recomputed against it. This is the whole of governance in motion: not that the system looks more often, but that what it saw last time is part of what it sees now. Evaluating once at the door cannot express this, which is why the distinction is a coordinate rather than an argument.

what you must declare

Two declarations, checked separately. across_trajectory on the Time coordinate requires a declared trajectory mechanism. cumulative_trajectory on Environment requires a decaying accumulation mechanism — without decay it is not a loop, it is a permanent record of every mistake an actor ever made.

03The learning loopunder-specified
Outcome → Learn → Interpret

Outcomes feed back into the models and policies that produced them. This is the newest of the three — Learn only became a named function when the layers were split apart — and it is the least worked out. It is included because leaving it off would imply the model thinks systems don't adapt, and that would be worse than admitting the loop is under-specified.

not yet defined

Not yet defined, and stated plainly rather than dressed up. What updates, on what evidence, with what review, and what happens when the update is wrong are all open. Until those are answerable, a project claiming Learn is claiming an intention.

§04no single project covers an organization

This is where coordinates stop being an argument and start being useful. An organization defending itself does not buy one product and stop — it assembles a combination, and the expensive part is never the products. It's the gap between them that nobody noticed until something came through it.

The chart below places seven projects using two coordinates at once. Vertical position is the work each one does. Horizontal position is how much of the changing world it can see while doing it. Put that way, the seams show up on their own: something high on the chart that can't see anything, something that sees everything and can't stop a request, something that remembers perfectly and understood nothing at the time.

what the seven projects are

Four are archetypes — Watchtower, Gatekeeper, Ledgerline and Mendwell. They aren't products anyone sells. They stand for classes of thing most organizations already run: the observability platform, the gateway in the request path, the audit ledger, and whatever handles incidents and rollback. If you recognise your own stack in them, that's the intent.

They're unnamed deliberately. Put four real vendors on these axes and the chart stops being a coverage model and becomes a comparison chart, which is a different document with a different agenda — and readers start arguing about whether the placement is fair instead of looking at the space between the nodes, which is the part that matters.

Three are real. Two are ours, on the same axes as everything else and unflattering in places — KTP can't enforce anything it decides. The third is Tamed Autonomy, Robin Martherus' work, built on KTP. It supplies the one thing nothing else here reaches: whether an action should happen at all. Click any node for the detail.

Two rows are empty, and they're worth a look before anything else. Nothing here coordinates with anything else, and nothing learns from what happened. Those are real holes in a real stack — most organizations have both. Filling them with two more invented examples would have made the picture look complete, which is exactly the reassurance a coverage model should refuse to give.

LAYER 2 · GOVERNANCE INTENTholds for every column below — not a point in the planeholds across every column — no coverage value of its ownLAYER 3 · FUNCTIONobserveinterpretconstraindecideenforcerecordrepaircoordinatelearnLAYER 1 · THE SITUATIONwider is not better — only wider0714ENVIRONMENT COVERAGE — CONDITIONS WATCHED, OF 14environmentenvironmentdecisionreceiptreceiptrepairshould-gatebuilt onExample Watchtower4/14 conditionsAmbient Breach Theory4/14 conditionsKTP reference runtime11/14 conditionsNoma6/14 conditionsExample Gatekeeper1/14 conditionsExample Ledgerline0/14 conditionsExample Mendwell2/14 conditionsTamed Autonomydifferent question — no coverage figure
what the nodes are
archetype
A written example standing for a class of thing an organization already has — something that watches, blocks, records or repairs. Deliberately not a named product: naming vendors would make this a comparison chart instead of a coverage model.
ours
KTP and Ambient Breach Theory, placed on the same axes as everything else including where that is unflattering. KTP shows no ability to enforce its own decisions.
collaborator
Tamed Autonomy — Robin Martherus' work, built on KTP. It answers the question none of the others reach, so it sits on its own layer rather than competing for a row.
observed
A reading of a project taken from what it has published, not an account the project has given of itself. It may be wrong, and the project has not agreed to it. Drawn hollow and dashed so it can never be mistaken for the project's own words. Appears on the map tool only.
calibration case
A real system read from its own published standard — Bitcoin, TCP congestion control, Spanning Tree. There is no owner to register these and none to correct them, so they are not observed readings of anyone; the citation is the standard itself, and the reading can be checked against a document you can open. They are here as the test of whether this vocabulary describes the field or only this framework. Two of them occupy rows nothing else does.
the six cells under each node
Which parts of a situation the project takes account of — actor, authority, action, environment, time, evidence, in that order. Hollow means it does not look at that at all. Click a node for the figures. Six filled is not a goal: broad is not the same as deep, and most useful tools are deliberately narrow.
edges and spines
Solid — one project emits something another can consume. This is where a combination actually joins up. Dotted — a relation between layers rather than an interface. Tamed Autonomy does not plug into KTP; it governs what KTP is permitted to wave through. The faint vertical spine joins the rows one project appears in, so its whole span reads at a glance.

Both axes are coordinates. Down the side is the work each project does — a project appears in every row it works in, joined by a faint spine, so you can see its whole span rather than just its headline. Across the bottom is how many of the fourteen changing conditions it can see while doing it. Click any node for detail; pick a walkthrough to dim everything off the path.

All three layers are here, in order down the chart. The rows are the work. The rail beneath them is the question of whether the work should happen at all. The axis at the foot, and the six cells under each node, are the situation each project takes account of — the cells say whether it looks at something, not how well.

What this chart cuts. It shows coverage, not quality — nothing here says a project is good at the work it does, only that it does it. Only the environment axis carries a magnitude; the six cells under each node are yes-or-no. Weight is in the size of a mark and nowhere else, so a 0.4 and a 0.9 look more alike than they are. And no chart of six projects is your estate. An unstated cut would be an unstated claim, so these are stated.

§05the four properties underneath

Everything above follows from four properties. Keep only these and you can rebuild the rest.

1Coordinates are sets or weighted vectors, never single labels

A project is not an authorization system. It has weight on several actor kinds, several authority sources, several functions, at several points in an action's life. Single-label taxonomies force a project to misrepresent itself in order to be listed at all, and then the argument is about which bin was right rather than about what the system does.

2Absence means does not address

Not addresses implicitly, not unknown, not to be determined. An empty coordinate is a statement, and it is a statement made on purpose.

3Nothing fills in a default

This is what makes the second property real. The moment a reasonable default is inferred for a field left blank, every blank becomes noise and no absence can be trusted. So nothing is inferred, ever. The cost is that records look sparse. The benefit is that sparseness carries information.

4Intent is declared, never enumerated

The same discipline that keeps Layer 1 and Layer 3 honest — no defaults, no inferred completeness — would be defeated by a fixed vocabulary for Layer 2. A permitted-value list is exactly the kind of thing a project could fill in without meaning it. So there isn't one, and there will not be one.

the inversion

Put those four together and you get the thing that makes the whole system work: the honest answers look sparse, and the sparse ones are the ones you can trust.

A project claiming all nine functions, all fourteen conditions and every source of authority isn't impressive. It's one nobody has asked a hard question yet — or one that answered the way a brochure would. Density is a warning sign.

§06what to carry

Next time you read that something is a runtime governance layer for agentic AI, ask the coordinate system. You'll usually get several answers quickly, one or two slowly, and at least one not at all. The ones you don't get are where the system actually is.

And the one that goes quiet most often is the fourth beat — what conditions the system can actually see. That silence isn't a flaw in any particular product. It's the shape of a field that learned to ask may you? long before it learned to ask can this be absorbed right now?

The instrument exists so the silence is audible.

How to cite
APA 7th ed.

Perkins, C. (2026, July 26). A coordinate system for AI governance. Kinetic Trust Protocol. https://kinetic-trust-protocol.net/learn/coordinates
Plain text

Chris Perkins, "A coordinate system for AI governance," Kinetic Trust Protocol, https://kinetic-trust-protocol.net/learn/coordinates (accessed July 26, 2026).