Labyrinth OS

Where Labyrinth fits — the receiver model

Labyrinth is the execution engine. It has no manual “new client” entry point — it receives hand-offs and runs delivery. A signed client becomes a contract, which holds milestones, which generate requests (the unit of delegated work).

Labyrinth receives work from two upstream sources

Logging in

Navigation. Open the app URL → email + password → you're routed to your role's home automatically. Seed users share the password labyrinth123 (e.g. ayo@elev8matrix.com Admin, sarah@elev8matrix.com Accountability, lisa@elev8matrix.com Coordinator, james@elev8matrix.com Specialist).

Navigation & role tiers

A left sidebar is shared across every screen; what you see depends on your role tier.

Role-home landings: Admin/Executive → Command Center; Accountability → Accountability; Project Director / Manager / Coordinator / Advisor → Role (/command/role); Specialist → My Work; Client → Portal.

Command Center

Purpose. Leadership cockpit — priorities, risk, deadlines and the Tree of Execution.

Navigation. Sidebar → Command Center (home for Admin/Executive).

• EnlilBar — today's priorities, at-risk items, next actions, deadlines.
• Metric tiles — Pipeline Value, Active Contracts, Red Tags, Overdue, Unassigned (red/amber = attention).
• Tree of Execution — Campaign → Contracts → Milestones → Requests, expandable with Next to drill in.
• CRM Handoff Queue — recent inbound hand-offs awaiting activation.

Strategy

Purpose. The kickoff view — pick a strategy and see its milestones A→Z with the roles, contracts and teams inserted at each stage.

Navigation. Sidebar → Strategy.

• Strategy pills switch the timeline (Foundation / Stabilization / Growth / Expansion).
• Stage cards — Active Execution, Deliverable Review, Validation, Optimization — each with day range, pace badge (On pace / At risk / Behind / No work), roles (owner ★), completion %, next action.
• “Validation checkpoint” markers on validation stages (visual marker, not an enforced gate).
• Show contracts & teams expands a stage to its live contracts and teams.

Vision

Purpose. The cross-client roadmap quadrant — pipeline of projects over time, with timeline / map / Gantt views and the approvals overlay.

Navigation. Sidebar → Command → Vision (/command/vision).

• View switches: Timeline, Command Map, Pipeline, Gantt.
• Approvals (n) overlay surfaces items awaiting sign-off across clients.
• Project cards (e.g. Apex Holdings — Full Suite, TechCorp — Web Platform) with milestone/deliverable counts, plus a Completed Projects rail.

Role

Purpose. The team-command quadrant and the home screen for Project Director / Manager / Coordinator / Advisor — your team's org, accountability and communication in one place.

Navigation. Sidebar → Command → Role (/command/role).

• Views: Organization (authority & team load), Accountability, Communication.
• Personal tiles: Assigned Requests, Board Cards To Review — your own queue at the top of the command surface.

Tools

Purpose. Daily operating tools — the Battleplan, SOPs/training, execution engines and systems.

Navigation. Sidebar → Command → Tools (/command/tools).

1. 1Battleplan
2. 2Training
3. 3SOPs
4. 4Engines
5. 5Systems

• Sections: Battleplan, Training, SOPs, Engines (Momentum / Outcome Lock / Adaptive Strategy), Systems.
• Entry tiles link to Requests, Boards and the execution engines — the launch pad for operational work.

Performance

Purpose. The department KPI dashboard — scorecards and narrative reports by function.

Navigation. Sidebar → Command → Performance (/command/performance).

1. 1Filter: All
2. 2Filter: Accountability
3. 3Filter: Development
4. 4Filter: HR / Marketing / Sales …

• Function filters: All, Accountability, Development, HR, Marketing, Powerhouse, Sales.
• Tiles: Average Score, Needs Attention, Failing KPIs, Verified (n/total).
• Function goals list with current scores and verification state.

Contracts

Purpose. The contract list — the trunk records the whole funnel hangs off.

Navigation. Sidebar → Contracts (or Command → Contracts).

