Visibility.
A real-time view of what autonomous systems are doing at the moment they act. Every consequential step captured in a standardised envelope recording initiator, agent, delegated authority, target system, and outcome.
ARBITR
Where autonomous execution becomes accountable.
The execution-assurance control plane for the moment autonomous systems act. Built for organisations whose AI and agentic automations now execute real changes across payments, records, workflows, and cross-system processes - and need to see, in evidentiary form, exactly what happened. Runtime-agnostic. Vendor-neutral. ARBITR makes delegated execution visible, structured, deterministic, tenant-isolated, portable, and evidentiary. Not identity. Not policy. The layer that records, and proves, what actually ran, under whose authority, at the moment it committed.
For teams deploying autonomous systems where execution authority matters.
ARBITR and system logs are not the same thing.
System logs are produced by the systems doing the work, for the people who run those systems. They tell engineers what happened inside an application, a database, or a piece of infrastructure - exceptions, latencies, errors, throughput. They are written in the language of the system. They are read by the people who keep that system running. Their job is operational diagnosis, not delegation evidence.
ARBITR is produced by the autonomous systems doing things on someone's behalf, for the people who are accountable when those things go wrong. It does not record that a process ran. It records which agent acted, under what delegated authority, on whose behalf, against which target system, with what result, and at the moment it committed. The unit of capture is the act of delegated execution, not the operation of the underlying machine.
The audiences are different. The questions are different. The evidence is structured differently
because the questions are structured differently.
A system log answers: did the application work?
ARBITR answers: was this autonomous action authorised, by whom, in what context, and is there
a deterministic record I can present to a board, an auditor, or a regulator?
Both are useful. They are not substitutes.
The runtime governance gap.
The boundary between advisory AI and executing AI is where the assumptions holding current governance in place quietly break. Once a system moves from suggesting an action to performing one, making the payment, modifying the record, triggering the workflow, deploying the change, the decision cadence most governance frameworks rely on no longer exists.
"Human in the loop" sounds reassuring because it assumes a human can plausibly review what happened before consequences land. At machine speed, that assumption stops being true. Actions commit faster than any review cycle can reach them. The governance is on paper. The execution has already occurred.
A log is not enough. Traceability shows that something happened. It does not, on its own, show that the action was authorised, by whom, within what scope, under what delegation, and with what consequence. That is the gap ARBITR exists to close.
Built from the same governance-first perspective used in regulated financial services and other high-trust operating environments, where execution, accountability, and consequence cannot be separated.
The primitive: the ARBITR Envelope.
At the core of ARBITR is a single primitive: the Envelope, Structured Execution schema v1. In plain terms, it is a structured, append-only execution record emitted per step. It gives each consequential action a stable, defensible record shape across runtimes, tenants, and environments.
Versioned, tenant-scoped, trace-correlated, capability-bound, secret-safe, signature-ready, and authority-context aware.
Each envelope captures:
- The initiating actor reference - the human or upstream system that triggered the step
- The agent reference - the AI or automated component that performed the step
- The delegation context - the authority chain under which the step was permitted
- The authority scope - the specific bounds on what the step was allowed to do
- The target system and action performed
- The result status
- Optional checkpoint references and artifact pointers
It is designed to preserve a stable record shape so evidence can be interpreted consistently, exported cleanly, and later sealed cryptographically without changing the underlying execution history.
The envelope is not a policy decision. It is not a compliance certificate. It is a deterministic execution record.
What ARBITR gives the customer.
Three goods, structural and portable.
Accountability.
Every execution step carries its delegation context, traceable back to why something was permitted, not just that it happened. This closes the gap between "the system had permission" and "the system should have acted in this specific way at this specific moment."
Portable evidence.
Structured, exportable evidence bundles that are vendor-neutral and signature-ready. Designed for three levels of review:
- An executive summary for boards and decision-makers
- A structured control and exception view for procurement and assurance teams
- Detailed execution records with checkpoint and artefact references for compliance, audit, and investigation
Not locked into one platform or AI vendor. Built so the evidence can travel, be defended, and be reviewed at the level each audience actually needs.
"In practice, this means ARBITR is not just producing logs. It is producing evidence packages that executives can understand, procurement teams can assess, and compliance teams can work with, in a standards format."
Architecture principles.
ARBITR is SaaS-first and runtime-agnostic. Envelope discipline is absolute because evidence portability depends on a stable record shape across tenants, runtimes, and releases. Storage is append-only. Tenant isolation is enforced at the database layer. No raw secrets are persisted in envelopes. Signature-readiness is built in from v1 so evidence bundles can be cryptographically sealed as the programme matures. The design is extensible across environments and organisational boundaries without changing the underlying execution record.
This is the discipline that makes the evidence defensible later, not just convenient now.
Competitive positioning.
The agent market is splitting into layers, not converging into one crowded category. ARBITR's lane is the neutral execution evidence and interpretation layer across agents, runtimes, enterprise systems, and commit surfaces.
The market is not becoming one agent platform. It is becoming a network of execution surfaces. ARBITR helps organisations evidence, interpret, and defend what autonomous systems actually executed across those surfaces.
Status.
ARBITR is in active development. The core primitive is stable, the V1 product scope is defined, and ten pilot organisations are being selected. The product is not available for general sale at this stage. The pilot programme is the only commercial path today.
ARBITR is best suited, today, to organisations deploying or planning autonomous systems where execution authority matters across payments, record modification, agent-triggered workflows, or other compliance-sensitive operations.
Express interest in the ARBITR Pilot.
Ten organisations will help shape ARBITR while structural feedback can still influence the product. Each pilot partner pays a single fixed entry fee and receives lifetime access thereafter. This is not a discount scheme. It is a partnership.
Submit an Expression of Interest and, if the fit is strong, you will be invited to a qualification call. Shortlisted organisations receive the Prospectus and, under mutual non-disclosure, the Architecture Brief and Envelope schema.
Not ready for either? For advisory, integration, or partnership enquiries that sit outside the pilot route, email contact@magentix.ai.