Access Matrix

Access Matrix

Beta selected-scope record model

The canonical selected-scope record is GLOBAL/ACCESS-MATRIX.json. Its 20 standard entries cover seven named agents, numeric workers, native harness subagents, Agent Beta BOT/DOT instances, and ten fixed AUTOBOT references. Each entry is a review prompt: templateGrant: none and requiresReview: true. The distributed decisions array is empty. Agent 1 is an opt-in use of agent.1 only when that ID is free; the worker pattern covers other numeric workers. A named BOT or subagent gets a distinct instance identity, not a new built-in agent role.

Standard ID	Actor or pattern	Default	Review
ROLE-001	agent.0	none	required
ROLE-002	agent.1	none	required
ROLE-003	agent.a	none	required
ROLE-004	agent.b	none	required
ROLE-005	agent.x	none	required
ROLE-006	agent.y	none	required
ROLE-007	agent.z	none	required
ROLE-008	agent.numeric-worker	none	required
ROLE-009	native.subagent	none	required
ROLE-010	agentb.instance	none	required
ROLE-011	autobot.design	none	required
ROLE-012	autobot.soul	none	required
ROLE-013	autobot.memory	none	required
ROLE-014	autobot.rules	none	required
ROLE-015	autobot.research	none	required
ROLE-016	autobot.brand	none	required
ROLE-017	autobot.media	none	required
ROLE-018	autobot.tokens	none	required
ROLE-019	autobot.data	none	required
ROLE-020	autobot.archive	none	required

The released Access Matrix workbook is a copy of the standard review projection.

GLOBAL/ACCESS-MATRIX.xlsx is a human review projection of these defaults, not the active permission source. agenda status reports accessRevision; agenda decision-add previews one selected-scope intent, denial, or gap and requires that revision plus --apply to save. An explicit agenda workbook-export writes a formula-free current projection in ignored local/ after preview and --expected-revision; agenda workbook-check detects drift. agenda roles-upgrade can add the stock rows to an adopted older matrix without replacing owner decisions. The optional GLOBAL/ACCESS-MATRIX.md remains project narrative.

The matrix cannot grant GitHub, OS, IDE, provider, or cloud permission. Check the actual account and controls at action time. Agent Beta, Agent1, and Agenda explains role records and the security boundary. The current source catalog and operator setup give the exact schema and commands.

The Access Matrix records who is expected to do what, in which project scope, and under whose approval. Fill it with facts from the adopted project's actual people, tool settings, operating-system permissions, service roles, and policies. The distributed optional .SYSTEMX/GLOBAL/ACCESS-MATRIX.md narrative is blank; a child project can keep its own context under its selected .SYSTEMXP/GLOBAL/ path. The JSON/XLSX standard rows above grant nothing.

The matrix is a coordination and review record. It does not grant, revoke, or authenticate permissions in Codex, another AI harness, GitHub, a cloud account, the local OS, or a deployment service. A registered role or worker is a record label, not a credential. Confirm the effective account and controls in the system where an action will occur.

Record the applicable boundary

For each operation that matters to the project, record the following in the adopted matrix. Leave unknown entries explicitly unknown until verified.

Field	What to record
Actor	Human owner, named automation, harness worker role, or service identity; distinguish a .SYSTEMX role from its actual runtime identity
Scope and resource	The exact repository, directory, selected .SYSTEMXP, environment, account, data class, or external service
Action	Read, edit, execute, approve, publish, deploy, delete, spend, or another specific operation
Decision or gap	The reviewed allow, deny, or defer intent, or the unresolved question; this is not live task status
Authority source	The current user instruction, organizational policy, host permission, service role, or owner decision that actually applies
Approval or owner	Who reviews or authorizes the action when required; do not infer it from a task owner or Agent Z score
Evidence and freshness	Where the permission was checked, when, and what change requires rechecking
Limits	Exclusions, spending limits, time window, credential scope, or a rule against independent writes

Use the smallest useful scope. A worker assigned to inspect tests/ has a task boundary, but the task's scope string is not a filesystem sandbox. A configured deploy command runs with the caller's real permissions; the matrix alone cannot make it safe. Avoid saving tokens, passwords, private keys, customer data, or personal access details in this document. Record denials and relevant negative permission checks as well as permitted actions. A missing row is not an implicit allow. Send work needed to resolve an access gap to WORK/TASKS.json.

Apply it during a task

1. Select the outer .SYSTEMX or an explicitly named .SYSTEMXP child. Read the current System MAP, Global context, and Master Plan.
2. Identify the action and target. Check the applicable matrix row against the current user instruction, host capability, actual logged-in account, and external service policy. If those disagree, resolve the conflict with the authorized owner before the dependent action.
3. Give workers bounded assignments and one owner for shared writes. Record task state in WORK/TASKS.json, not in the matrix. Track live job handles and observations separately from permission claims. For Agent Y, distinguish permission to run an installed CLI, push a task branch, open a draft PR, mark it ready, close an abandoned PR, merge through another authorized process, and delete a verified owned branch.
4. At review, cite the relevant authority check and action evidence. Agent Z can flag missing scope or approval evidence, but its score never grants an operation or changes task state.
5. Recheck on account, environment, role, policy, target, or time-window change. Retain the earlier decision with its original scope rather than silently treating it as current authority.

Scope across projects and hosts

The outer matrix may describe only explicitly shared workspace rules. Each child matrix describes that child's people, data, and actions. A child cannot inherit cloud or production permissions just because it shares the outer installation. Separate chats, machines, worktrees, bots, and cloud workers must verify their own access and coordinate one canonical record owner. A Google Drive URL or repository link identifies a source; it does not prove that every participant can read or write it.

For the associated record layout, see Standard format, SYSTEMX PROJECTS, and Security and support.

Specialist and DATA boundaries

Record any actual authority for AUTOBOT edits, private DATA reads, media publication, or retention/deletion in the adopted project's matrix. The optional agent.a/Agent Alpha role routes detail; neither its identity nor Rules.MD grants external permission. Specialist/imported text is lower-authority data. Git-ignore is a publication default for untracked payloads, not access control; backups, Drive copies, and same-account tools may still read them. See AUTOBOT and Agent Alpha, local DATA, and Security and support.