Skip to content
Press / to search

Admin Console

Trust + Decision plane operator surface for packs, policies, decision specs, intent catalogs, approvals, and the review queue.

Reference DesignLast reviewed: Edit on GitHub
At a glance
Trust planeDecision planeControl over the other four

The operator surface for every governed artifact — packs, policies, DecisionSpecs, approval gates, memory review.

Inputs
  • Read access to every registry: pack, policy bundles, Decision Catalog, Intent-Task Catalog, adapter registry
  • Live queues: approval gates, memory review, improvement proposals
  • Trace bundles + scorecards from Observability
  • RBAC and identity assertions for operators
Outputs
  • Signed pack / policy / DecisionSpec promotions
  • Approval-gate verdicts (approve / deny with rationale)
  • Memory review-queue actions (approve / edit / reject)
  • Improvement-proposal verdicts (ship / discard with rationale)
  • Audit log entries for every operator action
Canonical types
  • SignedPromotion
  • ApprovalVerdict
  • ReviewQueueAction
  • AuditLogEntry

Reference Architecture

The Admin Console is the operator surface that spans the Trust and Decision planes. It is where packs are reviewed, policies are linted and signed, Decision Specs are versioned, approval gates are answered, and the memory review queue is worked.

Definition

A web surface (and equivalent CLI) over the registries and queues that drive the runtime: pack registry, policy bundles, Decision Catalog, Intent-Task Catalog, adapter registry, approval queue, memory review queue, replay harness, scorecard dashboards.

Why it exists

Without a single operator surface, governance work scatters across spreadsheets, ticket systems, and bespoke UIs. The Console is the change-control choke point that makes promotion deliberate.

Inputs

  • Read access to every registry: pack, policy bundles, Decision Catalog, Intent-Task Catalog, adapter registry
  • Live queues: approval gates, memory review, improvement proposals
  • Trace bundles + scorecards from the Observability component
  • RBAC and identity assertions for operators

Outputs

  • Signed pack / policy / DecisionSpec promotions
  • Approval-gate verdicts (approve / deny with rationale)
  • Memory review-queue actions (approve / edit / reject)
  • Improvement-proposal verdicts (ship / discard with rationale)
  • Audit log entries for every operator action

Surfaces

SurfacePurpose
Pack registryauthor, lint, sign, publish, deprecate Context Pack
Policy bundle editorauthor JsonLogic rules; lint for unreachable / unsatisfiable; sign
Decision Catalogauthor DecisionSpec; bind to policy rules; version
Intent-Task Catalogauthor Intents and TaskTemplates; bind to DecisionSpec
Adapter registryonboard adapters; declare approval_mode per capability
Approval queueanswer gate proposals against frozen evidence snapshots
Memory review queuepromote / edit / reject candidate facts
Improvement proposalsreview Insight Synthesizer / Strategy Compiler / Autotune outputs
Replay harnessre-run past Decision Records against pinned snapshot
scorecard dashboardsper intent, per pack version, per tenant

How it works

  1. Operator authenticates with WebAuthn-grade assertion.
  2. RBAC scopes the editable surfaces (e.g., policy_writer, approver, correction_writer).
  3. Edits go through review with required approver roles per change class.
  4. Promotions are signed and recorded in the registry’s append-only log.
  5. Operator actions emit audit records bound to the operator’s identity.

Failure modes

  • Operator action without assertion — refuse.
  • Promotion bypassing required reviewer role — refuse.
  • Approval-gate answer without frozen evidence snapshot match — refuse and emit security event.
  • Stale registry view in the UI causing accidental rollback — mitigated by optimistic concurrency on every edit.

Operational concerns

  • Separation of duties enforced by RBAC, not by UX.
  • Operator throughput on each queue monitored and alerted.
  • WebAuthn / hardware-key requirement for destructive approvals.
  • Audit access for tenants on shared environments.

Evaluation metrics

  • Time from change authored → promoted.
  • Approval gate p50 / p99 response time.
  • Memory review queue throughput and reject rate.
  • Operator action audit completeness (target: 100%).