Open a contract for its Tree of Execution (milestones → requests), red tags, the accountability ladder and an append-only execution log. Lifecycle: QUESTIONNAIRE → PROPOSAL → SOW → BID → SIGNED → ACTIVE → CONFIRMING → COMPLETED → PAID, with REVISED as a re-work loop and ON_HOLD / CANCELLED escape hatches. Hand-offs create contracts at SIGNED. Each contract carries a client package (BRONZE / SILVER / GOLD / BLACK) that sets its accountability SLA.

Requests

Purpose. The queue of delegated work — the unit the accountability engine watches.

Navigation. Sidebar → Requests.

• Columns: Title · Contract · Tag · Priority · State · Owner · Assigned · Due.
• State: OPEN · IN_PROGRESS · BLOCKED · COMPLETED · CANCELLED.
• Priority: LOW · NORMAL · HIGH · URGENT.
• Tag: TASK · DOCUMENT_REQUEST · MEETING_REQUEST · DECISION_REQUEST · DELIVERABLE · APPROVAL · BILLING · CLIENT_REQUEST.
• Overdue requests drive escalation (NONE → REMINDER → WARNING → ESCALATED).

My Work

Purpose. The Specialist/Member home — a focused list of items assigned to you.

Navigation. Sidebar → My Work (also a shortcut for everyone).

• Tiles: Open Requests, Assigned Cards, Overdue, Due This Week, Done (7d), Unread.
• Request Queue and Red Tags panels.
• Start / Cancel actions move your items along; raise a red tag if blocked.

Boards

Purpose. Kanban-style delivery boards — recurring and per-contract.

Navigation. Sidebar → Tools → Boards (/boards).

Sections: Recurring Boards (e.g. weekly) and All Boards (per-contract delivery). Open a board for its card columns; cards link back to requests/milestones.

Rainfall

Purpose. The structured communication layer — on-record comms and commands that flow down the org and across peers.

Navigation. Sidebar → Rainfall.

1. 1Send Message

• Tiles: Total Messages, Critical Messages, Pending Acknowledgements, Messages Today, Escalated.
• Filters: All Types, All Severities, Needs Ack; plus Mark All Acknowledged.
• Messages carry a severity and can require acknowledgement (ack due in 12h CRITICAL / 24h HIGH / 48h NORMAL); unacknowledged criticals escalate.

Approvals

Purpose. The milestone approval & enforcement queue.

Navigation. Sidebar → Approvals (roles that can approve).

• Filters: All · Pending · Escalated · Rejected · Acknowledged · Approved.
• Approval chain (fixed): Coordinator → Advisor → Accountability → Executive — all four are required, in order, to fully approve a milestone (out-of-order approvals are rejected with “Next required role is X”).

Documents

Purpose. The resource vault — contracts, SOPs, deliverables and imports, scoped by visibility classification.

Navigation. Sidebar → Documents.

1. 1Search vault
2. 2Create your first page
3. 3New page

• Sections: Employee contracts, Client legal docs, Google Docs import, ClickUp attachments, Meeting-to-work import.
• Actions: New page, Issue for signature, Store and expose to portal, Index in vault, Index attachment.
• Each document is linked to a contract and classified by visibility (PUBLIC → OWNER_ONLY).

Red Tags

Purpose. The blocker registry — raise, acknowledge and resolve the flags that gate work.

Navigation. Sidebar → Red Tags (/red-tags).

1. 1New Red Tag
2. 2Resolve (per row)
3. 3Resolve
4. 4Resolve

• Severity → blast radius: WARNING blocks the request; CRITICAL blocks the milestone; BLOCKER blocks the contract.
• State: OPEN · ACKNOWLEDGED · RESOLVED · DISMISSED (OPEN/ACKNOWLEDGED block; RESOLVED/DISMISSED unblock).
• Row actions: Acknowledge, Resolve (with notes), Dismiss. What is severity? explains the model.

Decisions

Purpose. Decision memory & governance — log key decisions and their outcomes for an auditable record.

Navigation. Sidebar → Tools → Decisions (/decisions).

Log Decision records a decision (e.g. Delay launch by 2 weeks, Switch to Next.js for the client portal); each entry tracks its rationale and an Outcome once known.

Workflows

