XIOPro Production Blueprint v5.0¶

Part 1 — Foundations¶

1. Purpose¶

XIOPro is the internal AI operating system of STRUXIO.

It exists to:

convert unstructured human intent into structured execution
orchestrate multi-brain and multi-agent work reliably
preserve state, decisions, and knowledge over time
govern execution, prompting, modules, and evolution
optimize quality, stability, trust, and resource use
remain replaceable across providers, runtimes, and infrastructure

It is not:

a chatbot wrapper
a dashboard
a prompt collection
a single vendor workflow

It is the execution engine and control substrate of STRUXIO.

2. Core Problem¶

Most current AI work is fragile because it suffers from:

ephemeral context
chat-bound state
weak execution structure
poor ownership of work
weak recoverability
poor cost visibility
vendor dependency
ungoverned drift in rules, prompts, and modules

This produces:

lost ideas
duplicated work
unstable execution
poor reuse
weak trust
high hidden cost

XIOPro exists to solve this.

3. System Mission¶

Transform unstructured human intent into governed, persistent, recoverable, multi-agent execution — with full traceability, optimization, and compounding intelligence.

4. Non-Negotiable Design Constraints¶

4.1 Provider Independence¶

models must be swappable
no critical logic tied to one vendor
routing must remain abstractable

4.2 Headless First¶

all critical execution must work without UI
CLI and agent runtimes remain primary
UI is a governed control surface, not the engine

4.3 Durable State¶

nothing important lives only in chat
execution-changing interaction must become durable system state
runtime, session, escalation, decision, and cost records must persist

4.4 Deterministic Bias¶

prefer explicit logic over hidden behavior
actions should be explainable
state transitions should be queryable

4.5 Human Control Points¶

discussion is a real state
approval is a real state
founder intervention must be durable and traceable

4.5A Immediate Start vs Stage Gates¶

Agents begin work immediately upon assignment. Assignment IS the start signal -- agents must not wait for a second confirmation.

However, within execution, defined stage gates require explicit approval before the agent proceeds past the gate. These include protected deployments, policy mutations, cost threshold breaches, and recovery decisions with business tradeoffs.

These are not contradictory:

Start freely: assignment triggers execution immediately
Gate at checkpoints: agents pause at defined approval gates and wait for the required decision

This principle is enforced in the governance layer. See Part 7, Section 3.3A for the full specification.

4.6 Cost Awareness Everywhere¶

every execution produces resource impact
cost and usage must be visible, attributable, and actionable
optimization is not optional

4.7 Knowledge Compounding¶

the system must learn from success, failure, correction, research, and reflection
learning must become reusable assets or governed proposals

4.8 Replaceability¶

Every major component should remain replaceable:

providers
modules
agent runtimes
prompting behavior
knowledge services
UI
infrastructure

4.9 Optimization Under Constraint¶

XIOPro is an optimization system.

It must optimize constrained resources such as:

compute
memory
bandwidth
time / latency
monetary cost
subscription utilization

while maximizing:

quality
stability
trust

4.10 Host Resource Awareness¶

XIOPro runs across multiple physical and cloud hosts. Each host has finite resources that constrain how many agents, services, and workloads it can support.

The system must:

maintain a Host Registry as a first-class ODM object (see Part 3, Section 4.1B for schema)
know each host's hardware limits (vCPUs, RAM, SSD, network)
calculate the estimated max concurrent agents per host
prevent agent spawning that would exceed host capacity
support multi-host execution (cloud + local machines)
register new hosts when they are commissioned
decommission hosts gracefully when retired

Rules¶

no agent may be spawned if it would push the host past 85% RAM utilization
OOM incidents must trigger automatic agent reduction (graceful shutdown of lowest-priority agents)
adding a new host requires: network setup (Tailscale), Docker install, agent runtime install, host registration in ODM
host capacity is recalculated whenever services are added/removed

Implications Across Parts¶

Part 3 (ODM): Host is a registered entity with full schema (Section 4.1B)
Part 4 (Agent System): the orchestrator checks host capacity before spawning (Section 4.2F)
Part 7 (Governance): the governor monitors host health, breakers trigger on memory pressure
Part 8 (Infrastructure): Host registry is source of truth for capacity planning
Part 10 (Work Plan): Agent count per sprint bounded by host capacity

4.11 Agent Runtime Currency¶

Agent runtimes (Claude Code, LLM providers, tools) release updates frequently. XIOPro must maintain currency across all agents and hosts.

