Repository navigation
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.
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.
- Select the outer
.SYSTEMXor an explicitly named.SYSTEMXPchild. Read the current System MAP, Global context, and Master Plan. - 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.
- 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. - 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.
- 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.
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.
.SYSTEMX · DOT SYSTEMX · Maintained by Wayne Tech Lab LLC · Repository · User manual · Prompt cookbook · MIT license
Beta 1.11.0-beta.4 prerelease — validate the selected release in your project. Release policy. Project records, configured commands, and verified evidence determine the state of each adopted project.
DOT SYSTEMX · User manual
1. Start here
- Current beta video: chapter and scene guide
- The Guided Folder: historical 4K walkthrough
- Start with a Folder: 4K animated guide
- Introduction video and archived poster
- Advanced walkthrough: inside the coordination layer
- Choose a workspace
- Agent 0 roster: roles, bots, and CLI paths
- Agent 0 and toolchain direct I/O
- First-time setup
- Provider and harness onboarding
- Daily workflow
- One-shot project guide
- Shared workspaces, clouds, and bots
- Historical use-case workflows
- Four current system maps
- Current maps, seven agent guides, and atlas
- Agent guide text and CLI flows
- Visual guide and historical diagrams
- New chat setup prompt
- Prompt cookbook
2. Work and continuity
- SYSTEMX PROJECTS
- AUTOBOT and Agent Alpha: Tier 2
- Local DATA storage
- Planning and memory
- ROOT planning, rules, and task delta
- System MAP
- Access Matrix: 20 standard entries
- Agent Beta, Agent1, and Agenda
- Task workflow
- Agent X: events and time
- Agent Y: CLI and PR channels
- Agent Z: fixed review
- 100 review questions
- Agent 0 and subagents
- Subagent processing
- Advanced use cases
- Evidence and acceptance
- Anti-drift and long-running work
- Tokens, cost, and time
3. Setup and maintenance
- Project / VS Code
- OS directory
- Google Drive
- LLM chat
- Exact casing and alias
- Installation and updates
- Upgrading
- Uninstall and cleanup
4. Advanced reference
- Standard format
- Technical Guide
- Stack Guide
- Library integration
- CLI and Tools
- Command reference
- Configuration and quality
- Operations and troubleshooting
- Security and support
- Code review and readiness
5. Project information