MetaMynd Platform Governance

Companion to MAGP v1.0 Version 1.0 · 2026-08-20

MAGP specifies how a single action is authorized. This document specifies everything an organisation needs around that: who is answerable for a fleet of agents, how a regulator reads a tenant's record without being handed the tenant's database, how a supervised programme runs, how an incident reaches an authority, and how a decision is traced back to the humans and credentials behind it.

Scope: why this is a separate document

MAGP is drawn on a deliberately narrow test:

A thing belongs in MAGP if an independent implementer needs it to reach the same verdict on the same request, or to verify the same evidence without access to the platform that produced it.

Everything in this document fails that test, and fails it usefully. A second implementation of the gate does not need supervisory seats to agree with the first about whether a payment is authorized. These surfaces are how a platform is operated and supervised, not how a decision is computed.

The distinction is not cosmetic. Splitting them means MAGP can be implemented by a third party — a guard, an MCP server, a counterparty's own verifier — without inheriting the platform's tenancy model, its role system, or its regulator relationships. And it means these surfaces can change shape as regulation does, without a protocol version bump.

One asymmetry is worth naming. The protocol is the part we intend others to reimplement; this document describes the part we intend others to rely on. That makes the invariants here — §2 especially — load-bearing in a different way. A protocol bug produces a wrong verdict. A tenancy bug produces a data breach.

1. What is covered

2. Tenancy and scoping — the load-bearing invariant

Everything below reads data that belongs to someone. One rule governs all of it.

2.1 Ownership

2.1.1. Every governed object carries an ownerId. Every read is scoped by it.

2.1.2. A read never invents a scoping predicate. This is the single most important rule in this document, and it is worth stating as a prohibition rather than a principle, because the tempting design is the wrong one.

When a regulator needs to read one organisation's decisions, the obvious implementation is to teach the trust graph about regulators — add a "supervisor may see" branch to each query. That approach fails in a specific way: the accountability chain alone carries six distinct tenant predicates, and a second access path means each one is now enforced in two places that must agree forever. The first one that drifts is a cross-tenant leak, and it will drift silently, because nothing tests the equivalence of two predicates.

The rule instead:

Resolve the grant → resolve the supervised organisation to the tenant who owns it → call the same owner-scoped reads a tenant would call, as that owner → narrow the result to the granted organisation.

Every existing tenant predicate is reused untouched. There is exactly one code path to the data, and the supervisory seat is a caller of it rather than an exception within it.

2.1.3. Both narrowing predicates are required. Resolving to the owning tenant is not sufficient: a tenant may own several organisations, and stopping at the owner would return the granted organisation's siblings. Owner-scope and organisation-narrowing, together.

2.2 Refusals

2.2.1. A refused supervisory read returns 404, not 403. A 403 confirms the object exists, which is itself disclosure — a regulator probing ids could enumerate a tenant's organisations by distinguishing "not yours" from "not there".

2.2.2. The internal reason is recorded (NO_GRANT, REVOKED, EXPIRED, NOT_YET_VALID, UNKNOWN_BASIS, SCOPE_NOT_GRANTED, NO_ORGANIZATION, NOT_IN_ORGANIZATION, NOT_FOUND) and MUST NOT be returned to the caller.

2.3 Roles

2.3.1. regulator is a distinct role. It is not satisfied by platform admin — an operator with database access is not thereby a supervisor, and conflating them would make every supervisory access log entry ambiguous about who actually looked.

2.3.2. A regulator is exempt from the tenant KYC gate. It is not onboarding as a customer, and gating it behind customer verification locks the seat nobody can grant themselves.

3. Accountability

3.1 The chain

3.1.1. Every agent resolves to an accountable entity: a named legal person or organisation, reachable by walking agent → principal (or agent → organisation → principal).

3.1.2. The chain terminates at a human or a legal entity, never at another agent. A delegated agent's chain continues through its parent to the original principal (MAGP §5.4.7).

3.2 Fleet coverage

3.2.1. Per-agent accountability is necessary but not sufficient for supervision. The question an enterprise risk owner asks is not "who owns agent 47" but "how much of my fleet has an owner at all".

3.2.2. Coverage is reported as counts against the fleet total, rendered as a plain headline:

7 of 93 agents name an accountable entity · 0 have a business role

3.2.3. Gaps are reported, never inferred and never blank. An agent with no accountable entity appears as a gap. It MUST NOT be omitted from the denominator, and the surface MUST NOT render an empty state that reads as full coverage. A governance surface that shows nothing when it knows nothing is worse than no surface, because it is read as assurance.

3.2.4. Counts are clamped so a partial or inconsistent read cannot produce a coverage figure above 100%.

3.3 Backfill

3.3.1. Agents MAY be assigned to an organisation in bulk (reference limit: 200 per call).

3.3.2. Bulk assignment reports partial success: ids that were skipped are returned with a reason rather than silently dropped. An operator who assigns 200 and is told "done" when 40 failed has been misinformed about their own coverage.

3.3.3. Moving an agent to a different organisation MUST clear its operating unit. The unit belongs to the old organisation, and carrying it across leaves the agent pointing at a unit its new organisation does not contain.