The system must:

verify agent runtime versions daily across all hosts
detect when updates are available (Claude Code, Ruflo, LLM provider SDKs, CLI tools)
apply updates in a controlled manner (not silently mid-execution)
maintain version parity across hosts (Hetzner and Mac must run the same Claude Code version)
log version changes in the audit trail
alert the founder when a major version change is available

Daily Version Check¶

The governor (or a scheduled job) should run daily:

daily_version_check:
  schedule: "06:00 UTC"
  checks:
    - claude_code_version    # claude --version on each host
    - ruflo_version          # ruflo --version
    - litellm_version        # container image tag
    - python_version         # uv python list
    - cli_tools_versions     # gh, jq, yq, uv, rg, fd
    - docker_image_tags      # all running containers
  actions:
    - compare_across_hosts   # ensure parity
    - check_for_updates      # npm view, apt, docker hub
    - report_to_founder      # morning brief includes version status
    - apply_if_approved      # non-breaking updates can auto-apply; major versions require approval

Rules¶

never update a runtime while agents are executing
major version changes require founder approval
all hosts must be updated together (no version drift)
version state is recorded in the Host Registry object

4.12 Control Bus as Coordination Backbone¶

The XIOPro Control Bus is the unified communication, coordination, and intervention backbone for all agents and surfaces. It merges persistent messaging with orchestration into a single always-on PostgreSQL-backed service.

Every agent communicates through the Control Bus for messaging, task assignment, intervention, spawning, and cost tracking. The Bus provides SSE push delivery for real-time updates and REST APIs for all coordination operations.

Full specification: Part 2, Section 5.8.

4.13 CLI-First¶

Prefer CLI tools over MCP wrappers where both exist.

CLI pipelines are faster, more composable, and more debuggable.

Where a capability is available both as a CLI tool and as an MCP wrapper, the CLI path is the default execution path. MCP may be used for integration or discovery, but CLI is preferred for production pipelines and agent execution.

4.14 Review and Testing Everywhere¶

Every significant XIOPro output must be reviewed and tested before trusted.

Output Type	Review Method	Testing Method
Code	Code review (agent or human)	Unit tests, integration tests, completion tests
Architecture/Blueprint	Peer review (cross-agent or human)	Consistency checks, external review
Documents (docs-as-code)	Content review, fact-checking	Schema validation (YAML frontmatter), link checking
Rules and Skills	Rule steward validation	Conflict detection, performance comparison
Research outputs	Source verification, lineage check	Cross-reference against known facts
Decisions	Human approval for protected changes	Impact assessment
Configurations	Diff review	Dry-run, health check after apply
Deployments	Pre-deploy checklist	Health endpoints, smoke tests, rollback verification
Knowledge vault entries	Librarian validation	Metadata completeness, duplicate detection
Ticket definitions	Orchestrator review	Completeness check (all required fields)

Principle: "No output is trusted by default. Trust is earned through review and test."

This is a core AGI safety principle: autonomous agents produce at high volume, but without verification, errors compound silently.

Implementation:

Every task has a review_required flag
Every activity produces an evaluation record
Completion test is mandatory for ALL tickets (not just code)
Docs-as-code validated: YAML frontmatter, completeness, cross-references
Optimizer periodically reviews past outputs for quality degradation

4A. Key Terms and Definitions¶

Term	Definition
T1P (Top 1% Percentile)	The standard of domain expertise XIOPro applies. Every template, every agent specialization, every process design targets the top 1% of practitioners in that domain. T1P is not aspirational — it's the baseline.
T1P Posture	The operational readiness class of a subsystem: Active, Active but Narrow, Proposal-Oriented, or Deferred in Maturity (see Section 12A).
Control Bus	The unified communication, coordination, and intervention backbone for all agents and surfaces (see Section 4.12 and Part 2, Section 5.8).
ODM (Operational Domain Model)	The executable domain model: discussions, tickets, tasks, sessions, decisions, cost, and all durable state (see Part 3).
Role Bundle	A named collection of agent capabilities that can be assigned to any agent (see Section 8.2).
GO / HO / PO / IO	Layer designations in the Swarm v5.0 hierarchy: Global Orchestrator, Host Orchestrator, Project Orchestrator, Interaction Orchestrator (see Part 10).
Sprint Compression	The reduction of traditional 1-3 week sprints to 1-3 hours through parallel AI agent execution, T1P automation, and Bus-mediated coordination.

