FEDERATED INDUSTRIAL / AOTX-1
Persistent inference
systems.
A continuing environment for local inference, developed by Federated Industrial.
AOTX starts from a system question: what must remain coherent as models execute, conversations develop and a machine restarts? Its design brings execution, agents, memory and communication into a runtime with explicit ownership and a recoverable history.
- 01 / EXECUTION
- CUDA
- 02 / STATE
- GPU memory
- 03 / PERSISTENCE
- Disk journal
Continuity as a system property.
A system continues through the relationships between its parts: the source behind a memory, the authority behind an action and the recorded state behind a restart. AOTX makes those relationships part of the architecture.
Purpose and engineering scope
Local computation with a continuing history.
Purpose
AOTX-1 organises inference as a system that an operator can run, observe and maintain over time. Models supply execution; agents, memory and communication provide the surrounding environment. Authoritative active state resides in GPU memory, with defined paths for input, control and persistence.
The aim is continuity that can be explained. A later conversation should have a known relationship to what came before it. A saved runtime should identify the state it can restore. A shared service should make clear whose information is available to whom.
The system account
- Sources retain their provenance and ownership.
- Changes enter an ordered, recoverable history.
- Access follows explicit membership and grants.
- Saved generations define where continuation begins.
Local operation
The operator supplies a compatible host, CUDA driver and device, and controls the runtime’s configuration and deployment. Local interfaces and a separate gateway provide different ways into the same device-owned environment.
Engineering principles
Defined responsibilities
Cognitive and numerical work belongs in CUDA. Host glue establishes resources and launches graphs; disk processes maintain persistent files; clients handle presentation and transport within their defined contracts. Work enters in batches and proceeds within the selected profile’s capacity.
Recovery is part of correctness
An operation is understood through both its live result and the history it leaves behind. Testing therefore follows work through interruption, storage pressure, reconnection and restore. The important question is which state can be recovered, and whether the next operation begins from that state consistently.
For model-facing behaviour, the same discipline extends to meaning. A correctly framed result still needs to interpret its source appropriately. Qualification examines that behaviour for a declared model and processing configuration.
Inspectable contracts
Capabilities, resource limits and operation receipts give clients an explicit account of what the running instance can do. They connect architectural intent to the decisions an application makes during use.
The development programme
PROGRAMME / SEPTEMBER 2026
IN DEVELOPMENT
The current foundation brings together device execution, persistent source storage, complete CCIR packaging, supported image and audio input, supplied-context inference and continuing shared service. Compatible creator-policy maintenance and optional cold-memory offload are integrated into that environment.
Current qualification
Automatic memory interpretation is enabled for one exact model, processor, source profile and message-wrapper configuration. Other configurations retain ordinary conversation and source-text history. This is the established starting point for the next stage of work, rather than a claim across an entire model family.
The programme now extends how a continuing runtime uses its history. The following areas describe prospective development, progressing towards an integrated release:
- Appraisal and relationships
Develop the interpretation of events and relationships into useful, evidence-linked context for later interaction. The work centres on attribution, uncertainty, correction and the effects those judgements have on subsequent recall.
Automatic appraisal is under development and has not yet passed semantic qualification.
- Identity and affect
Extend controllable identity and affect behaviour around stable memory and appraisal consumers. The intended controls must have observable effects for supported configurations and preserve their state through recovery.
- Bounded reflection
Use available idle periods for evidence-supported reflection and lesson formation. The intended results are revisable, tied to their sources and useful to later work; foreground activity must be able to interrupt the process cleanly.
This builds beyond the maintenance operations already present in the runtime.
- Integrated operation
Bring local and shared use, text and media, corrections, optional operating modes and copied-file recovery through a common release qualification. Cancellation, resource pressure and repeated restart belong in that complete operational account.
Progress is established through usable behaviour and its recovery evidence. These directions extend the runtime’s capabilities while retaining the same organising principles: local authority, explicit state and a history that can be continued.
Read the system
Architecture and operation
The architecture overview follows state from the GPU to persistent storage. Its chapters then examine execution and scheduling, memory and recovery, and local and shared access. Together they explain how the system’s parts participate in one continuing runtime.
The portable runtime
CCIR brings the assets and saved state into one file. The portability chapter describes the complete path from an acknowledged generation to activation on a compatible destination, including how operation receipts and local permissions retain their meaning.