A principle nobody can act on at four on a Friday is not a principle, it is a poster.
These are commitments about how we work, not switches in the software. A few of them are enforced by the platform and we will say which. The rest are decisions, and the useful thing a charter can do is name the moment a decision arrives and the role that owns it.
Most responsible-AI statements are a list of adjectives: fair, transparent, accountable, human-centred. They are hard to disagree with and impossible to apply, because none of them tells anyone what to do when a module is ready and the person who would normally check it is on leave.
So ours is written the other way round. It names the points where a human owns the decision, and who that human is by role. A role survives a resignation. A named person does not.
It does not say keep humans in the loop. It names the points where a human owns the decision, and who that human is by role.The charter's own test of itself
No module, agent or pipeline decides a production promotion, admits a module, grants or widens access to a resource, or makes a final decision about an employee, a customer, a transaction or a regulated obligation. A module is never the actor that releases itself, expands its own access, or puts an output in front of a customer without a person accepting it.
Three of those are enforced rather than promised: promotion is an administrator-only route and our own automation has no path to it, a module's ceiling is fixed by admission at deploy time, and the identity policy denies an inference call that does not carry the content policy.
A new or wider resource. A new external host. Anything touching authentication, authorization, storage or data export. An output feeding a consequential business decision or a customer-facing artifact. After any validation failure that a coding agent attempted to repair. Before any irreversible action.
The list is deliberately mechanical. A reviewer should be able to tell from the change itself whether review is required, without a judgment call about how important it feels.
Whenever a module presents AI-generated or AI-shaped content to a person, or contributes materially to a decision about them. The notice states that a module and a model were involved, what for, that the output is support rather than final authority, what it drew on, who owns the module, and how to challenge the result.
The notice is written before the module ships. Under this rule a model-calling module is not promoted to production until the notice for it exists, which puts the wording in front of a person while there is still time to argue about it.
Strict validation fails. An undeclared host or resource is found. A scope exceeds its admission. An artifact hash does not match. The access record cannot be written. A cross-permission data event is suspected. An output causes or nearly causes material harm. Or a consequential workflow has no named human owner.
A channel can be disabled at runtime, so a pause is a real action rather than an intention. A pause taken for security or harm lifts only when your administrator and our platform owner agree, with evidence in front of both.
Containment first, before attribution and before the explanation. Evidence preserved rather than cleaned up. A written account of what happened and why. Then your risk owner decides whether to accept, reject or disclose the residual tradeoff, because that decision is a business one and is not ours to take.
One asymmetry is deliberate: we may refuse to re-enable a module that violates this charter, whoever asks. You own the business decision. We own whether we will operate the thing.
The instinct after a scare is to put the heaviest control on everything. It is the wrong move, and it is worse than doing nothing, because it teaches an organization that governance is the thing that stops work and gives it a reason to route around the governed path entirely.
A capability that retrieves and summarises, and takes no action on its own, sits at the configured tier: configured against your policy, monitored, audited, with no per-answer human review. A capability that writes to a system of record or reaches a customer sits higher, and gets a named human at the point of release.
Forcing per-answer review onto a low-autonomy capability slows adoption without reducing real risk, and spends the organization's patience on the wrong thing. Then when a genuinely consequential workflow arrives, the heavy control has already been discredited by the people who have to live with it.
For an internal, non-autonomous capability the two material categories are security, which for AI systems means direct and indirect prompt injection, and performance, which means being confidently wrong. Prompt injection is ranked first in the OWASP Top 10 for LLM Applications 2025 edition. We treat both as design constraints rather than as policy sentences: see what is enforced in cloud policy and the limits of knowledge answers.
A charter that produces no record is a statement of intent. These records exist in your deployment, in your account, and they are what makes an assertion about the charter checkable after the fact.
| What is recorded | Where it is written | Notable property |
|---|---|---|
| Each grant of module access | The access record, per person per module per day | Written before the credential is issued. If it cannot be written, no credential exists. Retained 400 days. |
| A promotion to production | The promotion record | Names the approvers and pins the exact artifact hash. A single-administrator deployment self-approves with a written justification, stored verbatim and labelled as exactly that. |
| An administrator reading a user's transcript | The application audit record | The read itself writes a row. This applies to us as much as to your own administrators. |
| A model call | The invocation log, in your account | Model, caller identity, latency, token counts. No prompt or answer text, deliberately, so it is evidence of use and not a transcript. |
| A reveal of a restricted field | The application audit record | Both the reveal and the write are recorded, with the person attached. |
| The controls in force, and what is not closed | The in-product plan page | Generated from the same typed object that builds the infrastructure. Our build fails if the two disagree. |
| What code is running | The deploy ledger and the health endpoints | Release tag and commit. Successful deploys only, which is a limit worth knowing. |
Every vended credential carries session tags naming the module, the channel, the person and the tenant, and the trust policy requires them, so a missing tag is a failed request rather than an unattributed one.
We train no models, so the familiar training-data conversation is not the relevant one. The two biases that do apply live in what an initiative chooses to measure, and both of them flatter the initiative.
If the success metric is "module shipped", the programme rewards activity over capability, and it will keep doing so with excellent dashboards. The counter is the business process owner defining success per capability before anything is built, in terms of a client-defined outcome rather than a count of things delivered.
A single adoption score across an organization conceals whose work improved and whose got worse. A capability can raise the mean while making one team's job measurably harder, and nobody sees it until that team stops using it. The counter is reading outcomes by role, not only in total.
Ours. It governs how we build and operate, and what we will and will not do inside your deployment. Your organization needs its own policy covering acceptable use, who may enable what, and what your people are told. We can help write it as part of policy advisory, and the useful part of that engagement is applying it in the system afterwards rather than filing it.
Parts of rules one and four. Promotion is administrator-only and our automation has no route to it; a module's ceiling is fixed at deploy time and intersected again when a credential is vended; an inference call without the content policy is denied by cloud identity policy; a channel can be paused at runtime; and if the access record cannot be written, no credential is issued.
Rules two, three and five are decisions made by people, and naming the role that owns each one is what makes them usable.
No. We run no evaluation set, no groundedness scoring and no faithfulness measurement. What the platform gives you is the record of what was asked of a model and by whom, and a knowledge assistant that declines when retrieval finds nothing rather than answering anyway.
Measuring whether a capability is right for your work is the process owner's job, and it is the first thing we ask them to define.
We will say so, in writing, with the reason. On most things you are the risk owner and your decision governs, including decisions we would have made differently. The exception is narrow: we may decline to operate or re-enable something that violates the charter, because we are the ones operating it.
It has a cost to us and we would rather carry that than the alternative. See what we do not claim.
If the answer is no, the document is decoration. Five rules, each attached to a role that exists in your organization, each naming the moment the decision arrives.
We map these five rules onto the roles that already exist in your organization during the assessment.