Purpose. Repeatable templates (e.g. Web Development Pipeline) deployed to a contract/campaign to seed structured tasks.

Navigation. Sidebar → Tools → Workflows (/workflows).

1. 1New Template (Admin)
2. 2Tab: Deployments
3. 3Tab: Templates

• Tabs: Deployments, Templates.
• Tiles: Active Templates, Active Deployments, Tasks Completed, Tasks In Progress.
• New Template (Admin only) defines a reusable pipeline; Deploy Workflow instantiates its tasks against a target. (This is where repeatable contract structure lives — not contract creation.)

Playbooks

Purpose. Structured SOPs/checklists that can be deployed to a contract or campaign.

Navigation. Sidebar → Tools → Playbooks (/playbooks).

Deploy Playbook: Choose playbook → Target contract (or campaign) → Deploy. Managing playbooks is Admin / Executive.

Campaigns

Purpose. The grouping above contracts — a campaign holds related contracts and scopes governance/visibility.

Navigation. Sidebar → Campaigns (/campaigns).

1. 1New Campaign

New Campaign creates the container; scoped (non-view-all) users can only create/see contracts inside campaigns they're granted. Open a campaign for its contracts and rollups.

Accountability

Purpose. The governance home & exception queue — overdue, blocked, unowned, unaudited work; also user creation.

Navigation. Sidebar → Accountability (home for the Accountability role).

1. 1Run Check
2. 2Add User

• Run Check refreshes accountability events (also runs automatically every 15 minutes).
• Work the exception queue top-down (escalated/overdue first); cards include Blocked Work and Unowned Contracts.
• Create & Manage Users — set role and function. User columns: Name, Email, Role, Function, Created.

System Factory

Purpose. The factory queue — imports, strategy intakes, proposals, draft contracts and the live CRM → Labyrinth hand-offs.

Navigation. Sidebar → More → System Factory (/command/factory).

1. 1Search factory
2. 2Tab: All
3. 3Tab: Imported Data
4. 4Tab: Strategies
5. 5Tab: Contracts

• Tabs: All · Imported Data · Strategies · Contracts · Proposals · Changes · Needs Review.
• Source tiles: ClickUp, GHL, CyberTax, Ripple, Nexus — each showing item counts and pending changes.
• Live CRM Handoffs — when a CRM deal closes, the hand-off surfaces here; View / Advance to PROPOSAL turn an intake into active execution.

Handoffs

Purpose. The hand-off command board — track inbound clients against onboarding/launch SLAs and team execution.

Navigation. Sidebar → More → Handoffs (/command/handoffs).

• Tiles: Live handoffs, New this week, SLA risks, Open tasks, Unassigned.
• Columns: Contract · 48h onboarding · 72h launch · Open work · Next action.
• Team Task Queue and a CEO demo script sit alongside the board.

Function Intakes

Purpose. Intake forms that capture a new function/department's setup as structured templates.

Navigation. Sidebar → More → Function Intakes (/command/function-intakes).

Function Templates define repeatable function setups; completing an intake seeds the related structure. Admin/operator oriented.

Imports

Purpose. Staged data imports — bring an external operating model in for review before it becomes live records.

Navigation. Sidebar → More → Imports (/imports).

1. 1Run demo source
2. 2New import
3. 3Refresh

• Tiles: Active Workspaces, Import Sessions, Completed Sessions, Needs Review.
• New import starts a session; Run demo source loads sample data; review the staged Operating Model before promoting it.

Integrations

Purpose. Connect external platforms and sync their data into Labyrinth.

Navigation. Sidebar → More → Integrations (/integrations).

Connect a source, optionally link it to a contract target, and Sync. Pairs with System Factory (where synced items surface for review).

Analytics

Purpose. System-wide execution metrics — campaign risk, milestone mix and request throughput.

Navigation. Sidebar → More → Analytics (/analytics).

• Campaign Risk Overview.
• Milestones by Status (EXECUTED / IN_PROGRESS / NOT_STARTED / OPTIMIZED).
• Requests Created (last 30 days) trend.

Payroll

Purpose. The payout queue — release contract payouts, gated by the post-completion investigation window.

Navigation. Sidebar → More → Payroll (/payroll).