4B. Sprint Compression¶

XIOPro compresses traditional sprint timelines by orders of magnitude: - Traditional agile sprint: 1-3 weeks - XIOPro sprint: 1-3 hours

This is achieved through: 1. Parallel agent execution — 10+ agents working simultaneously on different tickets 2. T1P automation — every stage gate, review, and verification is automated at top 1% quality 3. Bus-mediated coordination — no human bottleneck for inter-agent communication 4. Template-driven execution — projects don't need to figure out "how" — the template defines it 5. Review Engine — 4-reviewer external validation completes in minutes, not days 6. Progressive prototyping — mockup to production in hours, not months

A project that would take a traditional team 3-6 months can be delivered in 1-2 weeks with XIOPro. This is the core promise of the platform.

5. XIOPro vs STRUXIO¶

Layer	Role
XIOPro	Internal AI operating system
STRUXIO Products	Revenue-generating products built using XIOPro
STRUXIO	Broader product/platform direction

XIOPro builds STRUXIO products. The first product (see MVP1_PRODUCT_SPEC.md) validates XIOPro. Products also help validate the wider STRUXIO platform direction.

6. Mental Model¶

XIOPro is simultaneously:

an operating system for agentic execution
a control plane for work and decisions
a governed work graph
a compounding knowledge system
a research and synthesis engine
a human collaboration surface
an optimization layer for modules, prompting, and cost

6.1 System Capability Map¶

graph LR
    User["User"] --> UI

    subgraph Interaction
        UI["Control Center"]
        RC["Remote Control"]
        CLI["CLI"]
        UI --- RC
        RC --- CLI
    end

    CLI --> A000

    subgraph Orchestration
        A000["BrainMaster<br/>(orchestrator + governor + stewards)"]
    end

    A000 --> Brains

    subgraph Execution
        Brains["Domain Brains"]
        Workers["Workers"]
        Ruflo["Ruflo Runtime"]
        Brains --- Workers
        Workers --- Ruflo
    end

    A000 --> Tickets
    Ruflo --> Tickets

    subgraph ODM
        Tickets["Tickets"]
        Tasks["Tasks"]
        Sessions["Sessions"]
        Tickets --- Tasks
        Tasks --- Sessions
    end

    Librarian --> A000
    Librarian --> Brains

    subgraph Knowledge
        Librarian["Librarian"]
        Research["Research"]
        Librarian --- Research
    end

    A020 --> A000
    A020 --> Brains

    subgraph Interface
        A020["Face"]
    end

    Hetzner -.-> Ruflo

    subgraph Infra
        Hetzner["Hetzner"]
        Mac["Mac Worker"]
        PG["PostgreSQL"]
        Hetzner --- Mac
        Mac --- PG
    end

6.2 T1P Technology Stack Summary¶

The full technology stack is defined in Part 2. For quick reference, the canonical T1P stack is:

Layer	Technology	Part Reference
Frontend	TypeScript, React 19, Next.js App Router, shadcn/ui, TanStack Query, React-Grid-Layout	Part 2, Section 5.2
Backend	Python 3.12+, FastAPI, Pydantic v2, SQLAlchemy 2, Alembic	Part 2, Section 5.3
Primary Data Store	PostgreSQL 17.x (+ pgvector for embeddings)	Part 2, Section 5.5
Reverse Proxy	Caddy	Part 2, Section 5.9
Realtime Transport	SSE (default), WebSocket (bidirectional only)	Part 2, Section 5.6
Observability	OpenTelemetry, Prometheus, Grafana	Part 2, Section 5.10
Agent Runtime	Ruflo (claude-flow)	Part 2, Section 5.12
Model Router	LiteLLM (API-backed routes only)	Part 4, Section 4.4
Coordination	XIOPro Control Bus (PostgreSQL-backed)	Part 2, Section 5.8
Testing	pytest (backend), Playwright (E2E)	Part 2, Section 5.11
Python Tooling	uv	Part 2, Section 5.4
Secrets	SOPS + age	Part 2, Section 5.14
Backup	Restic to Backblaze B2	Part 2, Section 5.15

7. Canonical Execution Hierarchy¶

