Responsibility boundary
If an AI system acts on your organisation’s behalf, who is accountable, and can you prove it afterwards?
Who may decide, who may act, and on what authority
The useful question is not whether AI is allowed to act. It is whether the permission to act was explicit, bounded, and recorded.
Runcible Oversing holds an institution’s authority model as part of its structure: who holds which decision rights, over what, in which state, with what escalation, and who holds them when that person is unavailable. Runcible AI operates inside that model, not around it.
What authority means here
Not seniority. Not a role name. A recorded right to act on a specific thing.
In most systems, permission is a property of a person: a job title, a group membership, an administrator flag. That is enough to control who can open a screen. It is not enough to control who can commit an institution.
Here, authority is a relationship between a person, a role, and a matter. The same person can hold decision rights over one programme and none over another. The same role can carry authority at one stage of a matter’s life and not at the next.
The practical test is whether an organisation can answer, six months later, not just who approved something but who was permitted to.
Permissions that vary with state
A matter under review is not editable by the people waiting on it.
Configurable workflow determines what state a matter is in, and the state determines what may be done to it and by whom. This is not policy enforced by convention or by asking people to be careful. While a matter sits in regulatory review, the permission to change its claim does not exist for the campaign team.
The consequence worth noticing is what it prevents: the quiet override. Most governance failures are not people defying a control. They are people acting in a system that never had one, and finding out later that they should not have.
Visibility works the same way. What a given role can see of counts, time, cost, revenue, and margin is configurable, because in a real institution those are different questions with different answers by role.
Validation before consequence
Approval is part of the matter’s life, not a parallel process in another tool.
Approval cycles apply to the things that carry institutional consequence: accounts, contracts, budgets, time, and expenditure among them. Because they run on the object rather than beside it, the approval is attached to what was approved — including the version, the evidence available at the time, and the objection that was raised and answered.
Where a decision needs more than one holder, it can require more than one. Where the named holder is unavailable, an alternate can be defined in advance rather than improvised under time pressure.
Delegation to Runcible AI
This is the sentence that matters, and it does not vary.
Human validation is the default for consequential decisions and actions. Where authority, scope, permissions, conditions, and escalation rules are explicitly delegated, Runcible AI can decide and act.
Read it in both directions. The default is validation — Runcible AI produces a qualified judgment and a responsible person decides. Delegation is the exception, and it is an act the institution performs deliberately: a scope, a set of conditions, a boundary, and a rule for what happens at the edge of it.
Delegated authority is authority the institution granted and can withdraw. It is recorded like any other authority, which means an action taken under it can be traced back to the grant that permitted it.
What this is not: a system that decides how much to trust itself. The boundary is set outside the intelligence, in the institution’s own model of who may do what.
What we do not claim
A security review deserves the limits stated as plainly as the capabilities.
- This is not autonomous operation.Nothing here should be read as Runcible AI setting its own boundaries or expanding its own scope.
- The authority model is as good as its configuration.An institution that configures everything as permissible has not gained a control by installing one.
- Enterprise security hardening is outstanding.The authority model is implemented; the surrounding security and compliance posture required by a large regulated enterprise is work still to be done, and is named as such on What Is Built, What Is Not.
- Financial approval chains are not production-hardened.They exist in the running application. They are not offered as a hardened financial control environment.