• Tiles: Queued Contracts, Eligible for Full Payout, Restricted by Investigation.
• A completed contract holds payout until its investigationDays window (default 7) expires; maxPayoutPercent (default 60%) caps payout before full completion.

Workforce

Purpose. Employee utilization & roster — headcount, role types and capacity.

Navigation. Sidebar → More → Workforce (/workforce).

• Tiles: Full Time, Half Time, Contract, Project-Based, On Leave.
• Panels: Headcount by Department, Role Type Breakdown, Full Employee Roster.
• Roster columns: #, Name, Department, Specific Title, Role Type, Status/Notes (employment type = FULL_TIME / HALF_TIME / CONTRACT / PROJECT_BASED / ON_LEAVE).

Admin

Purpose. System configuration — managed systems, access reviews and policy acknowledgements.

Navigation. Sidebar → Admin (/admin, ADMIN only).

1. 1Add Managed System
2. 2New Access Review
3. 3Assign Policy Ack

• Tiles: Users, Campaigns, Contracts, Managed Systems, Pending Access.
• Actions: Add Managed System, New Access Review, Assign Policy Ack.
• Admin Workspaces and Policy Signals panels. Requires the admin.system_config permission (Admin only).

Client Management

Purpose. Manage client accounts, their workspaces and portal access.

Navigation. Sidebar → Admin → Clients (/admin/clients).

1. 1New Client

• Columns: Account · Client · Primary Contact · Workspaces · Status · Portal.
• New Client provisions a client account; portal access is managed per workspace (preview/activate via the portal routes).

Admin Log / Audit

Purpose. The append-only audit & events log of who did what.

Navigation. Sidebar → More → Admin Log (/command/admin-log). (/audit is an alias that lands here.)

1. 1Search logs

• Tabs: Audit (n) and Events (n).
• Each entry shows the action (e.g. CREATE on Playbook / FunctionIntake), the actor and a timestamp. Searchable. Visible to roles with command.admin_log.

Notifications

Purpose. Your notification centre — red tags, approvals and workflow events.

Navigation. Top bar → bell, or /notifications.

1. 1Tab: All
2. 2Tab: Unread
3. 3Tab: Red Tag
4. 4Tab: Approval

• Tabs: All · Unread · Red Tag · Approval · Workflow.
• Mark all as read / per-item Mark read. Grouped by day.

Ecosystem

Purpose. The cross-product launchpad — jump between Labyrinth and the sibling platforms.

Navigation. Sidebar footer → Ecosystem (/ecosystem, Admin/Executive).

Cards launch each engine: Labyrinth (execution), Nexus (command & evaluation), Finexus (financial intelligence), CyberTaxx (CRM & pipeline), Ripple (acquisition).

CRM Workspace

Purpose. A live read/work bridge to the upstream CRM (CyberTaxx) from inside Labyrinth.

Navigation. Sidebar → CRM (/crm, needs command.view).

1. 1Add note to CyberTaxx

• Tiles/tabs: CyberTaxx clients, Operating funnels, Leads, Deals, Accounts, CRM handoffs.
• Filter… narrows records; Add note to CyberTaxx writes back to the CRM. This is the read/write seam between the CRM and execution.

Client Portal

Purpose. The client-facing surface — what a client sees: progress, timeline, deliverables and payout status.

Navigation. /portal (role CLIENT, or portal.view/portal.manage).

• Sections: Workspace Summary, Timeline, Reports & Payout Status.
• Scoped to client-safe data only; the client reviews progress and gives approvals — they don't drive execution.
• Governed by the FLAG_PORTAL_ENABLED kill-switch (off = maintenance page).

Contracts & milestones

Create a Contract

Purpose. Create a delivery contract (most arrive via hand-off; this is the manual path).

Prerequisites. Permission contracts.create (Admin / Executive); a campaign to attach to unless org-wide.

1. Contracts → New Contract.
2. Set name, client, client package, campaign, owner.
3. Save — it starts at QUESTIONNAIRE.

Required fields. name, clientName, clientPackage (BRONZE/SILVER/GOLD/BLACK); campaignId unless org-wide; owner must pass canOwnWork (a leadership role).