flowchart TD
    Idea --> DiscussionThread
    DiscussionThread --> Ticket
    DiscussionThread --> Task
    Ticket --> Task
    Task --> AgentRuntime
    AgentRuntime --> Session
    Session --> Activity
    Activity --> Result
    Result --> Reflection
    Reflection --> Improvement
    Improvement --> Knowledge

    Task --> EscalationRequest
    EscalationRequest --> HumanDecision
    HumanDecision --> Task

    Task --> ResearchTask
    ResearchTask --> ResearchOutput
    ResearchOutput --> Knowledge

This is the shift from chat activity to governed execution.

8. Core System Roles (Role Bundles)¶

XIOPro relies on explicit system roles rather than one monolithic AI brain.

In the XIOPro agent model, roles are assigned properties of agents, not separate agents. Any agent may hold one or more roles. The named professions from earlier blueprint versions (O00, O01, R01, P01, M01) are now defined as role bundles -- collections of capabilities that can be assigned to any agent.

8.1 Unified Agent Identity Model¶

XIOPro uses two identity schemes:

Role@Context naming (canonical for orchestrators): GO, HO@MacStudio, PO-MVP1, IO@Shai
3-digit numeric IDs (retained for ephemeral workers): 100, 101, 102, ...

The 3-digit numeric scheme from v4.x is deprecated for orchestrators. Orchestrators are identified by their role and context, not by a number. Numeric IDs are retained only for ephemeral workers (100+) where short-lived identity is sufficient.

Identity Mapping Table¶

Identity	Type	Description
GO	Role (singleton)	Global Orchestrator. Replaces former 000/BrainMaster.
HO@{host}	Role@Host	Host Orchestrator, one per host. E.g., HO@Hetzner, HO@MacStudio.
PO-{project}	Role-Project	Project Orchestrator, one per active project. E.g., PO-MVP1, PO-XIOPro.
IO@{human}	Role@User	Interaction Orchestrator, one per human. E.g., IO@Shai.
100+	Numeric ID	Ephemeral workers. Short-lived, task-scoped. Sequential assignment.

Agent Identity Schema¶

agent:
  id: "GO"                          # Role@Context for orchestrators, 3-digit for workers
  name: "Global Orchestrator"        # human-readable
  roles: [orchestrator, governor]    # one or more from role_bundles
  is_master: true                    # only one master orchestrator
  host_id: "hetzner-cpx62"          # which machine
  orchestrator_id: null              # null = I AM the orchestrator
  parent_id: null                    # null = top-level agent
  model: "opus"                      # default LLM model
  auth_method: "oauth"               # oauth | api_key | litellm
  auth_account: "shai@struxio.ai"    # which Max/API account
  litellm_model_id: string|null      # LiteLLM routing target
  status: active
  capabilities: [string]             # derived from role_bundles

Agent Registry¶

ID	Name	Roles	Host
GO	Global Orchestrator	orchestrator, governor, rule_steward, prompt_steward, module_steward	hetzner-cpx62
HO@Hetzner	Host Orchestrator (Hetzner)	host_orchestrator, ops	hetzner-cpx62
HO@MacStudio	Host Orchestrator (Mac)	host_orchestrator, ops	mac-studio-m1
PO-MVP1	Project Orchestrator (MVP1)	project_orchestrator	hetzner-cpx62
IO@Shai	Interaction Orchestrator (Shai)	interaction_orchestrator, interface	hetzner-cpx62
100+	Ephemeral Workers	worker	varies

Hierarchy¶

Every agent knows:

orchestrator_id -- who is my boss (null = I am the master orchestrator)
parent_id -- who spawned me (null = top-level agent)
is_master -- only one agent has this true (000)

8.2 Role Bundles¶

Role bundles define the capabilities available to agents. An agent may hold multiple roles.

role_bundles:
  orchestrator: [assign_tasks, spawn_agents, read_work_graph, manage_progression]
  governor: [enforce_policy, trigger_breakers, track_costs, detect_anomalies]
  rule_steward: [validate_rules, detect_conflicts, propose_changes]
  prompt_steward: [assess_readiness, generate_questions, assemble_prompts]
  module_steward: [manage_registry, recommend_models, track_usage]
  specialist: [domain_reasoning, review_work, contribute_knowledge]
  worker: [execute_task, report_result]
  interface: [relay_human_input, present_output]

8.3 LLM / Auth Binding¶

Each agent binds to an LLM access method. This supports multiple Max accounts, API key fallback, LiteLLM routing, and self-hosted model routing.

