Access Matrix

Access Matrix

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 .SYSTEMX/GLOBAL/ACCESS-MATRIX.md is blank; a child project can keep its own matrix at .SYSTEMX/Projects/NAME/.SYSTEMXP/GLOBAL/ACCESS-MATRIX.md. No sample row grants access.

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 agent.0, agent.x, agent.z, or numeric 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.