Skip to content

ADR-0007: POWER 3.8 North-Star Control Plane Architecture

Status

Accepted as the authoritative architectural foundation for POWER 3.8. This decision freezes product and architectural direction for Gate P38-G1. It authorizes the governance sequence P38-G1 → P38-G2 → Phase 5C (P38-WP01). It does not implement runtime features or authorize premature version bumps.

Context

POWER originated as an AI-native knowledge substrate and structured Second Brain framework combining P.A.R.A., OKF metadata, hierarchical indexing, and local retrieval.

In real engineering workflows with autonomous and pair-programming AI agents (e.g. Gemini, Codex, OpenCode), probabilistic AI models operate directly against live filesystems, Git repositories, and infrastructure hosts. This introduces critical failure modes: - Hallucinated authority: Models declare tasks complete without empirical verification. - Unbounded mutations: Models perform destructive, unrecoverable, or duplicate actions. - Context degradation: Conversations and private model context are lost across crashes or session transitions, preventing reliable cross-agent continuation. - Authority inversion: Retrieved or model-generated text is mistaken for canonical truth.

POWER 3.8 recognizes that knowledge management remains a foundational data substrate, but the overarching role of POWER is to govern the boundary between probabilistic AI reasoning and deterministic system reality.

Decision

1. Target Product Direction

POWER is a local-first control plane for verifiable AI-assisted software engineering and Linux infrastructure operations.

POWER governs the boundary between probabilistic AI reasoning and real system state.

Knowledge management and Second Brain functionality are: 

SUPPORTED USE CASE / DATA SUBSTRATE
rather than: 
PRIMARY PRODUCT IDENTITY

POWER is explicitly NOT: - a generic Second Brain or note-taking application; - a RAG framework; - a vector database; - a graph database; - a generic memory system; - a generic agent runtime or workflow engine.

2. The POWER Proof Chain

POWER exists to make AI-assisted engineering work: - explicit - bounded - traceable - recoverable - verifiable - cross-agent resumable

The core lifecycle is the POWER Proof Chain:

GOAL
  ↓
EVIDENCE
  ↓
PLAN
  ↓
AUTHORITY
  ↓
ACTION
  ↓
VERIFICATION
  ↓
RECEIPT
  ↓
CANONICAL STATE

Epistemic Contract

Until formal verification semantics exist: 

PROOF != MATHEMATICAL PROOF
PROOF != FORMAL VERIFICATION
PROOF != AUTOMATIC CRYPTOGRAPHIC GUARANTEE
Public interfaces and documentation must use exact terms: verifiable, evidence-backed, traceable, and governed.

3. The Three Authorities

POWER enforces three explicit, non-overlapping authority boundaries:

  1. Truth Authority: What information is canonical?
  2. Action Authority: What effects may this principal perform?
  3. Completion Authority: What evidence allows a task to become complete?

Binding Invariant

LLM OUTPUT NEVER GRANTS AUTHORITY

An LLM may propose facts, relationships, plans, actions, summaries, repairs, or completion claims, but cannot grant itself authority.

4. Canonical vs. Derived State

POWER strictly partitions state into canonical authoritative owners and rebuildable derived views:

Canonical State Owners

  • PSE / Project State Event Ledger: Append-only recorded facts and lifecycle events.
  • ProjectStateService: State machine governing project lifecycle.
  • TaskService / TaskStore (PowerTask): Canonical task definitions, dependencies, and gates.
  • DecisionService: Recorded architectural and operational decisions.
  • Approved Transactional Memory Mutations: Explicitly governed durable facts.
  • Declared Source Artifacts: Versioned code, configuration, and documentation.
  • Action Receipts: Cryptographically signed or digest-pinned evidence of completed effects.
  • Verification Receipts: Empirical proof of passing checks, tests, or inspection commands.

Derived & Rebuildable State

  • Full-Text Search (FTS) indexes
  • Dense vector indexes & embeddings
  • Reranker scoring outputs
  • Synthesized summaries & abstracts
  • EvidenceGraph projections
  • ExecutionGraph views
  • Materialized database views
  • Model-generated entities & relations
  • Execution and retrieval caches

Binding Invariant

DERIVED STATE MUST NEVER SILENTLY BECOME CANONICAL AUTHORITY

5. EvidenceGraph Specification

EvidenceGraph is a typed, bounded, rebuildable, provenance-preserving, non-authoritative projection over canonical evidence.

  • Every graph assertion must trace directly to canonical evidence.
  • Required node/edge metadata: source_identity, source_digest, observed_at, recorded_at, optional valid_from/valid_to, authority_class, and provenance.
  • Traversals are strictly bounded in depth, fan-out, result count, and CPU cost.
  • Apache AGE / PostgreSQL are NOT mandatory; SQLite and in-memory graph projections serve Edge.

