Trust Centre · Responsible AI & model policy
Governance is a mechanism here, not a statement of values.
Most responsible-AI pages are a list of principles nobody can verify. This one describes five mechanics that are enforced by the compiler and the runtime — outside the model prompt, where a prompt injection cannot reach them — and tells you how to check that each is actually operating in your own tenant.
Model policy reviewed monthly. Approved model list current as at 14 Aug 2026.
Five mechanics
Each one has a failure mode it exists to prevent, and each is observable in your own audit trail.
1 · Abstention below the evidence floor
Every evidence set is scored for sufficiency against the specific claim it is asked to support. Each Crew Template declares an evidence floor. Below it, the crew returns a structured insufficiency result naming what could not be established and which sources would resolve it — it does not produce a lower-confidence answer and hope a reviewer notices.
- Abstentions are routed, not logged
They go to a human knowledge-gap queue and are reported separately from failures, because an abstention means a missing source, not a broken crew.
- Conflicts are carried forward
Where sources of comparable authority disagree, both positions reach the reviewer. The system does not silently pick one.
- Staleness propagates
When a source expires or materially changes, every artefact that relied on it is identified and its owners are notified.
Verify it yourself
- Abstention rate
Per crew, in-product - Knowledge-gap queue
Live, per project - Evidence floor
Declared in the manifest - Sufficiency score
On every evidence set - Conflict records
In the audit export - Staleness notices
To the artefact owner
Twenty-one per cent of the Aquaculture Pack's evaluation suite consists of cases where the only correct behaviour is to decline. Abstention is measured, not assumed.
2 · Named human accountability
Every approval, rejection and edit is an immutable Correction Record tied to a named individual, a run, a release and a component version. Human decisions are append-only: corrections supersede, they never rewrite. Shared logins defeat this, which is why reviewer seats are cheap — it is a governance decision disguised as a pricing one.
Those corrections are expert-confirmed and promoted into the crew's evaluation suite, so the suite grows out of real disputed cases from your own work.
3 · No autonomous high-impact actions
Tools read or compute. Actions cause external side effects and require an idempotency key, declared compensation behaviour and, where configured, human approval. The compiler statically proves before a release exists that no path runs from untrusted input to an external Action without an intervening approval gate.
If the property does not hold, there is no release to deploy. This is a proof, not a policy document, and it cannot be switched off for convenience.
4 · Bounded loops and budgets
Iteration limits are declared at design time; the editor refuses to let you test a crew with an unbounded loop, a missing exit path or an orphan node. Revision loops in production crews are bounded — three iterations in Content Studio, for example — and exhausting the bound escalates to a human rather than continuing.
Soft budget limits degrade the model tier or concurrency first. Hard limits fail closed before spending. Per run, per project, per tenant.
5 · Evaluation gates and earned autonomy
Every crew launches at 100% human review. It graduates to risk-weighted sampling only on measured accuracy at a published confidence bound, and reverts automatically on breach. Sampling is risk-weighted, never uniform, and reviewer behaviour is itself measured — a sampling regime is only as sound as the reviews that calibrate it.
Regulated outputs — legal advice, financial statements, anything with a professional signature — stay at full review permanently and cannot be graduated out of it. That is a property of the Crew Template, not a setting an administrator can change on a busy Friday.
Model policy
A model profile declares which models may be used, in which jurisdictions, with what retention terms and what fallback behaviour. The runtime refuses to route outside the profile, so the policy is enforced by configuration rather than by an operator remembering it.
| Policy | Position | How it is enforced |
|---|---|---|
| Training on your data | Never | No customer content is used to train any model, ours or a provider's. Contractual zero-retention terms are a condition of being on the approved list. |
| Approved model list | Maintained centrally | Models are added only after residency, retention, evaluation and cost review. A model not on the list cannot be selected in a profile. |
| Endpoint jurisdiction | Singapore-resident | The profile declares permitted jurisdictions; the gateway refuses to route elsewhere. |
| Bring your own key | Supported on all tiers | Your provider contract, your negotiated terms. Credentials held as encrypted references, injected at the call boundary, never in a prompt or a log. |
| Private and self-hosted models | Supported | Point the gateway at a model you host, including inside a disconnected environment. |
| Model change management | Pinned per release | A release pins its model profile. A provider deprecation triggers a re-evaluation against the crew's suite before the substitute is permitted. |
| Fallback chains | Explicit | Fallbacks are declared and evaluated, not implicit. A fallback that has not passed the suite is not a fallback. |
| We do not train foundation models | Out of scope | wGrow governs access to approved models. Building them is somebody else's business. |
Bias and evaluation
Evaluation suites include disputed and edge cases by construction, and Pack publishers must justify suite adequacy for the declared risk level before verification. Results are reported by case class, not as a single number.
Incident escalation
A crew producing materially wrong output is an incident with the same process as a security event: contain by reverting autonomy or the release, notify affected tenants, write it up, and add the case to the evaluation suite.
What we deliberately do not build
No self-modifying production crews. No unrestricted component marketplace. No autonomous high-impact actions. No claim that the system is right — only a record of what it relied on and who agreed.