auth_binding:
  auth_method: enum          # oauth | api_key | litellm
  auth_account: string|null  # email for OAuth (e.g., shai@struxio.ai, dev@struxio.ai)
  api_key_ref: string|null   # SOPS key reference for API key auth
  litellm_model_id: string|null  # LiteLLM model routing ID
  provider: string           # anthropic | openai | google | local

8.4 Role Descriptions¶

Orchestrator Role¶

Coordinates execution, task assignment, continuity, and work progression. Formerly: O00 Orchestrator.

Governor Role¶

Protects runtime execution through policy, anomaly handling, alerts, breakers, and recovery guidance. Formerly: O01 Governor.

Rule Steward Role¶

Governs the lifecycle of rules, skills, activations, patterns, and protocols. Formerly: R01 Rule & Skill Steward.

Prompt Steward Role¶

Determines readiness, inquiry strategy, assumptions, and prompt-package assembly. Formerly: P01 ContextPrompting Orchestrator.

Module Steward Role¶

Governs and optimizes module usage across subscriptions, APIs, and self-hosted runtimes. Formerly: M01 Module Portfolio Steward & Optimizer.

Specialist Role¶

Domain-specific reasoning, review, and knowledge contribution.

Worker Role¶

Executes bounded tasks and reports results.

Interface Role¶

Relays human input and presents output.

8.5 Non-Agent System Capabilities¶

The following are system capabilities, not agents or roles:

Librarian¶

Operates the knowledge system: ingestion, classification, indexing, storage routing, retrieval, and lifecycle.

Research Center¶

Coordinates research workflows, scheduled research, synthesis, NotebookLM/Obsidian integrations, and research outputs.

Hindsight¶

Produces reflections and improvement proposals from execution and research history.

Dream Engine¶

Runs idle-time restructuring, optimization, and proposal generation without bypassing governed approval.

Idle Maintenance¶

Idle Maintenance is the T1P operational subset of Dream Engine capabilities.

It provides the real, day-one idle-time work that runs when the system has no active ticket execution.

Posture: Active but Narrow

Capabilities¶

Memory consolidation (AutoDream) — compress and deduplicate session memory, consolidate lessons learned
Stale knowledge detection — flag knowledge objects, rules, or skills that have not been referenced within a configurable window
Morning brief generation — produce a structured daily summary of system state, pending work, alerts, and cost posture
Session cleanup — archive completed sessions, prune orphaned checkpoints, reclaim resources

Boundary¶

Idle Maintenance must not:

mutate protected rules, skills, or policies
create new tickets or tasks without human approval
execute research tasks or knowledge restructuring beyond flagging

Full Dream Engine capabilities (restructuring, optimization proposals, consolidation beyond flagging) remain in the blueprint but are deferred to post-T1P maturity.

8A. The XIOPro Optimizer¶

The XIOPro Optimizer is the collective name for all components that improve the system's efficiency, quality, and cost-effectiveness over time.

It is not a single service. It is a labeled group of capabilities that work together to make XIOPro better without manual intervention.

Components of the Optimizer¶

Component	Part	What It Optimizes	Posture
Dream Engine	Part 4, Section 4.9	Knowledge, rules, skills, patterns. Runs during idle time.	Proposal-Oriented
Idle Maintenance	Part 4, Section 4.9.9	Memory consolidation, stale detection, morning briefs, session cleanup, activation optimization, skill dedup, token waste.	Active but Narrow
Governor Role	Part 4, Section 4.1	Cost control, anomaly detection, circuit breakers, alerts, runtime protection.	Active
Rule Steward Role	Part 4, Section 4.2A	Rule/skill quality, conflict detection, consolidation, deprecation.	Active but Narrow
Prompt Steward Role	Part 4, Section 4.2B	Prompting quality, readiness assessment, inquiry discipline.	Active but Narrow
Module Steward Role	Part 4, Section 4.2D	Module portfolio optimization, cost/quality/latency balancing, self-hosting evaluation.	Active but Narrow
Skill Performance DB	Part 5, Section 8.9A	Token usage tracking, quality scoring, alternative comparison.	Active but Narrow
Research Center	Part 5, Section 8	Technology scouting, resource evaluation, continuous intelligence.	Active but Narrow
Hindsight	Part 5, Section 9	Reflection, improvement proposals from execution history.	Proposal-Oriented

What the Optimizer Produces¶

Cost reduction recommendations
Token usage optimization
Skill improvement proposals
Rule consolidation proposals
Module switching recommendations
Stale knowledge alerts
Performance trend reports
Technology adoption recommendations