6. ExecutionGraph Specification

ExecutionGraph is a derived dependency and progress view over existing canonical authority: - Derived directly from PowerTask, dependencies, open_gates, next_action, execution_state, PSE events, and Action/Verification receipts. - POWER does NOT introduce a second task, planning, or workflow database.

7. ContextPack Specification

A ContextPack is a bounded, explainable, proof-carrying context payload compiled for an agent: - Explicitly contains: goal/intent, scope, EvidenceRefs, authority_class, provenance, freshness, temporal_validity, contradiction_state, retrieval_rationale, budget/token_cost, and declared omissions. - Binding Rule: Semantic similarity never overrides authority ordering.

8. Observation Contract (power.observation.v1)

POWER defines a versioned append-only observation contract: 

agent / tool activity
        ↓
ObservationEnvelope
        ↓
RawEvent (append-only)
        ↓
session correlation
        ↓
privacy / retention / sensitivity filtering
        ↓
noise & taint classification
        ↓
semantic candidates
        ↓
governed disposition (discard | candidate | review)

Binding Invariant

RawEvent != Knowledge
Agent output != Fact
Conversation != Canonical state
Embedding != Authority
Raw prompt and completion payloads are never retained indiscriminately; capture enforces retention and sensitivity boundaries.

9. Interoperability Boundaries

POWER adheres to open, standard interfaces: - Agent → Tools/Resources: Model Context Protocol (MCP). - Agent → Agent: Agent-to-Agent (A2A) protocol only when justified by a concrete consumer. - Telemetry: OpenTelemetry-compatible export adapters. - Truth, Authority, Verification, & State: POWER Control Plane.

MCP Tasks Extension

POWER does not assume speculative MCP Tasks SDK support. Support is capability-detected. PowerTask remains the canonical POWER domain model regardless of client transport.

10. Vendor-Neutral Artifact Storage

POWER defines an abstract ArtifactStore: - Default Edge Implementation: LocalCASArtifactStore (filesystem content-addressed storage, SHA-256 digests, size bounds, retention policies). - Optional Hub Implementation: S3ArtifactStore (S3/MinIO compatible). - MinIO or remote object stores are never mandatory for local-first operations.

11. POWER Edge vs. Optional POWER Hub

  • POWER Edge (Default & First-Class): Python, SQLite, local filesystem, SQLite FTS, optional local ONNX embeddings, local CAS, local stdio MCP. Zero mandatory daemon services.
  • POWER Hub (Optional Benchmark-Gated Target): PostgreSQL, Apache AGE, pgvector, S3 storage, remote MCP, A2A, OTel export. Promotion rule: Hub capabilities require measurable benchmark wins and an explicit ADR before adoption.

12. Security as a Cross-Cutting Invariant

Security is enforced across all gates: - Least privilege, explicit principal identity, bounded authority. - Fail-closed mutation semantics and path containment. - Secret isolation (secrets never enter LLM context, prompts, tasks, receipts, or notes). - Untrusted model and retrieved content handling: 

UNTRUSTED MODEL OUTPUT OR RETRIEVED CONTENT
CANNOT GRANT TRUTH, ACTION OR COMPLETION AUTHORITY

13. Primary Verification Benchmark: Zero-Explanation Handoff

Synthetic test suites are necessary but not sufficient. POWER validation requires real-work scenarios across two different agent engines, forced crashes, forced stale state, and corrupt evidence.

Zero-Explanation Handoff Benchmark

  1. Agent A performs real engineering work and stops abruptly.
  2. Agent B is initialized with:
  3. NO prior conversation transcript;
  4. NO hidden prompt injection;
  5. NO private model memory.
  6. Agent B reads only canonical POWER state and reconstructs: goal, canonical state, completed work, blockers, allowed actions, and verification criteria.
  7. Mandatory release criteria: 
    DUPLICATE_EFFECTFUL_ACTIONS = 0
UNAUTHORIZED_MUTATIONS = 0
FALSE_DONE = 0

Non-Goals

POWER 3.8 explicitly does NOT build: - a new LLM framework or model provider abstraction; - an embedded vector database engine; - a new graph database engine; - a proprietary object storage service; - a proprietary agent transport protocol; - a distributed workflow orchestrator (e.g. Temporal replacement); - an autonomous agent runtime.

None of the following are mandatory for POWER Edge: PostgreSQL, Apache AGE, pgvector, S3, MinIO, A2A, Temporal, Dapr, Restate, DBOS, or remote cloud services.

Consequences

  • Positive:
  • Unambiguous product identity aligned across code, documentation, and agent prompts.
  • Provable boundaries between probabilistic model proposals and system state.
  • Zero-drift guarantee across development gates.
  • Negative:
  • Requires updating all current-surface documentation (Gate P38-G2).
  • Explicitly restricts unvalidated feature work until architecture gates pass.