4. Supervisory access

The regulator's seat. The only cross-tenant read in the platform.

4.1 Grants

4.1.1. A supervisory grant authorises one regulator to read one organisation's record. It carries a basis, a scope set, and a validity window.

4.1.2. Bases:

statutory_instrument is recognised by the schema and honoured by every check, with no way to issue one. Whether a supervisor's access in a given jurisdiction rests on agreement or on statute is a legal question, and the shape of the answer must not be forced by the shape of a table. When it is settled this becomes an issuance path, and nothing downstream changes.

4.1.3. Scopes: decisions · controls · proofs. A grant carries a subset; a read outside the granted subset is refused with SCOPE_NOT_GRANTED.

4.1.4. Grant checks fail closed. Unknown basis, expired, not-yet-valid and revoked all refuse.

4.2 The access log

4.2.1. Every supervisory read is logged. The log is hash-chained: each entry commits to the digest of the previous entry plus its own canonical content.

4.2.2. The log answers a question the supervised organisation is entitled to ask — what did the regulator actually look at — and answers it in a form the platform cannot quietly revise. Appending is cheap; rewriting history means recomputing every subsequent digest.

4.2.3. Chain verification distinguishes two failures, because they mean different things:

• DIGEST_MISMATCH — an entry's content no longer matches its digest. Tampering.
• CHAIN_BREAK — an entry's prevDigest does not match its predecessor. A missing or reordered entry.

4.2.4. An empty log is not intact. It is unverified. A verifier that returns "valid" for zero rows would certify a log that had been emptied.

4.2.5. Appends MUST serialise. The reference implementation takes a row lock on the chain tail before reading it, because read-tail-then-insert under concurrency forks the chain: two readers see the same tail, both append, and one entry's prevDigest points at a sibling rather than a predecessor — producing a false CHAIN_BREAK on a log nobody tampered with. Two unique indexes enforce the invariant at the storage layer as well.

4.3 What a regulator can read

4.3.1. The organisation's own access log is readable by the organisation, not only by the regulator. Supervision that cannot itself be audited is surveillance.

5. Sandbox programmes

A supervised trial: a regulator or programme operator admits participants, runs them against a defined plan, and collects evidence.

5.1 Cohorts

5.1.1. Statuses: open · closed · ended. Intake refusals are explicit — NOT_YET_OPEN, INTAKE_CLOSED, ENDED, NOT_OPEN — rather than a generic rejection, so an applicant learns whether to wait or to stop.

5.1.2. Applications transition through pending → admitted | refused | withdrawn. Only a pending application is decidable; re-deciding a settled one is refused.

5.1.3. Withdrawal belongs to the applicant; admission and refusal belong to the supervisor. These are different authorities over the same record.

5.2 Supervision

5.2.1. A programme has a supervisor, and only the supervisor (or a platform admin) may close it. A participant closing its own supervised programme would end the supervision by acting on the thing being supervised.

5.2.2. A supervisor MUST be able to read the programmes of its own cohort. Scoping a supervisor to only what it created leaves it unable to see what it supervises.

5.3 Plans and evidence

5.3.1. A sandbox plan is the trial as code — the probes to run and the evidence to collect — rather than a document describing what someone intends to do.

5.3.2. Programme evidence is hash-chained and retrievable as a chain, so a participant's run can be verified as complete and unedited.

5.3.3. Duplicate applications are refused as a conflict. A unique-constraint violation MUST NOT surface as a 500 carrying SQL — note that the ORM wraps the driver error, so detection must check the wrapped cause as well as the top-level code.

6. Incident recording and routing

6.1 Classification

6.1.1. Records are incident (realised) or near_miss (a control did its job).

6.1.2. classifyReportability() returns reportable or observation with reasons. The triggers:

6.1.3. Near-miss reporting is the point, not a bonus. Reporting foreseeable serious near misses is what lets an authority see a hazard before it lands rather than after.

6.1.4. Classification fails open. An unrecognised kind or severity is classified reportable, with the reason recorded as such. Every other control in this platform fails closed; this one must not, because the failure mode of a closed default here is a serious event silently reclassified as noise by a typo in an enum.

6.2 Routing

6.2.1. Routing sends a record to the authorities entitled to see it. A reporter can read where its own reports went; an authority reads an inbox of what was reported to it and acknowledges.

6.2.2. Deduplication keys the event, not the record. Two records describing one event route once. Keying the record instead would report the same event as many times as it was written down, which inflates an authority's picture of how often things go wrong.

7. Trust graph

Four questions over the governance record. All four are derived at read time from existing tables — there are no graph tables, no materialised edges, and nothing to fall out of sync with the records it summarises.

This section describes what is built. For the vocabulary these four answers are already expressed in, and the draft roadmap toward a graph a tenant can query directly instead of one computed on demand — which would revise 7.1.1 below — see the MetaMynd Trust Ontology (MMTO), an internal draft not yet implemented and not published (unlike this document, it carries no external guarantee, so it is named here rather than linked).

7.1 Design rules

7.1.1. Derived, never stored. A stored graph is a second source of truth about relationships the records already express.