Operating Principle¶

The Optimizer observes, measures, proposes, and (with approval) applies improvements. It does not self-modify protected system behavior without governance approval.

In T1P, most Optimizer components are "Active but Narrow" or "Proposal-Oriented" -- they detect and recommend, but the orchestrator and user make the final decisions.

Why This Label Matters¶

Without the Optimizer label, these capabilities appear disconnected -- the Dream Engine in one section, the Governor in another, Skill Performance DB elsewhere. Labeling them as "the Optimizer" makes it clear they are parts of one system-improvement machine.

9. Human Interaction Principle¶

Users interact with XIOPro through:

open conversation with brains
execution-bound discussion
approvals and rejections
recovery decisions
research and knowledge review
module and cost oversight
governed collaboration during design and strategy work

Human interaction is important, but the UI is not the source of truth.

Any interaction that changes execution, constraints, approvals, recovery, or module choice must become durable backend state.

User identity is modeled as a first-class ODM entity (see Part 3, Section 4.0). The system supports multiple users with distinct roles (founder, operator, reviewer, observer). The primary decision maker is identified by the is_primary flag on the User entity.

10. UI Principle¶

XIOPro's UI is:

web-based
widget-first
mobile-capable
runtime-flexible through governed layout presets

It is a control center, not a chatbot shell.

It exists to make execution, research, governance, and optimization visible and actionable without becoming a hidden dependency.

11. Blueprint Structure Map¶

Part 1 — Foundations¶

Why XIOPro exists, the non-negotiable constraints, mission, professions, and system principles.

Part 2 — Architecture¶

Layered architecture, runtime topology, boundaries, and system composition.

Part 3 — ODM¶

The executable domain model: discussion threads, tickets, tasks, research tasks, runtimes, sessions, activities, escalations, decisions, overrides, state, cost, and timing.

Part 4 — Execution & Agent System¶

Execution stack, orchestration, RC/session model, ContextPrompting, module portfolio, and runtime continuity.

Part 5 — Knowledge System¶

Librarian, knowledge ledger, governed assets, Research Center, Hindsight, Dream integration, and retrieval.

Part 6 — UI / Control Center¶

Widget-based web UI, layout presets, operator workflows, prompt composer, research/gov/module workspaces, and mobile mode.

Part 7 — Governance¶

Policies, breakers, alerts, approvals, module governance, ContextPrompting governance, and enforcement.

Part 8 — Infrastructure¶

Nodes, services, storage surfaces, repo/filesystem layout, cost telemetry pipeline, bootstrap/update lifecycle, and deployment constraints.

Part 9 — System Review¶

Formal verification layer between design (Parts 1-8) and execution (Parts 10-12). Data schema, module index, subject index, risk register, dependency order, data flow diagrams, and process checklists.

Part 10 — Work Plan, Migration & Test Plan¶

Implementation sequencing, delivery phases, migration logic, testing strategy, and validation criteria. This part may evolve after the design stabilizes.

Part 11 — Execution Log¶

Living record of what has been done, decided, and changed during the XIOPro build.

12. Foundational Success Criteria¶

XIOPro is successful if it becomes:

buildable
recoverable
explainable
replaceable
governable
optimizable
knowledge-compounding
trustworthy under stress

12A. T1P Posture Rules¶

T1P does not mean "everything is equally mature on day one".

It means the blueprint preserves the full architecture, while making explicit which parts must be:

operational now
limited in scope now
proposal-oriented now
deferred in maturity, but not removed

12A.1 T1P Posture Classes¶

Use these posture classes for major subsystems:

Active
Active but Narrow
Proposal-Oriented
Deferred in Maturity

Meaning¶

Active Required as real operating capability in T1P.

Active but Narrow Required in T1P, but with reduced scope and strict initial boundaries.

Proposal-Oriented Present in T1P, but limited to evidence, reflection, recommendation, or preparation. May not directly mutate protected system behavior.

Deferred in Maturity Architecturally present, but not required to be feature-complete in T1P.

12A.2 T1P Posture by Major Capability¶

Work Graph / ODM¶

Posture: Active

Must be real in T1P.

Orchestrator Role¶

Posture: Active

Must drive real ticket/task execution in T1P.

Governor Role¶

Posture: Active but Narrow

Must support: - alerts - approvals - basic breakers - runtime constraints

It does not need full long-horizon optimization sophistication on day one.

