Identity without memory:
The actor is verified, but the agent has no continuity of context. Each interaction starts blind. Decisions made with prior knowledge cannot reference that knowledge as evidence.
Identity · Memory · Execution
The Architecture.
An AI-native organisation's architecture has many layers. Three of them decide whether what it does can be held to account: identity, memory, and execution. IdSolid® holds the first two - who is acting, and what context informs the action. ARBITR holds one part of the third - not the carrying out of execution, but the evidence of what executed, under whose authority, against which target, with what result, at the moment of commit. The two products are independent, and deliberately bounded. Each holds a layer where accountability is won or lost, and leaves the rest of the architecture to others.
This page is for the architectural reader. The reader who has decided AI governance frameworks are necessary but who is starting to suspect that policy alone, without architecture underneath it, will not survive the first regulator who looks past the diagram.
Why policy without architecture does not survive scrutiny
Every AI governance framework currently in circulation describes how AI should behave. Policies define acceptable use. Frameworks set principles. Risk registers catalogue what could go wrong. The vocabulary is mature, the documents are well-meaning, and the conversation has been running for a decade.
What is missing is the same thing that was missing from financial governance before payment standards were ratified, and from internet security before TLS became universal: architectural guarantees underneath the policy claims. A policy that says "AI will only act within authorised boundaries" describes the desired state. The architectural question - what enforces the boundary, what records the action, what proves the authority at the moment of execution - has been answered by hand-waving for most of the AI governance era.
The cost of that gap is becoming visible. AI systems are now executing real changes against payments, records, workflows, and cross-system processes. Policy frameworks did not slow this down. Architectural enforcement, of the kind regulated finance has had since the 1970s, has not yet arrived. The next round of AI failures will not be at the model layer or at the policy layer. They will be at the architectural layer, and they will be the failures policy was supposed to prevent but had no mechanism to enforce.
This architecture is the answer to that gap.
The three layers
Three layers decide whether an AI-native organisation can be held to account: identity, memory, and execution.
Identity. Who is acting. Whose authority is the action being performed under. What credentials does the actor carry. What attributes have been verified, by whom, to what standard. Without an architectural answer to identity, every layer above rests on assumption.
Memory. What context informs the action. What history is the actor drawing on. What previous decisions are being referenced. Where does that context live, and who controls whether it persists across providers, tools, and models. Without architectural sovereignty over memory, AI systems either start every interaction from zero or accumulate context inside a vendor's silo with no portability path.
Execution. What actually happened. What target system was affected. What result occurred. Under what specific authority chain. At what exact moment of commit. Without an architectural record of execution, governance becomes retrospective speculation defended by people who cannot say with certainty.
Each layer has its own architectural challenges and its own failure modes when ignored. What has not existed until now is an integrated way of thinking about the three together, and a pair of products that occupy two of the three at peer-level senior altitude.
How the three layers compose
The layers do not stack in strict order. They compose.
An AI agent receives a task. Identity establishes who is asking, under what authority. Memory provides the context the agent uses to interpret the task. Execution is what the agent then does against the target system. Each step produces evidence. The evidence chain is itself an artefact of the architecture - a record that the right actor, with the right context, executed the right action under the right authority.
When the layers are intact, the audit question has a single answer. When any one layer is missing or weak, the audit question has no answer that survives scrutiny.
Memory without identity:
AI carries context but cannot prove who the context belongs to or who authorised its use. Context becomes ungoverned data, and every regulator that has thought about AI memory in the past three years has flagged this as the next major exposure."
Execution without identity or memory:
The action happened but its causation cannot be traced. "An AI did it" is not an answer a board, an auditor, or a regulator can accept.
All three together: the audit question is closed. Who acted, with what context, under what authority, against what target, with what result, at what moment of commit. Every step recorded as evidence in a format the recipients of audit already trust.
The two Magentix products.
Two products, mapped to the layers above. IdSolid holds identity and memory. ARBITR holds the evidence of execution - and only that.
IdSolid®
Sovereignty as a structural property of storage, not as a contractual promise.
IdSolid is the sovereign-by-architecture layer for identity and memory. Each subject's identity attributes and AI memory live inside their own cryptographically isolated Sovereign Pod. The subject owns the pod. The architecture provides sovereignty as a structural property of storage, not as a contractual promise. Bank-verified attributes, government-issued credentials including those under eIDAS and the EU Business Wallet, professional credentials, and the Open Brain memory layer all live inside the pod and travel with the subject across providers.
ARBITR
The board-grade evidence record for what executed, under whose authority, at what moment.
ARBITR is the evidence layer for execution. It does not govern, enforce, or control execution. Other systems do that. ARBITR captures what executed, under whose authority, against which target, with what result, at the moment of commit, and packages the record as a board-grade evidence report - the kind a CFO walks into a board meeting holding, or that lands on a regulator's desk without an engineering escort.
The execution layer is not one job but three. Something has to carry the action out: the agent platforms and runtimes where AWS, Google, Microsoft, OpenAI and others compete. Something has to enforce what is allowed to run: authority and policy engines such as Zortrex, compliance choke points such as Genesis50, agent-platform governance, and policy-as-code. And something has to evidence what actually ran. ARBITR does only the last of these. It does not carry execution out and it does not enforce it; it records across whichever systems an organisation has already chosen for those jobs. The narrowness is the point. A record is only trusted as evidence when the thing producing it has no stake in the outcome.
So Magentix builds identity and memory in IdSolid, and the evidence of execution in ARBITR. Carrying execution out, and enforcing it, belong to others by design.
Why independence matters.
IdSolid and ARBITR are sold independently. An organisation can adopt one without the other and still get a complete product. There is no architectural lock-in between them.
This matters for three reasons.
Adoption sequencing. An organisation that has already committed to a particular identity infrastructure but needs execution evidence can adopt ARBITR without disrupting their identity stack. An organisation that wants sovereign data and AI memory but is comfortable with their current execution monitoring can adopt IdSolid without changing their execution layer. The architecture does not require all-or-nothing.
Procurement reality. Senior buyers in regulated finance procure architectural layers separately. Bundling them would force a single decision in front of a procurement committee whose appetite for novel architecture decisions is finite. Two products in two procurement cycles is more digestible than one product in one over-large cycle.
Vendor sovereignty. Each Magentix product earns its place on its own merits. Neither rides the other's adoption. If IdSolid is the right answer for an organisation but ARBITR is not, the organisation gets the right answer to its actual question.
That said, when both are adopted the coverage compounds. An organisation running IdSolid and ARBITR together can account for identity, memory, and the evidence of execution in one coherent picture: who acted, with what context, and with what proof. The systems that carry execution out and enforce it stay the organisation's own choice, and both products are built to compose with them.
Where to go from here.
Status.
This architecture is a framework Magentix has built across multiple engagements in regulated finance, AI governance, and applied cybernetics. The two products that occupy its first two layers - IdSolid and ARBITR - are running their respective Early-Design-Partner and Pilot programmes, with twenty and ten places being selected on lifetime-access partnership terms.
The framework itself is open. Magentix does not claim ownership of the broader picture; the architectural argument it makes is intended to clarify the AI governance conversation, not to lock it down. Other vendors are welcome to occupy other layers. The market is not becoming one platform - it is becoming a network of architectural surfaces, and this architecture is one way of seeing that network with strategic discipline.