Status: DRAFT
Structuring the Charter: obligations as spine, views as lenses¶
Map of a draft framework. The Charter Commitments contain the proposed obligations and duties; this note explains how they relate to evidence, assessment and system use.
Resolution¶
The Charter's five public obligations are the spine. Everything else — actor roles, lifecycle, system layer, risk tier, impact type — is a lens over that spine or a module triggered by the assessed use.
The assessable truth remains the eight operational duties plus modules. An obligation summary is derived from duty/module findings; it is not scored on its own. Three rules prevent a readable summary from becoming a weak legitimacy wrapper:
- Non-compensatory: a strong module cannot offset a failed material duty.
- Not assessed blocks material claims: an omitted material module narrows or blocks the claim.
- Honesty failures contaminate affected claims: false, stale, or unsupported evidence invalidates the claim it supports, not only obligation 5.
Honesty-of-process cuts across the spine: public claims must be scoped, dated, versioned, evidence-backed, uncertainty-qualified, and withdrawn when unsupported. Grounding-faithfulness is one module of that discipline for factual system outputs.
Obligation-to-duty bridge¶
Use a Claims → Arguments → Evidence view:
- Scope & trigger — when the obligation applies and at what risk tier; links to legal-scope map, risk register, and duties 2–3.
- Accountability — interests protected, accountable owner, duty-holders, and oversight route; links to duty 1.
- Controls & evidence — what must be done and how it is proven, labelled by assurance depth; links to duty 3 and relevant modules.
- Remedy & escalation — remedy owed, escalation route, and withdrawal triggers; links to duties 6 and 8.
This view is a crosswalk over existing duties, not a new control layer. The five worked prototypes are consolidated in assurance-cases.md.
Two planes¶
Assurance and runtime are different planes:
- Assurance plane: periodic, outside the request path; produces warranted claims, evidence, depth labels, findings, and withdrawals.
- Runtime plane: inside the system; produces actions and traces under a governed operating envelope.
Runtime is the object of assurance, not a rival authority. Five interfaces bind the planes:
- assured scope → runtime envelope;
- runtime trace → assurance evidence;
- runtime drift/incident → re-assurance or withdrawal;
- shared risk tier → gate strength and evidence depth;
- one honesty discipline across reports and live notices.
The user-workflow governance note is the runtime reference model the assurance plane can assess.
Lenses¶
Use a small fixed set of lenses when a reader needs a different view:
- Actor-kind — rights/interest-holders, duty-holders, oversight actors, and meta-governance. Roles are contextual; one entity can hold several.
- Two lifecycles — system lifecycle (conceive → assess → procure → deploy → monitor → incident → update → retire) and consequential-event lifecycle (purpose → AI processing/action → effect → explanation → challenge → remedy → learning). Both start with a legitimacy gate. Admissibility — may this purpose enter Charter space at all? — is separate from assurance depth: a well-documented purpose can still be inadmissible, and some uses sit below a non-negotiable floor that no evidence redeems.
- Layer — data/knowledge/provenance, model/component, application/system, compute/infrastructure, human workflow, institution/governance, ecosystem/society.
- Risk/context calibrator — severity, likelihood, reversibility, scale, autonomy, dependency, vulnerability, domain, and essential-service status.
- Collective to individual impact — individual, group, community, polity, commons, environment; sets remedy route and evidence type.
Modules¶
Modules are triggered, not optional decoration. Every assessed system gets a baseline screen; deeper duties activate when the trigger is met. Examples: labour/worker, environment/resource, creator/copyright, sovereignty/Global-South, and capture/political-economy. Capture is always-on for the Charter's own governance because the steward, assessor, funder, and registry roles can themselves be captured. Worker is the one to watch: someone compelled to use a tool is not the free, accountable user the user-workflow note assumes.
Demand side: find, check, watch¶
The outward surfaces are concepts, not interface specs:
- Find — discovery and navigation across the network's AI systems and the providers behind them, based on scoped assurance depth rather than an "approved" badge. The directory must remain plural and neutral: the index is a chokepoint, and a captured registry is a captured market.
- Check — a Capabilities & Assurance Interface: what a system says it is for, what has been assured, and what is not verified.
- Watch — runtime inspection at least-exposure: each audience sees only its slice (own session, affected-person decision, assessor sample, regulator access, public aggregate). Inspection must be verifiable rather than self-reported, privacy-bounded (confirm behaviour without exposing content), and itself assessed — the assurance plane checks that inspection is adequate.
These surfaces steer discovery, procurement, and trust. They are governed public-power surfaces, not neutral plumbing.
Check: Capabilities & Assurance Interface (CAI)¶
Concept and public-interest profile, not a running interface, API or new standard. Consolidated from the 2026-06-28 design sketch, shaped by a GPT-5.5 / Gemini 3.1 exchange; schemas, signing and log mechanisms remain out of scope.
A person or their agent needs to distinguish what a system says it can do from which Charter obligations have been independently assured, at what depth and how recently. A machine-readable label can spread false confidence as readily as warranted confidence: CAI must never become a global "trusted / safe / compliant" badge or "queryable certification."
- Separate the claims. Keep provider-declared capabilities and independently assured findings visibly distinct, each with its own provenance. Bind assured claims to the exact assessed version; a changed system falls out of scope instead of inheriting assurance.
- Make scrutiny possible. Claims must be publicly checkable, scoped and labelled by assurance depth and currentness, countering fake assessors and conflicting accounts given to buyers and regulators. Unconfirmed status is unknown, never valid; stale claims expire. Build on existing attestation and transparency practices, adding the Charter's public-interest profile rather than a new standard.
- Respect the institutional dependency. Independent assurance needs accredited assessors, revocation and enforceable consequences such as delisting or procurement exclusion. A format cannot supply that trust infrastructure.
Possible in Phase 1: the self-declared half—purpose, limits, prohibited uses, operating envelope and version, plus a link to the human-readable release risk assessment. Assured fields remain not-yet-independently-attested. Deferred until a mature Phase-2 conformity scheme: independently signed obligation statuses, public scrutiny records and revocation. These are design directions, not claims that either service exists.
Accountability¶
Claims need consequences:
- Standing: users, affected people, and representatives for diffuse or collective harms can challenge.
- Authority: a named adjudicator outside any single member decides contested Charter claims under published standards.
- Consequence: unsupported, misleading, or out-of-scope claims are narrowed, reclassified, or withdrawn, and the record is public. Honesty applies reflexively — that consequence record is itself a warranted public claim.
Without this leg, the system only produces claims. With it, claims are answerable.
Where pieces sit¶
- Charter Commitments — assurance plane: obligations, duties, scope, depth labels, withdrawal.
- Grounding-Faithfulness & Contestability — assurance plane: factual-output honesty module.
- Assurance cases — the five obligation-to-duty crosswalk prototypes.
- Control-and-evidence layer — policy broker plus evidence plane.
- User-workflow governance — runtime reference model.
- Capabilities & Assurance Interface — demand-side check surface, described above.
What this is¶
A structural map. It is not normative text, not an assurance spec, and not a threshold/RACI model. The obligation crosswalks should graduate into a certification-model annex, not into the body of the Charter Commitments.