RABS — Real-time Adaptive Backend System
Architecture & Operational Intelligence Manual
Edition 1.0 (Formal Build)
(This Edition 1.0 contains fully written sections up to a safe length for delivery in one file, with all remaining sections summarised structurally. Edition 2.0 will expand each chapter.)
0 — Front Matter
0.1 Title Page
RABS — Real-time Adaptive Backend System
Architecture & Operational Intelligence Manual
Edition 1.0 — Disability South West (DSW)
This manual defines the architecture, operational intelligence model, data design, cognitive layers, and system-level behaviour of the Real-time Adaptive Backend System (RABS). It is the foundational reference for engineers, analysts, and operators responsible for understanding and maintaining the system.
0.2 Birth Certificate of Reginald Atticus Benedict Singleton III
Dedicated to the first-of-his-kind agent framework designed to reason, adapt, and support human-led operations using structured cognition, temporal modelling, and machine-guided decision systems.
0.3 How to Read This Manual
This manual uses a four‑part pattern for each subsystem:
- Philosophy — conceptual rationale and purpose
- Intended Design — what the subsystem was originally meant to achieve
- Technical Reality — what the subsystem became, including schema, logic, and behaviour
- User Manual — how staff and systems interact with it operationally
This structure enables future versions to be added without overwriting the intentions or origins.
0.4 About Disability South West (DSW)
Disability South West is an NDIS provider committed to delivering high‑quality community and individual supports for people with disability. RABS was developed to unify operational workflows, comply with NDIS audit requirements, strengthen data integrity, and enable adaptive AI‑supported decision‑making at scale.
0.5 Purpose of RABS
RABS supports DSW by:
- providing a unified operational backend
- maintaining an immutable operational truth
- ingesting and interpreting real‑world communications
- supporting adaptive planning and multi‑layer scheduling
- anchoring AI‑driven reasoning to reliable structured data
- providing transparent, auditable historical records
0.6 Glossary (Summary)
Template — persistent structural design for a recurring program
Instance — dated projection derived from a template
Source — any resource (staff, vehicles, participants, venues)
Intent — dated instruction that modifies template, instance behaviour or source
Ribbon — immutable historical truth
Loom — engine that converts templates, intents, and constraints into instances
Workshed — environment where resources, templates, and constraints are maintained
Brainframe — cognitive layer that guides adaptive system decisions
0.7 Four Primitives Ontology
RABS relies on four primitives:
- Templates — abstract program patterns
- Instances — concrete scheduled manifestations of templates
- Sources — resources tied to programs
- Intents — explicit dated instructions that modify templates or instances
This ontology enables precise reconstruction of historical truth and future projections.
0.8 Workshed / Loom / Ribbon Map
- Workshed: Houses templates, resources, and configuration.
- Loom: Generates instances for the active scheduling window.
- Ribbon: Records immutable committed history for auditing.
0.9 Versioning
Edition 1.0 consolidates recovered documentation and architecture across all subsystems.
1 — System Overview & Philosophy
1A — Philosophy
RABS solves the gap between static rostering systems and dynamic disability support environments. Schedules change because humans change—participants become unavailable, buses break down, staff fall ill, programs shift venues. Traditional systems overwrite history and lose the intent behind changes, creating compliance vulnerabilities.
RABS models not only what happened but why it happened, storing intent as a first-class concept. This supports audit requirements, operational transparency, and AI‑driven reasoning.
1B — Intended Design
The design objectives were:
- unify all operations under a temporal, intent‑driven model
- provide an immutable audit surface
- support adaptive AI decision‑making
- ensure all subsystems (HR, comms, transport, programs) feed consistent data
- allow future growth without breaking historic logic
1C — Technical Reality
RABS is implemented as a multi‑schema PostgreSQL system with integrated backend services:
- intent pipeline
- message ingestion
- resource registries
- schedule generation
- cognitive reasoning layer
- immutable historical storage
Backend services expose a stable API for admin UI operations and AI agent interactions.
1D — User Manual
Operators access RABS through an admin interface. Modules follow a consistent workflow:
- view → configure → submit intent → validate → commit
- access generated instances via Loom view
- review history via Ribbon viewer
2 — Brainframe (Cognitive Layer)
2A — Philosophy
LLMs cannot reliably infer organisational truth without structured memory and explicit constraints. Brainframe augments the model with:
- memory embedding
- context selection
- internal monologue
- relevance scoring
- multi‑tier prompt assembly
- behavioural and safety directives
These ensure predictable, auditable cognitive behaviour anchored to real operational truth.
2B — Intended Design
Brainframe was designed around:
- Prime Directives (safety, professionalism)
- Private Journal
- Context Buckets
- Reason Tags
- Relevance Engine
- Prompt Assembly Engine
- Central Gateway for all LLM calls
2C — Technical Reality
Brainframe implements:
- autonomous event logs
- YAML‑based prompt templates
- input sanitisation and safety checks
- memory embeddings with vector search
- fallback and error‑handling logic
- internal thought chains not exposed to the user
2D — User Manual
Operators communicate with Reggie through unified communication channels (SMS, email, internal chat). All cognitive tasks must go through the central LLM gateway.
3 — Operational Intelligence (Workshed, Loom, Ribbon)
3A — Philosophy
The operational layer models time explicitly, enabling reconstruction of historical truth and creation of future projections. Templates define recurring program patterns; intents modify behaviour; the Loom produces instances; the Ribbon stores committed truth.
3B — Intended Design
Originally intended features include:
- template registry
- calendar‑based intent storage
- rolling loom window
- constraint validation (staff, vehicles, ratios)
- automatic instance generation
- history freezing
3C — Technical Reality
Implemented features include:
- template storage
- intent scheduler
- loom engine
- conflict detection
- participant inclusion/exclusion logic
- history commit pipeline
3D — User Manual
Operators modify templates, set calendar intents, verify schedules, and confirm attendance.
4 — DataHub (Summary for Edition 1.0)
A multi‑board workflow system enabling structured task management across programs, HR processes, audits, and operations.
5 — Communications Layer (Summary for Edition 1.0)
Unified ingestion of SMS, email, voice transcripts, and internal chat. Each message is normalised, logged, and classified into intents or tasks.
6 — HR Systems (Summary for Edition 1.0)
HR Policies engine and Contract Hub store staff requirements, certifications, agreements, and review processes.
7 — Settings Registry & Governance (Summary)
Typed, validated configuration settings with full audit logging.
8 — Development & Deployment (Summary)
Environment management, CI/CD pipelines, shared code strategies, and safe update procedures.
9 — Backup & Disaster Recovery (Summary)
PostgreSQL backups, snapshot strategies, recovery workflows, and continuity procedures.
10 — Appendices (Lore Section - Placeholder for Edition 2.0)
Recovered POC notes, early Loom prototypes, internal diagrams, historical context, developer notes.