7.1.2. Exact-key joins only. No fuzzy matching, no inferred edges. A relationship either exists in the data or is reported as a gap.

7.1.3. Gaps are reported, never blank. Each answer states what it could not resolve. An accountability walk that cannot reach a human says so; it does not return a shorter chain that looks complete.

7.1.4. Resolve by either key. An agent is addressable by identity id or DID, and a mandate resolves its agent by either — resolving only by uuid silently returns nothing for a caller holding the DID.

7.2 What each answer is really for

Each of the four looked straightforward and turned out to be a different question than expected:

• Blast radius — issuer → credential has no stored edges to walk; the relationship is reconstructed from what the credentials record about their issuance.
• Accountability — the chain ends at a human, not at an organisation. An org is not answerable; a person in it is.
• Contagion — shared standards link most of the fleet to most of the fleet, so a naive "what else shares an exposure" returns nearly everything. Cohorts need a specificity rule: a shared control only implies shared exposure when it is specific enough to mean something.
• Evidence path — the useful question is not "show me the chain" but "can anyone verify this without us". The answer names which links are independently checkable (anchored root, DID resolution, issuer signature) and which rest on trusting the platform.

8. SOP compilation

8.1 What it does

8.1.1. An organisation uploads a written policy document. The compiler proposes governance rules — MAGP molecules and atoms (MAGP §6.1, Appendix C) — for human review before anything is enforced.

8.1.2. Compiled output is a proposal, never live policy. Nothing an AI extracted from a PDF enforces itself.

8.2 Tenant privacy — a hard invariant

8.2.1. SOPs are strictly tenant-private. Uploaded documents, intermediate compilations, and emitted SOPs are ownerId-scoped, and assignable only to the owner's own agents.

8.2.2. A tenant's SOP MUST NOT be reused, shared, pooled across tenants, promoted into a template library, or used as training data. This holds regardless of how generic the content appears — the document is the customer's, and its governance posture is competitively sensitive.

8.2.3. Only admin-published Standards are cross-tenant. That is the sole sanctioned sharing path, and it carries content the platform authored.

8.2.4. Compliance artifacts and evidence packs derived from SOPs are owner- or admin-scoped by the same rule.

9. Cross-cutting rules

Collected because each was learned by getting it wrong somewhere above.

9.1. Never invent a scoping predicate (§2.1.2). Reuse the tenant path.

9.2. 404, not 403, on a cross-tenant refusal (§2.2.1).

9.3. Report gaps; never render blank as complete (§3.2.3, §7.1.3). A governance surface showing nothing is read as assurance.

9.4. Say what was truncated. A list capped at 50 of 93 must say so. A silently truncated list reads as a complete one.

9.5. Fail closed, except where a closed default hides a hazard — incident classification (§6.1.4) and MAGP's secondary controls (§9 there) are the deliberate exceptions, and each is exceptional for a stated reason.

9.6. Partial success is reported, not rounded up (§3.3.2).

9.7. Append-only logs need serialised appends (§4.2.5), or they produce false tamper alarms.

10. Endpoint reference

All authenticated. Role requirements as noted.

Supervisory — regulator, except /regulators (platform admin)

POST /supervisory/regulators
GET  /supervisory/grants                                   POST /supervisory/grants
POST /supervisory/grants/:grantId/revoke
GET  /supervisory/grants/:grantId/access
GET  /supervisory/organizations
GET  /supervisory/organizations/:orgId/access
GET  /supervisory/organizations/:orgId/pack?format=html
GET  /supervisory/organizations/:orgId/decisions
GET  /supervisory/organizations/:orgId/decisions/:ref/assurance

Sandbox

GET  /sandbox/me
POST /sandbox/enrolments/challenge                         POST /sandbox/enrolments
POST /sandbox/cohorts                                      GET  /sandbox/cohorts
GET  /sandbox/cohorts/:cohortId                            POST /sandbox/cohorts/:cohortId/status
POST /sandbox/cohorts/:cohortId/apply                      GET  /sandbox/cohorts/:cohortId/applications
GET  /sandbox/applications
POST /sandbox/applications/:applicationId/admit
POST /sandbox/applications/:applicationId/refuse
POST /sandbox/applications/:applicationId/withdraw
GET  /sandbox/plans                                        GET  /sandbox/plans/:planId
POST /sandbox/programmes                                   GET  /sandbox/programmes
GET  /sandbox/programmes/:programmeId                      POST /sandbox/programmes/:programmeId/close
GET  /sandbox/programmes/:programmeId/chain

Incident

POST /incident                          GET /incident            GET /incident/stats
GET  /incident/reports/inbox            POST /incident/reports/:reportId/acknowledge
GET  /incident/:id                      POST /incident/:id/route GET /incident/:id/reports

Trust graph

GET /trust-graph/issuer/:id/blast-radius
GET /trust-graph/decision/:ref/accountability
GET /trust-graph/decision/:ref/evidence-path
GET /trust-graph/agent/:ref/contagion

11. Relationship to MAGP

The seam: MAGP produces the records; this document specifies who may read them, who is answerable for them, and where they must be sent.