LightGrid Mission Control

Mission Control is the coordination layer for LightGrid operators, missions, governance, memory, and supervised AI recommendations.

Control Pattern

  1. 1AI Recommendation
  2. 2Policy Review
  3. 3Human Approval
  4. 4Controlled Execution
  5. 5Audit Ledger

DUCK Steward Queue

Review submitted DUCK proof, triage contributor follow-up, and leave an audit trail.

Open DUCK queue

Current Operational Status

Operator Network

Forming

watch

Core stewards and builders are being mapped into accountable lanes.

Governance Queue

4 reviews

watch

Actions are staged for review, simulation, or approval only.

Mission Readiness

71%

ready

Priority missions have owners, but execution gates remain supervised.

Knowledge Base

Seeded

stable

Static operating memory is available for Phase 1 planning.

Treasury Controls

Locked

stable

No wallet, transfer, or token execution is connected.

Infrastructure Signals

Watching

watch

Signals are manually modeled until adapters are approved.

Security Posture

Guarded

stable

AI recommendations are filtered through policy and human approval.

Node Replication

Draft

blocked

Replication checklist is not yet approved for field execution.

Active Missions

Operational work is staged as assigned, queued, blocked, or under review.

Harden lead capture queue

Builder + Sentinel

highactive

Next: Verify production observability gates before launch.

Build operator onboarding path

Scribe + Steward

mediumqueued

Next: Draft first operator readiness checklist.

Define governance readiness gates

Architect + Steward

highreview

Next: Separate advisory proposals from executable authority.

Prepare Juneteenth funnel report

Scribe

mediumactive

Next: Summarize RSVPs, ticket CTAs, and partner follow-up.

Draft node replication checklist

Architect

highblocked

Next: Wait for policy and land/legal review criteria.

Map treasury control plane

Treasury Keeper

criticalreview

Next: Keep all actions simulated until approval ledger exists.

Governance Queue

Governance work is modeled as review and simulation, not live execution.

Approve new operator role model

review

Reviewer: Steward Circle

Role authority cannot grant execution rights yet.

Review proposal readiness criteria

simulation

Reviewer: Architect + Sentinel

Simulation only; no governance execution is live.

Define multisig escalation policy

draft

Reviewer: Treasury Keeper

No wallet integration exists in Phase 1.

Validate community feedback metrics

approval

Reviewer: Scribe + Steward

Metrics inform decisions; they do not automate decisions.

Operator Roles

Roles define responsibility, not unchecked authority.

  • Architect

    ready

    System design, dependency planning, and readiness decomposition.

  • Sentinel

    ready

    Threat modeling, policy risk detection, and control validation.

  • Builder

    watch

    Implementation planning, test coverage, and safe patch proposals.

  • Steward

    watch

    Governance interpretation, approvals, and escalation routing.

  • Scribe

    stable

    Decision records, summaries, onboarding, and operator memory.

Operator Console

Authenticated operator cockpit for missions, recommendations, approval requests, and decision history.

Hydration

Locked

Operator

No authenticated operator

Authority

Read-only fallback is disabled when persistence is configured.

Mission Control requires an authenticated operator session.

Authenticate with Supabase and bind auth.users.id to an active Mission Control operator.

Admin

Can review approvals and manage operator-grade gates.

Operator

Can create missions, recommendations, and action requests.

Viewer

Read-only operator context; mutation controls stay gated.

Empty state

Panels render clear empty messages when no records are available.

Loading state

Server hydration keeps loading off the client until authenticated data is ready.

Error state

Hydration failures fall back safely without exposing backend internals.

Mission Registry

Durable mission records when Supabase is available; fallback records otherwise.

No missions are available for this operator context.

Safe Create / Review Forms

Operator-facing form shells for protected API workflows. Browser forms do not carry server secrets.

Create Mission

Requires mission:create.

Disabled

Create Readiness Gate

Requires readiness_gate:create.

Disabled

Create Governance Action

Requires governance_action:create.

Disabled

Submit Recommendation

Requires recommendation:create.

Disabled

Create Action Request

Requires action_request:create.

Disabled

Approve / Reject Action Request

Requires action_request:approve.

Disabled

Review Recommendation

Requires recommendation:review.

Disabled

Form submission requires authenticated operator authority through protected API routes. No execution action is available from this console.

Action Request Queue

Requests can be proposed or reviewed. Approval never executes the request.

No pending action requests.

Recommendation Review

AI signals are classified for human review and optional action-request creation.

No recommendations are awaiting review.

Approval Decision History

Append-only decision records for action requests.

No approval decision history yet.

Recommendation Review History

Append-only review records for AI-generated signals.

No recommendation review history yet.

Operator Activity Log

Append-only audit trail for mutation attempts, denials, failures, and accepted changes.

Trace related API responses and audit events by request ID. Request IDs are diagnostic handles, not credentials or approval proof.

No operator activity matches the selected filters.

System Signals

Signals are modeled locally in Phase 1. No external telemetry adapters are connected.

Policy Layer

watch

Execution disabled until policy ledger is connected.

Memory

info

Decision records need source citations before approval use.

Security

info

External adapters are intentionally disconnected in Phase 1.

Treasury

urgent

Treasury actions remain simulated and awaiting human approval.

AI Recommendations

Recommendations are advisory. Policy filters and humans approve before controlled workflow.

Prioritize production readiness checks for lead capture before new funnel expansion.

