Policies written in a document are not enough if the runtime can bypass them. In a governed agent system, authority is resolved before mutation-capable work begins, the execution environment is bounded, state changes are observable and the final result can be checked independently.
The OsaTechGPT architecture separates these responsibilities instead of collapsing them into one agent process.
OSA Execution Force is the authority and capability-control layer. Its documented V3 path binds policy, repository, scope, source SHA and the downstream execution payload before RuntimeV2 receives mutation authority.
Documented P0 invariants deny a direct RuntimeV2 mutation path before V3 authorization, reject modified payloads, prevent scope widening and require exact source provenance for the project-scoped path.
Hydra Hermes Lab is the operational runtime laboratory. Its public architecture routes agent work through a NemoClaw/OpenShell sandbox, keeps raw infrastructure credentials host-side and applies permission classes to distinguish ordinary work from sensitive operations.
The continuous worker design includes a daily prompt cap, interval controls, a circuit breaker and a STOP file. Sending, publishing, production deployment and money movement are treated as RED operations rather than ordinary autonomous actions.
NeurOSA Human Brain provides a separate persistent cognitive-state layer. The verified build compiles .nsa through lexer, parser, AST, semantic analysis and typed IR into runtime activation backed by SQLite.
Its append-only SHA-256 hash-chain ledger can detect payload mutation, deletion, reordering and broken hashes. This does not turn memory into execution authority; it keeps state and provenance as a distinct system responsibility.
OSA Cloud Workspace models deployment evidence as a chain from source SHA to build, image, ready revision and live endpoint. GitHub is the code source of truth; the cloud runtime is a separate source of operational truth.
A historical badge or repository claim is not treated as proof that a runtime is healthy now. Runtime freshness must be checked separately.
Agent Proof Runtime (APR) sits across execution paths as an evidence and verification layer. Missions produce observations and proof artifacts that can be evaluated independently instead of allowing the same agent to declare its own success.
APR uses explicit result states such as LOCAL_VERIFIED, FAILED and UNANCHORED rather than converting incomplete evidence into a green status.
| Question | Control |
|---|---|
| Who may authorize the action? | Policy and authority gate. |
| What exactly may change? | Repository, file, scope and payload binding. |
| Which tools or capabilities are available? | Capability allow/deny rules and permission classes. |
| Where does execution happen? | Sandbox or bounded runtime. |
| How long and how often may it run? | Budgets, intervals, circuit breakers and cancellation. |
| What changed? | Events, observations, hashes, receipts and deployment evidence. |
| Who decides whether it succeeded? | Independent verification, not the executor alone. |
Governance is not a single dashboard toggle. It is a chain of enforceable boundaries around execution, state, infrastructure and evidence.
The systems above do not share the same evidence level. Some have public repositories and mechanical tests; some expose live runtime evidence; some remain R&D. OsaTechGPT does not upgrade a component to “production ready” because it has a landing page.
The governing rule is deliberately simple: claim strength follows evidence strength.
Discuss a scoped pilot covering execution authority, runtime boundaries and auditable evidence.