Validation. Stage cannot be set on creation — new contracts always start at QUESTIONNAIRE (anything else → 422).

Update a Contract / Move Contract Stages

Purpose. Advance the contract lifecycle.

Prerequisites. Permission contracts.transition.

1. Open the contract.
2. Use the lifecycle control to move to the next allowed stage.
3. Provide any required transition info.

Validation. You can't skip stages. CONFIRMING/COMPLETED require all milestones EXECUTED; COMPLETED is blocked by any OPEN/ACKNOWLEDGED CRITICAL/BLOCKER red tag; PAID waits for the investigation window; an unacknowledged critical communication blocks progression.

Create / Edit Milestones

Purpose. Add checkpoints under a contract.

Prerequisites. Permission milestones.create / milestones.edit.

1. Open the contract → Add Milestone.
2. Set title, description, due date, order.
3. Save — starts at NOT_STARTED.

Required fields. contractId, title.

Validation. Status can't be set on creation (always NOT_STARTED). Lifecycle: NOT_STARTED → IN_PROGRESS → OPTIMIZED → EXECUTED (+ NEEDS_ATTENTION, ON_HOLD).

Approve a Milestone

Purpose. Sign off a milestone in the chain.

Prerequisites. Permission milestones.approve and your step in the chain.

1. Approvals → open the milestone.
2. Record your approval (with notes).

Validation. The chain is Coordinator → Advisor → Accountability → Executive, strictly in order — an out-of-order approval is rejected (“Next required role is X”).

Expected result. Once all four roles have approved within the current cycle, the milestone can become EXECUTED.

Requests & red tags

Create a Request

Purpose. Delegate a unit of work (the ‘Golden Rule’ record).

Prerequisites. Per the authority model, official tasks are created by Accountability or automation; coordinators initiate/delegate.

1. Requests → New Request.
2. Attach to a contract (required) and optionally a milestone.
3. Set title, tag, priority, owner (a leadership role), due date.
4. Save.

Required fields. contractId, title, tag, priority, ownerId (leadership), dueAt — all required (the Golden Rule).

Validation. A request MUST have a contract, an owner who can own work, a tag, a priority and a due date. Specialists are assignees, not owners.

Assign / Reassign a Request

Purpose. Put work in someone's My Work.

1. Open the request → set/refresh the assignee.
2. Save.

Expected result. The request appears in the assignee's My Work.

Complete a Request

1. Open the request → set state → COMPLETED (with notes).

Expected result. Removed from active queues; counts toward milestone progress. (States: OPEN · IN_PROGRESS · BLOCKED · COMPLETED · CANCELLED.)

Raise a Red Tag

Purpose. Flag a blocker.

1. Red Tags → New Red Tag (or from a contract/milestone/request).
2. Choose severity, title, description.
3. Save.

Required fields. contractId, severity, title.

Validation. WARNING blocks the request · CRITICAL blocks the milestone · BLOCKER blocks the contract.

Resolve a Red Tag

1. Open the red tag → Acknowledge, then Resolve with resolution notes (or Dismiss).

Expected result. Unblocks the gated item; records who resolved it and when. States: OPEN · ACKNOWLEDGED · RESOLVED · DISMISSED.

Rainfall, approvals, users, documents, templates

Create a Rainfall Message

Purpose. Send an on-record communication/command.

1. Rainfall → Send Message.
2. Pick what it's linked to (contract/campaign/etc.), write the body, set severity / require acknowledgement if needed.
3. Send.

Required fields. linkedEntityType, linkedEntityId, body.

Validation. Those three are required; severity sets the ack deadline (12h/24h/48h) and drives escalation.

Create Users / Assign Roles

Purpose. Onboard a team member.

Prerequisites. Permission team.manage — Accountability or Admin.

1. Accountability → Create & Manage Users → Add User.
2. Set role and function.
3. Save / invite (password must meet the 12-char policy).

Expected result. User can log in to their role's home; role sets their tier & permissions.

Manage Documents

1. Documents → New page / Index in vault / Index attachment; link to a contract; set visibility classification.
2. Use ‘Store and expose to portal’ to share a document with the client.

Manage Templates & Playbooks

