The PMIVerse Multi-Agent Harness is a governed execution and orchestration system for AI-assisted software engineering.
It is designed for environments where coding agents need to inspect repositories, modify source code, execute validations, coordinate dependent work, survive interruption, and leave independently verifiable evidence—without receiving unrestricted authority over the development host.
The project began from a practical engineering problem:
How can increasingly capable coding agents be allowed to perform real software-development work without treating prompts, model output, or broad workstation access as a security model?
PMIVerse addresses this by separating planning, authority, execution, containment, recovery, and evidence into distinct layers.
Its primary proving ground is the PMIVerse / PMISuite Odoo ecosystem, where tasks may involve multiple repositories, strict repository-specific rules, dependent modules, validation procedures, different runtime environments, independent review stages, and long-lived operational state.
The harness has progressed far beyond its original readiness and governance prototype.
The current system implements a complete fixed native production-pilot catalog, including multi-agent orchestration, coding-agent execution, controller and MCP interfaces, external authority verification, recovery, continuity, monitoring, controlled runtime upgrades, and independent final evidence verification.
Its strongest current native qualification is:
native-disposable-qualified
This means the complete native production catalog has executed successfully through current production APIs inside an owner-private disposable environment.
The complete automated test catalog has also now been exercised successfully. Six host-sensitive tests that could not run inside the original assessment sandbox were subsequently executed by the administrator in the appropriate host context and passed.
The project nevertheless continues to distinguish native qualification, formal intended-host qualification, and real-provider qualification because they establish different facts.
The Core Principle
The central architectural rule is deliberately simple:
Describing an operation is not the same as authorizing it.
A prompt does not grant authority.
A task manifest does not grant authority.
A successful readiness check does not grant authority.
Evidence does not grant authority.
Monitoring does not grant authority.
A coding agent cannot expand its permissions through its own output.
Before a mutation can occur, PMIVerse binds the requested operation to exact identities such as:
- repository;
- repository state;
- task;
- run;
- release;
- controller configuration;
- executable;
- runtime closure;
- enforcement generation;
- orchestration node;
- operation;
- approval or grant;
- durable consumer;
- durable store.
Only explicitly issued external authority permits defined mutations.
The harness verifies and consumes that authority.
It does not issue it.
This creates a deliberate separation between:
What work is being requested?
and:
Who has authorized that exact work?
Architecture
The current architecture separates strategic reasoning from local execution control:
Human Engineer / Operator
│
▼
ChatGPT / Orchestrator
│
▼
MCP / Client Layer
│
▼
PMIVerse Local Controller
authentication / idempotency
│
▼
PMIVerse Harness
governance / orchestration
authority / recovery / evidence
│
▼
Controlled Launcher
│
▼
Coding-Agent Sidecar
│
▼
Isolated Repository Runtime
External authority remains outside that execution path:
External Authority Issuer
│
│ signed exact grant
▼
Trust / Revocation / Delivery
│
▼
Typed Consumer
The component that performs work therefore does not also manufacture the permission required to perform it.
The harness is not a prompt-management framework and not an unrestricted AI shell.
It is a governed execution system.
Exact Identity Instead of Ambient Trust
PMIVerse relies heavily on explicit identity binding.
Execution can be tied to exact:
- repository identities;
- repository digests;
- Git state;
- task definitions;
- release inventory;
- service configuration;
- runtime closure;
- executable identities;
- enforcement generation;
- authority grants;
- orchestration graph;
- durable stores;
- processes and descendants.
The current release identity is content-based rather than relying on a Git commit SHA as the sole release identifier.
The governed filesystem contents and operational assets define what software is actually being qualified.
This is important in environments where working state, generated assets, deployment configuration, or runtime closure may matter as much as repository history.
Governance Before Execution
Before work can be dispatched, PMIVerse evaluates readiness and validates the structural facts that define the task.
These can include:
- applicable governance;
- repository ownership;
- selected repository;
- branch or detached revision;
- task identity;
- editable scope;
- excluded scope;
- validation declarations;
- runtime state;
- trusted assets;
- service configuration;
- active enforcement generation.
Observed facts are distinguished from:
- caller-provided information;
- derived information;
- information that cannot be established reliably.
Required uncertainty is not replaced with an assumption.
When a security-relevant fact cannot be established, execution fails closed.
Immutable Execution Contracts
A repository being ready does not itself grant permission to execute.
Validated task state is converted into exact execution and orchestration contracts.
Those contracts bind the operation to the intended repository, task, runtime, scope, authority references, dependencies, and generation.
A valid contract cannot be reused to silently substitute:
- another repository;
- another command;
- another task;
- another writable scope;
- another runtime;
- another approval.
Canonical serialization and domain-separated digests are used throughout the system to make those identities deterministic.
Mechanical Worker Containment
Prompt instructions are not considered a containment mechanism.
Repository execution is mechanically constrained.
The launcher uses mechanisms including:
- pinned executable identities;
- descriptor-pinned runtime assets;
- detached workspaces;
- controlled writable scope;
- protected excluded paths;
- masked Git metadata;
- bounded environment;
- bounded descriptors;
- bounded time and output;
- process-group supervision;
- Bubblewrap isolation when the host satisfies the required capability contract;
- authenticated process identity;
- descendant-death verification.
The worker is not simply told to avoid unrelated files.
The surrounding execution environment is constructed so that unrelated authority is not ambiently available.
Governed Coding-Agent Boundary
The current implementation includes a production coding-agent adapter and a bounded machine protocol.
The coding agent can request only a fixed set of repository actions such as:
- list a directory;
- read text;
- search text;
- replace text;
- create a file;
- optionally delete an explicitly permitted file;
- inspect a diff summary;
- run a declared validation;
- submit a final result.
The worker cannot introduce:
- arbitrary shell commands;
- arbitrary validation commands;
- unrestricted filesystem paths;
- new approvals;
- new authority;
- arbitrary executable identities;
- unrestricted environment values;
- expanded write scope.
All repository effects continue to pass through the governed action engine.
The coding-agent protocol is also separate from execution truth.
A model saying that a task succeeded cannot override:
- a failed process;
- failed containment;
- a timeout;
- protocol failure;
- surviving descendants;
- missing execution evidence.
Multi-Agent Orchestration
The current native production workflow uses an explicit implementation-and-review graph:
Implementation Worker
│
│ exact successful result
▼
Integration Review Worker
│
▼
Final Orchestration Result
The implementation worker receives bounded write scope.
The review worker is read-only.
The review stage depends on the exact implementation result.
The orchestration system persists:
- graph identity;
- dependencies;
- readiness;
- dispatch intent;
- running state;
- invocation identity;
- worker result;
- review result;
- terminal state.
A failed dependency cannot silently become successful downstream work.
A node that may already have been externally dispatched is not relaunched simply because a controller process restarted.
Repository Ownership and Leases
Repository ownership is explicit.
A core rule remains:
One implementation worker owns one canonical repository.
Repository leases prevent multiple implementation workers from silently obtaining simultaneous authority over the same canonical repository.
Lease acquisition and lease release are separate lifecycle operations.
Cleanup does not imply lease release.
Execution does not imply cleanup.
The project deliberately avoids collapsing these different effects into one broad permission.
Authenticated Local Controller
The production mutation boundary is the local controller service.
It uses a filesystem Unix-domain SOCK_SEQPACKET socket and validates local peers using operating-system credentials.
The controller includes:
- socket parent and object identity validation;
- expected service UID validation;
- SO_PEERCRED peer authentication;
- bounded request size;
- canonical JSON;
- strict schemas;
- ancillary-descriptor rejection;
- bounded concurrency;
- bounded admission;
- deterministic shutdown;
- durable idempotency.
It exposes only defined operations for:
- readiness;
- orchestration submission;
- orchestration execution;
- orchestration status;
- cancellation;
- recovery assessment;
- recovery planning;
- recovery application;
- checkpoint verification;
- retention planning;
- retention application.
It does not expose:
- a generic shell;
- generic arbitrary command execution;
- arbitrary environment injection;
- authority issuance;
- deployment operations.
Durable Idempotency
Mutating controller requests use caller-held idempotency keys.
The key is bound to the complete authenticated request.
If a request has already completed, its exact result can be replayed without repeating the underlying effect.
This remains true after controller reconstruction.
A reused key with changed arguments is rejected.
This distinction is especially important when the client loses its connection.
If the operation completed durably but the response was lost, PMIVerse can return the stored result.
It does not execute the operation again.
Ambiguity Is Preserved
One of the central system invariants is:
Unknown external effects are not permission to retry.
If a mutation is durably known to have started but the system cannot prove its final external effect, it remains ambiguous or recovery-required.
This behavior applies across areas such as:
- process dispatch;
- signal delivery;
- cancellation;
- recovery;
- restore;
- generation activation.
The harness does not turn missing information into optimistic assumptions.
Durable Recovery
Recovery begins with observation rather than mutation.
The model is:
observe durable state
↓
classify known and unknown effects
↓
construct exact recovery plan
↓
request external authority
↓
verify and consume one-use authority
↓
apply known-safe transition
↓
publish exact receipt
The recovery plan itself is non-authoritative.
If an external effect remains unknown, the system does not automatically invent a corrective operation.
Cancellation and Forced Termination
Cancellation authority is separate from normal execution authority.
Graceful cancellation and forced termination are also distinct.
A graceful cancellation request may authorize a controlled signal.
If the target does not terminate, that does not automatically authorize forced termination.
Escalation requires separate authority.
PMIVerse also does not consider a process safely terminated simply because the primary PID disappeared.
Terminal death requires evidence about the authenticated process and relevant descendants.
External Authority and Revocation
The production system now includes offline Ed25519 authority verification and typed delivery.
It supports:
- trust records;
- verification keys;
- validity windows;
- operation constraints;
- revocation records;
- signed envelopes;
- immutable acceptance;
- typed materialization;
- one-use consumption;
- replay protection.
Authority can be delivered only to defined target classes such as:
- launcher;
- recovery;
- retention;
- generation;
- restore;
- live-host qualification.
Production does not:
- create signing keys;
- hold an issuer role;
- sign production grants;
- create its own approval.
The authority issuer is deliberately external.
Late-Bound Authority
Some operations cannot safely be approved before their exact effect is known.
These include:
- recovery application;
- retention application;
- enforcement-generation staging;
- restore;
- successor activation;
- predecessor retirement.
PMIVerse therefore persists the exact plan first.
Only then can the external authority issuer approve that exact plan.
This allows approval to remain narrow even for operations whose exact target does not exist at the start of the workflow.
Enforcement Generations
Trusted execution infrastructure is grouped into enforcement generations.
A generation binds facts such as:
- executable identities;
- runtime closure;
- capability profile;
- predecessor;
- generation number;
- state.
Generation states include:
- staged;
- active;
- retired.
The active generation is explicit.
A running or authorized operation does not silently change enforcement meaning because newer assets appeared on disk.
Safe Drain and Upgrade
The current production pilot includes a complete controlled generation-transition lifecycle.
The high-level flow is:
prepare successor
↓
authorize staging
↓
stage successor
↓
close mutation admission
↓
prove quiescence
↓
stop controller
↓
backup current durable state
↓
restore into controlled roots
↓
authorize successor activation
↓
activate exact successor
↓
start and verify successor
↓
prove predecessor was not automatically retired
↓
optional separately authorized retirement
Activation and retirement are separate permissions.
A successful successor start does not imply permission to delete or retire its predecessor.
Quiescence
Quiescence is not inferred from an empty queue or a stopped socket.
The harness evaluates real durable state such as:
- queued controller work;
- active requests;
- nonterminal orchestration;
- running launcher processes;
- active leases;
- pending cleanup;
- pending release;
- recovery-required state.
Preserved historical ambiguity may remain visible without implying that a process is currently active.
This allows the controller to stop safely without pretending that every historical uncertainty has disappeared.
Backup, Restore, and Continuity
Continuity is implemented as a governed stopped-state workflow.
The current system can:
- verify the source configuration;
- require quiescence;
- inspect relevant durable stores;
- create a backup manifest;
- independently verify the complete backup;
- construct an exact restore plan;
- require absent restore targets;
- consume separate restore authority;
- restore the durable stores;
- reconstruct the controller;
- verify completed replay;
- preserve started ambiguity.
A completed request remains completed after restore.
A started uncertain mutation remains uncertain after restore.
Restore does not rewrite history into a more convenient state.
Checkpoints and Retention
Checkpoint state provides independent local integrity evidence for important lifecycle and generation identities.
Retention is separately planned and authorized.
A retention plan identifies exact eligible objects.
The system revalidates those objects immediately before deletion.
Security-relevant state is excluded from ordinary disposable retention.
Retention evidence cannot grant future retention authority.
Monitoring and Incident Evidence
The harness includes a bounded monitoring subsystem.
It can observe information such as:
- controller lifecycle;
- orchestration state;
- launcher state;
- checkpoint state;
- retention;
- generation state;
- drain state;
- continuity;
- authority delivery;
- coding-agent capability;
- MCP qualification.
Monitoring is read-only with respect to those systems.
It may publish:
- monitoring snapshots;
- OpenMetrics output;
- append-only incident transitions.
Incident transitions remain independently verifiable.
Monitoring cannot:
- acknowledge authority;
- resolve recovery;
- issue approval;
- mutate execution state;
- silently remediate failures.
MCP Integration
PMIVerse includes a thin local MCP server for integration with orchestrators such as ChatGPT.
MCP maps a fixed tool catalog to exact controller operations.
It is deliberately not:
- a shell;
- a plugin system;
- an arbitrary operation dispatcher;
- an authority issuer;
- a repository execution environment.
Mutating MCP operations continue to require caller-held idempotency keys and existing controller authority.
Transport ambiguity is not automatically retried.
The 32-Step Native Production Pilot
The current system includes a fixed 32-step production-pilot catalog covering the complete local governed execution lifecycle.
The catalog includes:
- release and configuration verification;
- operational diagnostics;
- monitoring baseline;
- external authority readiness;
- controller startup and readiness;
- bounded implementation followed by review;
- completed replay;
- controller restart replay;
- reboot-boundary continuation;
- response-loss replay;
- graceful cancellation;
- separately authorized forced termination;
- recovery-required execution;
- late-authorized recovery;
- workspace cleanup;
- repository lease release;
- checkpoint verification;
- late-authorized retention;
- successor staging and drain;
- quiescence proof;
- controller stop;
- backup creation and verification;
- authorized restore;
- restored replay verification;
- successor generation activation;
- successor host readiness;
- proof that predecessor retirement was not automatic;
- optional separately authorized predecessor retirement;
- MCP qualification;
- coding-agent qualification and provider classification;
- monitoring and incident verification;
- final acceptance evidence.
All mandatory steps are implemented.
The only optional step is predecessor retirement.
The strongest native path enables that optional step as well.
Native Disposable Qualification
The strongest current native classification is:
native-disposable-qualified
The native environment uses current production implementations for:
- controller service;
- controller client;
- durable stores;
- orchestration;
- launcher;
- coding-agent protocol;
- recovery;
- retention;
- generation transition;
- continuity;
- MCP;
- monitoring;
- final verification.
Qualification-specific fixtures provide deterministic repositories, an external test issuer, and a deterministic bounded provider.
These fixtures demonstrate the production consumers.
They are not production authority infrastructure or a real external AI provider.
Effect-Free Terminal Replay
One of the strongest demonstrated properties is effect-free terminal replay.
After the complete native production pilot reaches terminal acceptance, the test:
- records the complete disposable filesystem state;
- reconstructs a new native assembly and controller;
- replaces native adapter methods with failure hooks;
- replays the already terminal request;
- verifies that no adapter method runs;
- verifies the same final result;
- verifies identical final evidence bytes;
- compares the complete filesystem snapshot;
- verifies that no observed file or metadata changed;
- independently verifies final evidence again.
This proves more than identical output.
It demonstrates that terminal replay repeats no harness effect within the observed disposable environment.
Independent Final Verification
Successful execution is not sufficient by itself.
The production pilot publishes a final V3 evidence set.
An independent verifier re-evaluates:
- catalog completeness;
- transition ordering;
- release identity;
- service configuration;
- native receipts;
- authority acceptance and consumption;
- generation state;
- continuity;
- MCP;
- coding-agent result;
- monitoring;
- retained ambiguity.
Missing, added, reordered, stale, substituted, malformed, or conflicting evidence fails verification.
The component being verified cannot simply declare itself qualified.
Automated Validation
The project now has a fully exercised automated test catalog.
The assessment environment initially reported:
- 817 unittest cases executed with six host-capability skips;
- 811 pytest cases passed with the same six skips.
Those six cases could not run inside the assessment sandbox because that environment could not expose the required trusted host ancestry and Bubblewrap/runtime characteristics.
They were subsequently run by the administrator outside the sandbox in the appropriate host context.
All six passed.
The complete known automated test catalog has therefore been executed successfully across the relevant execution environments.
Additional validation includes:
- strongest native path passing;
- production package and scripts passing Ruff lint;
- canonical policy validation passing;
- Python syntax compilation passing;
- systemd service definitions passing static verification.
Repository-wide style and formatting debt remains advisory maintenance work rather than a demonstrated runtime defect.
Three Different Qualification Claims
PMIVerse deliberately maintains different qualification classes because they answer different questions.
Native Disposable Qualification
Current classification: native-disposable-qualified
This proves that the fixed production catalog executes successfully through current production components in the controlled disposable environment.
Host-Sensitive Automated Validation
Current state: passed
All known host-sensitive automated cases that could not execute inside the original sandbox have now been executed by the administrator in the required host context and passed.
This closes the automated-test coverage gap around those host-specific execution boundaries.
Intended Live-Host Qualification
The system also includes a separate, externally authorized live-host qualification workflow.
This is a stronger deployment-specific claim involving the intended host and its exact operational boundaries.
Host-sensitive automated tests passing should not automatically be represented as a completed formal live-host qualification unless that distinct workflow, with its required service-host and continuity evidence, has also been executed and verified.
Real-Provider Qualification
Current classification: real-provider-unqualified
The production coding-agent protocol and adapter exist.
The native path uses a deterministic qualification provider.
No real external AI provider has yet established the equivalent qualification claim.
Current Development Status
For the existing fixed native catalog, the implementation is complete.
There is currently no established functional code gap preventing repetition of the native disposable qualification.
The complete automated catalog has now also been executed successfully.
The primary remaining work has therefore shifted away from core harness construction.
The next areas are principally:
- intended production-host deployment and qualification;
- service-account and filesystem provisioning;
- physical reboot and operational continuity validation;
- cgroup and resource policy;
- production signing-key custody;
- revocation and approval governance;
- real backup custody;
- operational restore drills;
- monitoring and incident ownership;
- real-provider selection;
- provider credentials and network policy;
- real-provider qualification;
- performance and scale characterization.
New core code should now be driven by demonstrated findings from those activities or by an explicit strategic expansion.
Current Limitations
The project deliberately does not claim several things that have not yet been established.
Native qualification does not by itself prove:
- production deployment;
- production key governance;
- a real physical disaster-recovery procedure;
- externally custodied backup media;
- long-duration production stability;
- high-scale throughput;
- multi-host operation;
- remote-controller security;
- a real AI provider;
- root-level tamper resistance for purely local evidence.
The current architecture is intentionally single-host and local.
Those boundaries should be expanded only when there is a concrete product requirement.
What PMIVerse Is Not
PMIVerse is deliberately not:
- an unrestricted AI shell;
- an approval issuer;
- a signing service;
- an automatic deployment system;
- a generic arbitrary workflow engine;
- a broad remote-command system;
- an automatic privilege escalation mechanism;
- an automatic retry engine for unknown effects;
- an automatic runtime-retirement system;
- a distributed multi-host scheduler;
- proof that an external model is safe.
The AI model itself is not treated as the security boundary.
The surrounding governed execution system is.
Long-Term Direction
The intended engineering experience is increasingly clear.
A developer should be able to request:
Investigate this problem.
Determine which repositories are involved.
Implement the authorized changes.
Run the required validations.
Have an independent worker review the result.
Recover safely if execution is interrupted.
Preserve the evidence.
Underneath that request:
Humans define intent and authority.
ChatGPT or another orchestrator reasons about the work.
Coding agents investigate and implement.
PMIVerse governs execution.
Linux enforces containment.
External authority controls privileged transitions.
Durable state preserves uncertainty instead of guessing.
Independent verification determines what actually happened.
The PMIVerse Multi-Agent Harness is therefore becoming infrastructure for a new class of software-development environment:
AI-assisted engineering with controlled autonomy, explicit authority, recoverable execution, and independently verifiable outcomes.