Rule Steward Role¶

Posture: Active but Narrow

Must support: - search-before-create - validation - conflict detection - approval routing

It does not need a large autonomous stewardship pipeline on day one.

Prompt Steward Role¶

Posture: Active but Narrow

Must support: - prompting mode selection - blocking vs optional inquiry - durable answer promotion - bounded prompt-package assembly

It does not need a very rich adaptive prompt science layer on day one.

Module Steward Role¶

Posture: Active but Narrow

Must support: - module registry - recommendation - fallback awareness - evidence-backed comparison - cost/usage visibility

It does not need a broad autonomous portfolio strategy engine on day one.

Research Center¶

Posture: Active but Narrow

Must support: - research task definition - scheduled research - source bundles - research output lineage - promotion into Librarian-managed knowledge

It does not need a giant multi-surface research universe on day one.

Hindsight¶

Posture: Proposal-Oriented

Must generate: - reflections - improvement proposals - evidence for change

It must not silently publish protected changes in T1P.

Dream Engine¶

Posture: Proposal-Oriented

Must remain: - idle-time - bounded - non-authoritative - non-mutating for protected behavior

Dream may prepare, compress, detect, and propose. It must not directly rewrite live protected behavior in T1P.

Idle Maintenance¶

Posture: Active but Narrow

Must support: - memory consolidation (AutoDream) - stale knowledge detection - morning brief generation - session cleanup

This is the T1P operational subset that runs in production from day one, distinct from the full Dream Engine ambition.

UI / Control Center¶

Posture: Active but Narrow

Must support: - Control Center - Brain Collaboration - approvals / alerts - Prompt Composer - Research Desk basics - module visibility - mobile reduced-surface mode

It does not need every widget/preset to be equally mature on day one.

12A.3 Rule¶

T1P preserves the whole XIOPro architecture.

It does not require every subsystem to begin at full conceptual maturity.

This allows the blueprint to remain ambitious, without pretending that all ambition is implemented at once.

13. Current State¶

As of 2026-03-28, the following foundational elements exist:

The BrainMaster operates as the master orchestrator on Hetzner CPX62, holding all steward roles (current assignment: agent 000)
Domain brains exist and operate with distinct specializations (current assignments: agents 001-005)
The Mac Worker serves as local operator node via Tailscale (current assignment: agent 010)
Face serves as the user-facing interface (current assignment: agent 020)
Ruflo (claude-flow) provides the agent execution runtime
Bus-based messaging connects agents across surfaces
Paperclip serves as the current ticket tracker (to be superseded by ODM-backed work graph)
CLI-first execution is the primary operational mode
Agent identity uses the unified 3-digit numbering model (see Section 8.1)

14. Final Statement¶

XIOPro is the internal machine that turns thought into governed action.

If built correctly:

execution becomes structured
knowledge compounds
recovery becomes practical
optimization becomes deliberate
trust becomes scalable

If built poorly:

autonomy becomes chaos
cost becomes invisible
modules drift
prompting degrades
knowledge fragments
the system collapses back into chat-shaped fragility

Changelog¶

v5.0.0 (2026-03-28)¶

Changes from v4.1.0:

C1.1: Added Idle Maintenance section (Section 8) as the T1P operational subset of Dream Engine, with explicit capabilities and boundaries
C1.2 / CX.1: Global naming fix — "Rufio" replaced with "Ruflo" throughout
C1.3: Added constraint 4.10 CLI-First to Non-Negotiable Design Constraints (Section 4)
C1.3: Added Idle Maintenance posture entry to T1P Posture by Major Capability (Section 12A.2)
CX.2: Version header updated to 4.2.0, last_updated to 2026-03-28
CX.3: Added this changelog section
CX.4: Added Current State section (Section 13) documenting what exists today
Renumbered Final Statement from Section 13 to Section 14

v5.0.1 (2026-03-28)¶

Unified Agent Identity Model:

