System MAP

System MAP

The System MAP is a compact route through an adopted project's source locations, interfaces, records, environments, and acceptance boundaries. Fill the blank .SYSTEMX/PLAN/MAP.md after choosing the workspace. A child project uses its own .SYSTEMX/Projects/NAME/.SYSTEMXP/PLAN/MAP.md. The map complements GLOBAL/CONTEXT.md and PLAN/MASTER-PLAN.md; it is not another task ledger, live status board, architecture proof, or permission system.

The public template contains no project-specific routes. Record real locations, owners, revisions, and assumptions in the adopted copy. Record data flows and trust boundaries when they apply. Mark an unknown as unknown rather than filling it with an illustrative endpoint.

Route from request to accepted outcome

flowchart LR
    H[Human objective and accepted sources] --> G[GLOBAL/CONTEXT.md]
    G --> P[PLAN/MASTER-PLAN.md]
    P --> T[WORK/TASKS.json]
    T --> W[Authorized tools and workers]
    T --> Y[Agent Y selected CLI and PR channel, if activated]
    Y --> W
    W --> E[Evidence and Agent X events, if activated]
    E --> Z[Agent Z review, if activated]
    Z --> A[Agent 0 or owner acceptance]
    A --> T
    T --> V[Generated work views]
    T --> F[WORK/FOCUS.json]
    F --> C[Generated CURRENT.md]

Loading

WORK/TASKS.json owns task status, dependencies, and completion history. WORK/FOCUS.json selects the current objective and task/checkpoint pointers. TODO, WORKING-ON, BLOCKED, REVIEW, DONE, CANCELLED, and CURRENT.md are generated views. Agent X events, Agent Y CLI/PR jobs, and Agent Z reports add observations, handoff, and review; none becomes a second task-status authority. The host IDE, CLI, chat, or bot supplies actual execution and permissions. See Task workflow and Evidence and acceptance.

Record the project's real topology

In the adopted MAP, make a small table for each applicable category:

Category	Questions the map should answer
Source locations	Which brief, specification, repository, dataset, and policy supplies each area? Link the accepted hierarchy in GLOBAL/CONTEXT.md; do not replace it here.
Record scope	Is this the outer project or a named .SYSTEMXP child? Which path is canonical, and who writes it?
Product and stack	Which components, interfaces, dependencies, data stores, and user paths exist? Where is the project architecture documented?
Environments and artifacts	Which local, test, staging, release, and live targets actually exist? What identifies an observed artifact or deployment?
Toolchain and ownership	Which harness or command performs each action? Who owns shared files, build resources, and active jobs?
CLI and PR channel	If Agent Y is used, which installed provider, repository/base, worktree/branch, and PR owner correspond to the task? Which remote actions are authorized?
Evidence route	Which checks prove source, integration, package, deployment, function, operation, or publication claims? Where are their original receipts?
Decision route	Which actions require a human or service approval, and where is the current Access Matrix or policy?

Use paths or stable references, not copied transcripts. A link to a live resource is a pointer, not a claim that it was reached or verified. Record last-observed time and revision for volatile facts, then recheck them when a decision depends on them. Keep private endpoints, credentials, and sensitive customer data out of a publicly shared map.

Multi-project and multi-chat selection

One outer .SYSTEMX can contain several named children at Projects/NAME/.SYSTEMXP. Each child has its own map, plan, tasks, focus, memory, and optional agent records. The outer map may hold only agreed shared routes and relationships. Always name the selected child when routing a task; equal task IDs in two children refer to different records. A cross-project reference is a coordination link, not a cross-ledger dependency.

Separate Git clones, Drive folders, chats, and virtual machines do not sync themselves. Choose one canonical record owner and a reviewed transport/handoff path. Record what was actually read back from that destination. See Shared workspaces, clouds, and bots and SYSTEMX PROJECTS.

Keep the map useful

Update the map when topology, source location, environment, or ownership changes. Keep the exact next task and status in WORK/TASKS.json, current selection in WORK/FOCUS.json, accepted source hierarchy in GLOBAL/CONTEXT.md, and accepted outcomes in the Master Plan. A map change alone cannot finish a task, deploy software, or prove a live result. Use Planning and memory for the session load order and Code review and readiness for current evidence limits.

Route Tier 2 detail and local payloads

Add the selected AUTOBOT/ panel and DATA/ location to the adopted map only when they are used. Record which specialist owns an approved convention or source pointer, which Agent Alpha result/revision a task used, and where the original evidence lives. Root and child panels/storage are distinct scopes. Keep payload content, private endpoints, and credentials out of a public MAP. Agent Alpha routes detail without replacing the Global source hierarchy or canonical ledger. DATA audit reports local Git exclusions; it is not transport, cloud access control, or history cleanup.

Route optional ROOT records

If ROOT planning is enabled, identify the selected ROOT/ path, originating/delegated requests, structural plan references, and actual harness/bot binding identities. Link canonical milestones/tasks and retained readback evidence; keep statuses in WORK/TASKS.json. The MAP explains where an external surface lives and who owns its reconciliation. It does not turn a saved ROOT observation into a continuously connected live source.