high confidence

Requires operator review; no autonomous deployment.

Create a proposal intake template before opening broader governance submissions.

medium confidence

Policy review required before governance routing.

Keep node replication in checklist mode until land, safety, and treasury controls are defined.

high confidence

Human approval required for field execution.

Readiness Gates

Execution readiness is gated by identity, policy, approval, and audit design.

Identity model defined

in_progress

Operator archetypes and roles exist as seed model.

Mission taxonomy approved

in_progress

Mission types are modeled but not yet governance-approved.

Policy engine selected

blocked

Decision pattern is defined; durable policy ledger is next.

Audit ledger designed

in_progress

Ledger concept exists; Mission Control does not persist yet.

Human approval flow mapped

complete

AI Recommendation -> Policy Review -> Human Approval -> Controlled Execution -> Audit Ledger.

Supabase persistence planned

in_progress

Phase 1 uses typed seed data only.

Agent execution disabled until policy layer exists

complete

No production automation or external API connection is present.

Policy-Safe Next Actions

All actions remain proposed, queued, simulated, or awaiting approval.

Queue mission workflow readiness review

queued

Queued for steward approval; no action executes from this page.

Simulate governance proposal routing

simulated

Simulation only; no vote execution is connected.

Prepare treasury control plane review

awaiting_approval

Awaiting approval; no wallet, transfer, or token action exists.

Propose memory update from mission notes

proposed

Proposed update requires review before becoming operating memory.

Durable Mission Registry

Phase 2 adds server-only mission persistence with strict validation. The page still falls back to typed seed data when Supabase is unavailable.

Mission records are modeled as proposed, active, blocked, completed, or archived. Operational work remains queued for operator review.

Policy Decision Ledger

Policy outcomes are append-only by design and are not exposed through update or delete repository methods.

Every sensitive recommendation should become a policy decision record before approval or denial.

Operator Authority Placeholder

Authority is represented as a boundary, not as a completed RBAC system.

API writes are gated server-side. Authenticated operator roles are intentionally deferred until the identity layer is finalized.

Governance Queue Persistence

Governance actions can be stored as draft, review, approved, rejected, or deferred.

Governance records capture required authority and deadlines without implying live governance execution.

Readiness Gate Tracking

Readiness gates persist the conditions required before later phases can advance.

Gates are tracked as not started, in progress, satisfied, or blocked so operators can see what authority and evidence are missing.

Phase 2 Foundation

Identity -> persistence -> policy ledger -> approval flow -> AI recommendation queue.

No autonomous agents are introduced in this phase. The system is preparing durable mission records and audit-ready policy decisions first.

Operator Identity

Phase 3 introduces an authenticated operator model before any AI recommendation queue or execution workflow.

Operator identity is resolved server-side. Temporary development headers are placeholders only and are not a production authentication pattern.

Authority Gates

Mutations require explicit Mission Control authorities such as mission:create or policy_decision:append.

Operator authority is now the required gate for Mission Control mutations. Admins receive all authorities, operators receive scoped mutation rights, and viewers remain read-only.

Protected Mutations

Mission, readiness, governance, and policy ledger writes are checked before validation side effects.

Unauthorized requests are denied. Insufficient-authority requests are rejected. Public errors remain generic.

Approval-Ready Actions

Action request types are modeled for future approval workflow, but no execution routes exist.

Action requests can be proposed, reviewed, approved, denied, or expired in later phases. Autonomous execution remains disabled.

Current Operator Context

Operator context is a protected server concern, not a client-controlled role claim.

AI recommendations are still deferred until the approval and policy layers mature.

Pending Approval Queue

Phase 4 stores approval requests and decision history. Approval is not execution.

Authorize controlled readiness review for lead queue production observability

review required

Requires mission:update. Requester and approver must be separate operators. Approved requests authorize only future controlled workflow.

Approve governance readiness criteria for operator review

proposed

Requires governance_action:update. Requester and approver must be separate operators. Approved requests authorize only future controlled workflow.

Approval Decision History

Approve, reject, and expire decisions append immutable history records.

Status transitions stop at approved, denied, or expired. Approved does not mean executed, and no execution adapter is connected.

Supervised AI Recommendation Queue

Phase 5 accepts AI-generated signals for policy classification and human review only.

Lead queue observability readiness

action request eligible

Create an operator-reviewed action request for lead queue observability verification.

AI may recommend. Operators may request. Admins may approve. Systems still do not execute.

Node replication remains checklist-only

review required

Keep node replication as a reviewed planning item until policy gates are satisfied.

AI may recommend. Operators may request. Admins may approve. Systems still do not execute.

Recommendation Review Flow

Recommendation intake -> policy classification -> human review -> optional action-request creation -> no execution.

Accepted recommendations become reviewed signals. Action-worthy recommendations must be converted into Phase 4 action requests and still require approval before any future controlled workflow path.

Phase 1 Scope

This is the first static operating surface for Mission Control. It is not a completed automation platform.

  • Static command center
  • Typed operational model
  • Supervised AI action pattern
  • Governance/readiness visibility
  • No autonomous execution

Next Build Steps

These are planned implementation steps, not live integrations.

  • Connect missions to Supabase
  • Add authenticated operator roles
  • Add policy decision ledger
  • Add governance proposal intake
  • Add AI recommendation review queue
  • Add telemetry adapters
Mission Control | LightGrid | LightGrid