Prerequisites. Workflow templates: Admin (workflows.edit_templates). Playbooks: Admin / Executive (playbooks.manage).

1. Workflows → New Template, or Playbooks → create.
2. Deploy to a contract/campaign to seed tasks.

Manage Accountability Events

1. Accountability → Run Check to refresh events → work the exception queue → escalate/reassign.

Coordinator

Responsibilities

• Own execution direction; delegate requests; drive contracts/milestones forward; clear blockers.

Accessible modules

• Role (home), Command Center, Strategy, Contracts, Requests, Boards, Rainfall, Approvals (own step), Documents.

Daily workflow

1. Open Role — today's actions, blocked cards, assigned requests.
2. Triage blockers (red tags) first.
3. Delegate requests with owners & due dates (the Golden Rule).
4. Move milestones along; submit the Coordinator approval step.
5. Issue commands/updates via Rainfall.

Step-by-step procedures

• See Create a Request, Assign/Reassign, Raise/Resolve a Red Tag, Approve a Milestone in the task guides.

Permissions

• Owns work; transitions contracts; first step of the milestone approval chain. Cannot create users or override ownership.

Common scenarios

• A request has no owner/due date → Accountability will escalate it; fix it.
• A milestone is blocked → resolve the CRITICAL red tag before approving.

Best practice

• Keep every request owned and due-dated — unowned/overdue work is exactly what Accountability escalates.

Manager

Responsibilities

• Ensure resources/docs/readiness; watch KPIs; close communication gaps.

Accessible modules

• Role (home), Documents, Tools, Performance, Requests, Rainfall, Approvals (as granted).

Daily workflow

1. Check readiness — missing docs, unsigned contracts, gaps.
2. Attach documents/resources to the work that needs them.
3. Watch team load & KPIs on Performance.
4. Close communication gaps via Rainfall.

Step-by-step procedures

• See Manage Documents, Create a Rainfall Message; readiness review uses Contracts + Documents.

Permissions

