Charterion in ten minutes

The fourth architect question is new in version 2.0. It is answered by the part of the model that describes where agents run: the machines that host them, the tools they call, the AI models that drive them and the controls that stop them. It is optional; the rest of Charterion can be adopted without it.

A survey of 150 practitioners rated how much each of the first four agent questions matters and how well their current enterprise models answer it. Every one fell short, and the widest gap was on the envelope.

When an agent asks whether it may act, the execution plane gives exactly one of four answers. Each has its own remedy.

Four-valued answers exist elsewhere. What Charterion adds is the named human behind escalate and the warrant behind unwarranted: the evidence the substrate can show for its answer. Weaker evidence can only move an answer towards unwarranted.

A charter is grounded in a step the business has handed to agents, under a goal or an obligation. It yields a need on a resource, served through a tool that exposes the resource at an effect level, reached from a runtime node under an entitlement. What the agent remembers between actions must stay within the charter’s scope. Each break in the chain is reported on its own, so an architect can say where an agent’s authority stops being realised.

The specification catalogues 43 building blocks, 13 of them new in v2.0, and ten patterns, from planner and executor to kill-switch and approved-model routing; each of the seven checks is satisfied or made checkable by at least one pattern. It also names what the checks catch in systems that already run.

Every authority an agent holds begins as a charter: the organisation’s statement that the agent may act within a business scope (a capability, a process or a single step), up to a level, under an accountable human, with validity and review dates.

Commit and autonomous are the write levels. The same four words are used when the model is designed, when the agent runs and when its authority is handed to another organisation, so all three speak of one thing.

A capability is delivered by processes, a process by steps; each step touches resources at a level, and an agent chartered for the step needs an entitlement on each of them at that level. The entitlement a system enforces is worked out from the charter’s scope by following that chain through the enterprise model, then provisioned from the model into identity management. A grant no step needs is a shadow grant; a need with no grant is an agent that fails in production. Narrowing the charter narrows the entitlement; and an agent that hands work to another agent can pass on no more authority than it holds.

The specification’s granularity rule: read and propose charters may be broad, a capability or a process. Commit and autonomous charters should be as narrow as the steps that need them, and a write charter on a whole capability must be recorded with the reason a narrower scope was not possible.

Every decision is attributed to the charter that authorised it, and each charter accumulates its permits, denials, escalations, unwarranted answers and reversals. That record crosses the second bridge, evidence back, into the design loop, where a review narrows or widens the charter, or raises it one level. Raising must clear thresholds the governance board sets; the level can be lowered at any time.

A defect the organisation chooses to live with is recorded with an owner and a review date, and is reported again when that date passes.

When an agent deals with another organisation, neither side’s approvers can approve for the other. Authority has to travel with the agent.

The action proceeds only if both sides find it admissible; each side decides its own escalations. Under the layer model a partner’s server, tool or memory is an exposure too, like any record the partner opens.

Charterion is adopted as an ArchiMate profile: it labels elements already in your repository as agents and charters, without changing the language or the tools that read it. An agent is still drawn as an application component, so existing repositories stay valid, but it reads as an element whose meaning is authority: its charters belong to the agency layer, and the machine that runs it to the runtime layer. Every phase of the three loops above has a place in TOGAF’s Architecture Development Method, the ADM, the cycle a TOGAF shop already runs and keeps. Two habits change for the part of the estate agents work in: a target conformance level takes the place of a target architecture, and the board’s review of solutions becomes gates in each charter’s life, run by tools on every change.

The unit of adoption, conformance and reporting is the slice: a bounded set of capabilities or processes, their resources and the agents chartered on them.

Conformance is claimed slice by slice, on three scales: D0-D4 for the enterprise model, Levels 0-4 for the live service an agent asks before it acts, X0-X4 for what another organisation’s agents may find and do. A published Conformance Statement records each level and the defects the organisation chose to accept. No agent may be given authority to write to a system on a slice below Level 3 on that live-service scale.

Version 2.0 adds no level, scale or stage. A slice that opts into the layered checks says so in its statement and names who owns each layer; the checks are recommended once the slice’s model is well formed and required at no level, and a statement written under 1.x stays valid at the same levels.