Clearance-gated memory
Retrieval is scoped to what a given user and task are cleared to see. The deployed identity and source mappings still need customer validation.
The platform
The control and evidence layer behind regulated AI work.
GAIA-CORE assembles access, egress, model-routing and evidence controls in a customer-hosted system. A sector layer adds the approved sources, roles and workflows for a specific regulated domain.
What it is
Six parts, working as one.
The value is in the assembly, not any one component. Together the parts are designed to make knowledge access, model dispatch, evidence and review visible in one transaction.
The egress round-trip
The built mechanism can detect and replace configured protected values before external dispatch, then restore valid surrogates locally. It is currently gated and default-off pending witnessed activation.
TPM-sealed key custody
Key-custody and provenance paths bind protected material to a trusted platform module (TPM) on customer hardware. Final host behaviour is part of the pilot readiness gate.
Tamper-evident audit trail
A hash-chained log records configured system events. It is tamper-evident under its deployment assumptions; protected custody, checkpoints and restore tests remain operational responsibilities.
Live DPIA and RoPA endpoints
DPIA, RoPA and export endpoints can generate technical evidence from system state. They support, rather than replace, the customer’s legal and governance records.
A governed provider router
Local and external endpoints sit behind one interface so a workflow can apply an eligibility and fallback policy. Models are not identical in quality, latency, cost or legal posture; each route must be evaluated.
How it works
Authorise, control, assist, review.
By design, every request follows the same governed path, from the user’s clearance to the named professional who approves the result. The egress round-trip (part 02 above) is one of the controls in the second step. Its source and tests exist; customer use begins only after a hardware-key bind, witnessed activation and customer validation.
Your infrastructure
Authorised user
01
Authorise
Clearance and approved sources
Your organisation’s knowledge
- Memories
- Figures
- Know-how
- Processes
- Skills that improve and grow under review
Multi-level access, with clearance by sector and confidentiality level
Keys sealed to the host’s TPM, disk encryption verified at installation
02
Control
Policy and routing. Protected values are replaced by tokens before anything leaves
Local model
Always present. The request is answered here, unless the task requires more
Only when the task requires it
Boundary of your infrastructureRequest with tokens
External model provider or rented GPU capacity
Receives tokens and the remaining context, not the protected values
Boundary of your infrastructureResponse
03
Assist
Where tokens were used, the original values are restored locally
04
Review
A named professional approves the result or refers it
Audit trail: each step is recorded, and any alteration is detectable
Schematic of the implemented design. Token replacement is off by default until witnessed activation.
- 01
Authorise
Identity, task and clearance decide which sources and memory the request may use.
- 02
Control
Access rules and the configured egress policy apply before any model is called. Where egress protection is enabled, protected values are replaced before dispatch and restored locally.
- 03
Assist
The routed model returns a draft linked to its sources, a stated uncertainty or a refusal.
- 04
Review
A named professional corrects, approves or escalates the output, and the decision is recorded.
Two designed fail-closed paths in the control step
- If the detector is unavailable, the request is refused rather than sent in the clear.
- If any token in a returned answer cannot be accounted for, the response is held rather than shown. Silence over leakage, by design.
One core, bounded verticals
Control in the core. Useful work in the sector layer.
The product boundary is functional. The core governs the transaction; the sector layer packages the sources, roles, controls and workflows for a domain. GAIA-CORE will be released under AGPLv3; the sector layer remains proprietary.
GAIA-CORE, the reusable layer
Identity context, clearance-aware memory, protected egress, model routing and evidence form the reusable product, the part planned for release under AGPLv3. Until that release, source access and continuity terms are agreed commercially.
The sector layer
Approved sources, data classes, roles, obligations, controls and workflow outputs turn the core into useful regulated work. The first proof is a bounded investment-management pilot, not a catalogue of regimes.
Deployment and scale
One instance, or a coordinated network.
The assessed source runs as a single operator-hosted development instance. The product direction can scale to several scoped instances, but customer deployment and multi-instance coordination have not yet been proven.
Standalone
One instance in a customer-controlled environment. This is the proposed first pilot shape, not a generally available deployment.
Coordinated centrally
A coordinator instance issues clearance-gated cross-queries across the others, so a question can draw on more than one domain without anyone seeing what they have no right to.
Distributed
Instances federate as peers. Traffic between them rides the same egress discipline: tokenised, recorded, and refused if a token cannot be accounted for.
Single-instance source is built and operator-hosted. There is no official customer deployment. Multi-instance coordination is roadmap only.
Where it stands
Source just short of MVP, on a controlled path to pilot.
As assessed on 10 October 2026, merged source contains 130,595 tracked TypeScript lines across 963 commits. A clean-clone install and build passed.
The cumulative regression harness passed all 1,430 criteria in the assessed environment. Separate HTTP integration suites passed 10/10 and 18/18.
There is currently no official customer deployment. Egress enforcement is off by default. Key material is sealed to the host’s TPM and backups are encrypted before they leave the host. The development installation runs on an encrypted disk; on a pilot, disk encryption and the rest of the security configuration are set up and verified on the customer’s infrastructure before it starts. Interested firms are invited to discuss a paid, bounded design-partner pilot.