• Operator tier — can own work and view the full command surface. Does not create users (that's Accountability/Admin) or override ownership.

Common scenarios

• A deliverable is missing its doc → attach it from Documents before the milestone review.
• KPI failing → drill in on Performance and assign corrective requests.

Best practice

• Treat readiness as preventative — a resourced team rarely generates red tags.

Advisor

Responsibilities

• Review deliverables; approve (Advisor step); improve templates & systems.

Accessible modules

• Role (home), Approvals, Boards, Tools (Workflows/Playbooks), Documents, Requests.

Daily workflow

1. Clear board/deliverable reviews.
2. Act on milestone approvals needing the Advisor step (second in the chain).
3. Refine workflow templates & SOPs; address recurring failures.

Step-by-step procedures

• See Approve a Milestone, Manage Templates & Playbooks.

Permissions

• Reviews & approves (Advisor step); operator tier. Note: workflow-template creation is Admin-only; Advisors contribute via review and SOPs.

Common scenarios

• Same failure keeps recurring → encode the fix as a workflow/playbook step.
• Approval stuck before me → the Coordinator step must come first.

Best practice

• Approve against the standard, not the deadline — the Advisor step is a quality gate.

Accountability

Responsibilities

• Govern overdue/blocked/unowned/unaudited work; create users; keep Rainfall clean; hold the third approval step.

Accessible modules

• Accountability (home), Approvals, Rainfall, Requests, Contracts, Create & Manage Users.

Daily workflow

1. Run the check (or rely on the 15-min cron).
2. Work the exception queue top-down (escalated/overdue first).
3. Escalate / reassign stuck work with a reason.
4. Create users (role + function); govern access.

Step-by-step procedures

• See Create Users / Assign Roles, Manage Accountability Events, Approve a Milestone (Accountability step).

Permissions

Best practice

• Govern by exception — if the queue is empty, the system is healthy; don't micro-manage owned, on-time work.

Specialist

Responsibilities

• Do the work assigned to you; mark progress; flag blockers.

Accessible modules

• My Work only (plus Documents/Contracts in scope, Requests owned/assigned). No command grid.

Daily workflow

1. Open My Work.
2. Work assigned requests in priority order (Start).
3. Mark progress / Complete.
4. Raise a red tag if blocked.

Step-by-step procedures

• See Complete a Request, Raise a Red Tag.

Permissions

Common scenarios

• Blocked on a dependency → raise a red tag (don't sit on it); it surfaces to the owner and Accountability.
• Can't see a contract → it's out of your scope; ask the owner.

Best practice

• Keep states honest (Start when you start, Complete when done) — the accountability engine reads them.

Project Director

Responsibilities

• Cross-client execution health and contract lifecycle at a team level; sits above Coordinators; owns escalations at the PD step.

Accessible modules

• Role (home), Vision (cross-client roadmap), Command Center, Contracts, Requests, Approvals, Rainfall.

Daily workflow

1. Scan Vision for the cross-client pipeline and at-risk projects.
2. Review team load on Role; rebalance owners.
3. Clear PD-level escalations and approvals.
4. Deploy workflows where structure is missing.

Step-by-step procedures

• See Update a Contract / Move Stages, Approve a Milestone; workflow deploy via Manage Templates & Playbooks.

Permissions

• Operator/leadership — can own work, approve, deploy workflows (workflows.deploy), and is the first escalation target for communications. Does not create users.

Common scenarios

• Two clients contend for the same specialist → rebalance on Role.
• A campaign is drifting → drill from Vision into its contracts.

Best practice

• Manage at the campaign/portfolio level; let Coordinators run the per-contract detail.

Executive

Responsibilities

• Org-wide oversight; final approval/override authority; strategic direction.

Accessible modules

• Command Center (home), Strategy, Vision, Performance, Approvals, Ecosystem; full command surface.

Daily workflow

1. Read the Command Center cockpit + Performance for org health.
2. Act on the Executive (final) approval step.
3. Resolve escalations that reached the top of the ladder.
4. Set strategic direction via Strategy.

Step-by-step procedures

• See Approve a Milestone (Executive step); override ownership jointly with Accountability.

Permissions

• Top of the approval & escalation chain (final approver = Executive); can create contracts (contracts.create), deploy workflows, manage playbooks; override ownership only together with Accountability. Operator tier — full command surface.

Best practice

• Reserve override for genuine exceptions — the chain exists so quality isn't bypassed casually.

Administrator

Responsibilities

• Configure the system; manage users, clients and managed systems; maintain templates and integrations; run access reviews.

Accessible modules

• Everything — Admin, Client Management, Admin Log, System Factory, Workflows (templates), Integrations, plus the full command & execution surface.

Daily workflow

1. Run access reviews & assign policy acks (Admin).
2. Manage users/roles (shared with Accountability).
3. Maintain workflow templates and integrations.
4. Watch the Admin Log for anomalies.

Step-by-step procedures

• See Create Users / Assign Roles, Manage Templates & Playbooks; managed systems & access reviews on the Admin screen.

Permissions

• Holds all 38 permissions (admin.system_config, workflows.edit_templates, etc.). Use sparingly for day-to-day execution — that's the operating roles' job.

Best practice

• Keep roles least-privilege; let Accountability run governance and Coordinators run delivery.

Client Portal

Responsibilities

• Review progress and deliverables; give approvals; respond to requests directed at you.

Accessible modules

• Client Portal only — Workspace Summary, Timeline, Reports & Payout Status.

Daily/periodic workflow

1. Open the Portal.
2. Review milestones & campaign progress on the Timeline.
3. Review deliverables and give approvals.
4. Respond to any client requests.

Step-by-step procedures

• Activate the portal via the emailed activation link (12-char password); thereafter sign in to /portal.

Permissions

Best practice

• Approve promptly — client approvals are part of the milestone chain and stalled approvals delay payout.

Field & data dictionary (Labyrinth)

Verified against the Prisma schema + state engines. auto = system-set. The Golden Rule marks the fields a request cannot exist without.

Contract

Milestone

Request (Golden Rule)

RedTag · Communication · User

Key enumerations

Permission matrix (exact)

The complete grant table from the live permission model — 38 permissions × 9 role columns. ADMIN holds all 38. Legend: ✓ granted · · not granted.

ADM Admin · EXEC Executive · PD Project Director · ACC Accountability · MGR Manager · CRD Coordinator · ADV Advisor · SPC Specialist · CLI Client. MEMBER mirrors SPECIALIST. 38 permissions × 9 roles. Source: labyrinth-os/src/lib/permissions.ts.

Permissions in practice

Practical access scenarios — view / create / edit / delete / approve / manage.

¹ Overriding ownership requires Accountability together with Executive. Examples: Can a Specialist own a contract? No — they're an assignee. Who creates users? Accountability or Admin. Who creates workflow templates? Admin only. Who gives the final milestone approval? Executive (step 4).

Reporting & analytics

Where the numbers live

• Command Center — Pipeline Value, Active Contracts, Red Tags, Overdue, Unassigned.
• Performance — department KPI scorecards (Average Score, Needs Attention, Failing KPIs, Verified) with function filters.
• Analytics — Campaign Risk, Milestones by Status, Requests Created (30-day).
• Handoffs — SLA board (48h onboarding / 72h launch, SLA risks).
• Payroll — Queued / Eligible / Restricted payouts.
• Workforce — headcount by department, role-type breakdown, utilization.

Common reporting uses

• Spot drift: Command Center + Analytics campaign risk.
• Quality: Performance failing KPIs + Verified ratio.
• Throughput: Requests Created trend + Boards.
• Cash: Payroll eligibility vs investigation holds.

Administration & configuration

Resolved from code — the items the older manual marked “[confirm with dev]” now have answers.

Troubleshooting

Validation & state errors

Permission & approval errors

Accountability, hand-off & access

End-to-end walkthroughs

Delivery: Contract → Milestones → Requests → Approval → Completion

1. Arrive (System Factory). A CRM close lands a contract at SIGNED/ONBOARDING; Accountability confirms ownership. (System Factory / Handoffs.)
2. Plan (Contracts). The Coordinator seeds milestones (NOT_STARTED) and delegates requests (Golden Rule: contract + title + tag + priority + owner + due). (Contracts / Requests.)
3. Execute (My Work). Specialists Start and Complete their requests; blockers become red tags. (My Work / Red Tags.)
4. Review (Approvals). Milestone moves to OPTIMIZED, then the chain signs off: Coordinator → Advisor → Accountability → Executive → EXECUTED. (Approvals.)
5. Complete & pay (Contracts → Payroll). All milestones EXECUTED, red tags clear → CONFIRMING → COMPLETED; after the investigation window → PAID. (Contracts / Payroll.)

Approval flow: Submission → Review → Approval → Escalation

1. Milestone reaches OPTIMIZED → enters the Approvals queue.
2. Each chain role reviews and approves in order (or rejects with notes).
3. All four approved → EXECUTED.
4. If a step stalls past its window, the linked owner is notified and the communications escalation advances PD → Accountability → Executive.

Accountability flow: Request → Overdue → Escalation → Resolution

1. A request passes its dueAt.
2. The 15-min cron sets REMINDER (before due) → WARNING (at +warningHours) → ESCALATED (at +escalationHours), per the contract's client-package policy.
3. It surfaces on the Accountability exception queue.
4. Accountability reassigns/extends with a reason, or the owner completes it — clearing the escalation.

Receiving the hand-off (for users)

What the delivery team sees when a new client arrives — and how to verify it.

What arrives

• A new contract at stage SIGNED / journey ONBOARDING named “<Client> Operating Launch”, with three starter milestones (handoff, campaign readiness, first campaign) and operational requests (schedule kickoff, confirm onboarding access, publish first plan), plus a Rainfall message and a system event.

Where to find it

• System Factory (the live hand-off queue), Handoffs (SLA board) and Contracts. Accountability confirms ownership; the Coordinator seeds milestones and delegates.

Prerequisites & post-conditions

• Pre: the upstream deal/proposal completed (CRM Closed-Won, or Nexus proposal acceptance).
• Post: an owned, governed contract ready for execution — requests appear in owners' My Work.

QA verification — test plan

Turn-key checks a QA tester can run to prove the behaviours, not just read about them. Items 1–6 were verified live on the dev environment; expected results are exact.

Core flows