Section 8: Rewritten from "Core System Professions" to "Core System Roles (Role Bundles)". O00/O01/R01/P01/M01 reframed as role bundles assigned to agents, not separate agent identities
Section 8.1: Added Unified Agent Identity Model with 3-digit agent IDs (000-020, 100+), agent identity schema, agent registry table, and hierarchy model
Section 8.2: Added Role Bundles definition with capability lists
Section 8.3: Added LLM/Auth Binding schema supporting multiple Max accounts, API keys, LiteLLM routing, and self-hosted models
Section 8.4: Added Role Descriptions preserving original profession content, now reframed as assignable roles
Section 8.5: Non-agent system capabilities (Librarian, Research Center, Hindsight, Dream Engine, Idle Maintenance) preserved unchanged
Section 6.1: Updated System Capability Map diagram to use 3-digit agent IDs
Section 12A.2: Updated T1P posture entries from O00/O01/R01/P01/M01 to role-based naming
Section 13: Updated Current State to use 3-digit agent IDs
Updated all cross-references from named agents (BM, B1-B5, M0, C0) and profession codes (O00, O01) to 3-digit IDs with role annotations

v5.0.2 (2026-03-28)¶

Agent naming migration verification: Part 1 was already migrated in v5.0.1. No additional changes required. Changelog entry added for completeness.

v5.0.3 (2026-03-28)¶

Idea + User entities:

Section 6.1: Updated System Capability Map diagram — "Founder" node replaced with "User"
Section 9: Updated Human Interaction Principle — "The founder interacts" replaced with "Users interact". Added paragraph explaining User as first-class ODM entity with multi-user support and is_primary flag
Section 13: Updated Current State — "founder-facing interface" replaced with "user-facing interface"

v5.0.4 (2026-03-28)¶

Roles over numbers: Removed agent IDs from architectural role descriptions, section headers, diagrams, and T1P posture entries. Agent numbers retained only in Section 8.1 (identity schema/registry) and Section 13 (Current State, now with "current assignment" format). Blueprint describes WHAT roles do, not WHICH agent holds them.

v5.0.7 (2026-03-28)¶

Added Section 8A: The XIOPro Optimizer -- unified label for all system-improvement components (Dream Engine, Idle Maintenance, Governor, Rule/Prompt/Module Stewards, Skill Performance DB, Research Center, Hindsight). Includes component table, output list, operating principle, and rationale for the label.

v5.0.8 (2026-03-28)¶

Review and Testing Everywhere:

Section 4.13: Added constraint "Review and Testing Everywhere" -- every significant XIOPro output must be reviewed and tested before trusted. Includes output-type matrix (code, architecture, docs, rules, research, decisions, configurations, deployments, knowledge vault entries, ticket definitions), implementation requirements, and core AGI safety principle statement.

v5.0.10 (2026-03-29)¶

Added Key Terms and Definitions:

Section 4A: New "Key Terms and Definitions" section added with entries for T1P (Top 1% Percentile), T1P Posture, Control Bus, ODM, Role Bundle, and GO/HO/PO/IO hierarchy labels.

v5.0.11 (2026-03-30)¶

Sprint Compression insight:

Section 4A: Added "Sprint Compression" entry to Key Terms table — definition of reducing 1-3 week sprints to 1-3 hours via parallel agents, T1P automation, and Bus-mediated coordination.
Section 4B: New "Sprint Compression" section added documenting the 6 enabling mechanisms (parallel agent execution, T1P automation, Bus-mediated coordination, template-driven execution, Review Engine, progressive prototyping) and the platform's core delivery promise (3-6 month projects in 1-2 weeks).

v5.0.9 (2026-03-28)¶

Wave 1-2 BP fixes:

Section 4.12: Added constraint "Control Bus as Coordination Backbone" -- documents the Control Bus as a non-negotiable design constraint with cross-reference to Part 2 Section 5.8. Previous 4.12 CLI-First renumbered to 4.13, 4.13 Review/Testing renumbered to 4.14.
Section 6.2: Added T1P Technology Stack Summary table -- quick-reference table of all canonical technology decisions with Part references (PostgreSQL, FastAPI, Next.js, Caddy, Ruflo, LiteLLM, SOPS, Restic, etc.).

v5.0.12 (2026-03-30)¶

I12 review fix:

Section 4.5A: Added "Immediate Start vs Stage Gates" -- clarifies that "never ask permission to START" and "require approval at gates" are complementary. Agents begin immediately on assignment; they pause at defined stage gates. Cross-references Part 7, Section 3.3A.

v5.0.13 (2026-03-30)¶

Round 2 review fix (identity model tension):

Section 8.1: Deprecated 3-digit identity model for orchestrators (GO, HO, PO, IO). Part 10 Role@Context naming declared canonical. 3-digit IDs retained only for ephemeral workers (100+). Added identity mapping table. Updated agent registry to use Role@Context format.