MODULE INDEX

Aerius Runtime Modules

The architecture components that sit around AI models: input, observation, orchestration, reasoning, memory, identity, knowledge, domain runtime, expression, action, trace, and governance.

Read Concept Library View Portfolio

MODULE GROUPS

Each module exists because a cognitive responsibility should not be hidden inside a model-only response.

Input & Observation

IISLCOR

Explore Modules ->

Orchestration & Reasoning

CCOStack BrainPbRMRMI

Explore Modules ->

Memory & Identity

COMSMemory PyramidIMCRCC

Explore Modules ->

Knowledge & Domain Runtime

KELDCRCPOR

Explore Modules ->

Expression & Action

CEAVoice / ExpressionIntent Action

Explore Modules ->

Trace & Governance

Trace / EvidencePolicy GatesHuman Review

Explore Modules ->

INPUT & OBSERVATION

Input & Observation

Modules activate conditionally based on task, context, evidence, risk, policy, domain need, and available resources.

Input to Observation Chain

Raw Input

IISL

Structured Context

COR

Governed Observation

Input & Observation

IISL

Intelligent Interface and Sensor Layer

What it does: Receives input, events, files, streams, API data, sensor data, digital sources, and external information, then converts them into structured, provenance-aware context.
Why it exists: Raw input is not reliable context. IISL makes source, provenance, validation, and routing explicit before the architecture reasons over an event.
Why it matters: Without IISL, Aerius would treat weakly structured inputs as if they were ready for reasoning.
Architecture Position: Entry point of Aerius, before observation, orchestration, memory retrieval, reasoning, domain runtime, and action governance.

Related modules

CORCCOTrace / Evidence

Related concepts

Multi-modal intakeProvenanceDeterministic context formationEvidence-carrying input

Related portfolio item: IISL - Intelligent Interface and Sensor Layer

Input & Observation

COR

Cognitive Observation Runtime

What it does: Governs observation as a cognitive resource, deciding what should be observed, when, from which source, and under which evidence, risk, privacy, authority, and resource constraints.
Why it exists: Traditional systems collect data first and decide later. COR decides what should be observed before observation occurs.
Why it matters: COR prevents observation from becoming passive data capture by tying perception to intent, evidence, risk, and budget.
Architecture Position: After intake and before or during reasoning; it can be re-triggered when more evidence is needed.

Related modules

IISLCCOPbRCOMS

Related concepts

DOEObservation DirectiveEvidence EscalationObservation BudgetRisk-Aware Observation

Related portfolio item: COR - Cognitive Observation Runtime

ORCHESTRATION & REASONING

Orchestration & Reasoning

Modules activate conditionally based on task, context, evidence, risk, policy, domain need, and available resources.

Orchestration & Reasoning

CCO

Central Cognitive Orchestrator

What it does: Coordinates cognitive processing across observation, memory, reasoning, domain runtime, action, policy, and trace systems.
Why it exists: A pile of tools is not architecture. CCO gives Aerius a coordination layer so modules activate for a reason, under context and policy.
Why it matters: CCO prevents cognitive modules from behaving as disconnected systems without shared coordination.
Architecture Position: Central coordination layer connecting COR, PbR, Stack Brain, COMS, DCR, CPOR, CEA, and Intent Action.

Related modules

CORStack BrainPbRCOMSDCRIntent Action

Related concepts

Cognitive orchestrationTask routingRuntime coordinationPolicy coordination

Related portfolio item: Hybrid Cognitive Orchestrator Architecture

Orchestration & Reasoning

Stack Brain

Aerius Stack Brain

What it does: Coordinates multiple reasoning stacks within the same cognitive runtime under orchestration, synchronization, and meta-level control.
Why it exists: Complex tasks rarely fit a single pass. Stack Brain coordinates reasoning stacks without reducing Aerius to multi-agent chat or an agent chain.
Why it matters: Stack Brain gives Aerius structured reasoning depth while keeping reasoning inside one synchronized cognitive architecture.
Architecture Position: Reasoning control layer, coordinated by CCO and influenced by PbR and MRMI.

Related modules

CCOPbRMRMICOMS

Related concepts

Stack-based reasoningReasoning stackIntermediate cognitive stateMeta-level control

Related portfolio item: Aerius Stack Brain

Orchestration & Reasoning

PbR

Priority-Based Reasoning

What it does: Determines cognitive priority, reasoning depth, urgency, risk handling, confidence handling, resource allocation, and reasoning rhythm.
Why it exists: Reasoning resources are limited. PbR decides where cognitive effort, depth, urgency, and safety attention should be spent.
Why it matters: PbR keeps reasoning effort aligned with risk, urgency, confidence, and utility instead of spending effort randomly.
Architecture Position: Cross-cutting reasoning priority layer influencing observation, memory retrieval, domain capsule use, human review, and action governance.

Related modules

CCOStack BrainCORCOMSIntent Action

Related concepts

Priority-Based ReasoningCognitive priorityReasoning depthResource allocation

Related portfolio item: PbR - Priority-Based Reasoning

Orchestration & Reasoning

MRMI

Meta-Reasoning and Meta-Innovation

What it does: Selects, evaluates, improves, and governs reasoning strategies without base-model retraining.
Why it exists: Better reasoning should not always require retraining a model. MRMI lets Aerius select and improve strategies at the architecture layer.
Why it matters: MRMI lets reasoning strategy evolve without turning every improvement into a base-model training problem.
Architecture Position: Above or around reasoning processes, influencing Stack Brain, PbR, policy objects, and reusable reasoning patterns.

Related modules

Stack BrainPbRKELCPOR

Related concepts

Meta-reasoningStrategy selectionStrategy policy objectNo base-model retraining

Related portfolio item: MRMI - Meta-Reasoning and Meta-Innovation

MEMORY & IDENTITY

Memory & Identity

Modules activate conditionally based on task, context, evidence, risk, policy, domain need, and available resources.

Memory & Identity

COMS

Cognitive Orchestrated Memory System

What it does: Provides governed, evidence-aware, multi-modal, tiered memory with deterministic retrieval and as-of versioning.
Why it exists: Most AI systems retrieve context. COMS governs what memory should be used, why it is valid, and under what evidence state.
Why it matters: COMS keeps memory from becoming ordinary RAG by governing retrieval, evidence, versioning, and memory status.
Architecture Position: Cross-cutting memory layer supporting reasoning, identity, knowledge evolution, evidence storage, trace records, retrieval, and updates.

Related modules

CCOPbRIMCRCCKELCPOR

Related concepts

Deterministic RetrievalAs-Of VersioningEvidence-Driven PromotionTrace-linked memory

Related portfolio item: COMS - Multi-Modal Tiered Memory

Memory & Identity

Memory Pyramid

What it does: Represents a tiered structure for organizing memory by durability, authority, evidence strength, recency, operational use, and long-term reliability.
Why it exists: Not all memory deserves the same weight. Memory Pyramid gives COMS a way to separate temporary, operational, evidence-backed, and durable memory.
Why it matters: Memory Pyramid helps Aerius avoid treating every stored fact, preference, trace, or signal as equally authoritative.
Architecture Position: Supports COMS and the broader memory architecture.

Related modules

COMSIMCKEL

Related concepts

Tiered memoryMemory promotionMemory demotionEvidence strength

Related portfolio item: Memory Pyramid / COMS-related technical disclosure

Memory & Identity

IMC

Identity Memory Core / Identity-Bound Memory

What it does: Stores, binds, and updates memory associated with persons or entities under a cognitive memory architecture.
Why it exists: Continuity breaks when identity context is treated as generic memory. IMC binds memory to persons or entities under governance.
Why it matters: IMC lets identity-aware context persist without collapsing people, entities, roles, and preferences into generic storage.
Architecture Position: Within memory and identity context handling, working with COMS and sometimes RCC, CEA, PbR, and Intent Action.

Related modules

COMSRCCCEAIntent Action

Related concepts

Identity-bound memoryEntity memoryRole contextCross-session continuity

Related portfolio item: IMC - Identity-Bound Memory

Memory & Identity

RCC

Relational Cognition Core

Working / developing technical disclosure unless filing status is confirmed

What it does: Extends identity memory into relational context with trust, familiarity, role, boundary requirements, safety, expectation gaps, and entity-specific context.
Why it exists: People and entities are not static profiles. RCC lets Aerius activate trust, role, boundary, familiarity, and safety context only when relevant.
Why it matters: RCC gives Aerius relational and entity-aware cognition instead of simple profile lookup, social labels, or trust scores.
Architecture Position: Near IMC and COMS; trigger-based, activating only relevant relational context.

Related modules

IMCCOMSCEAPbRIntent Action

Related concepts

Relational CognitionEntity ContextTrust ContextRole / Boundary Context

Related portfolio item: RCC - Relational Cognition Core

KNOWLEDGE & DOMAIN RUNTIME

Knowledge & Domain Runtime

Modules activate conditionally based on task, context, evidence, risk, policy, domain need, and available resources.

Knowledge to Runtime Chain

Human Knowledge

KEL

Validated Knowledge

DCR

Operational Runtime

CPOR

Governed Reuse

Knowledge & Domain Runtime

KEL

Human-Driven Knowledge Evolution Layer

What it does: Extracts, structures, validates, promotes, demotes, quarantines, and governs knowledge derived from humans, interactions, observations, or reviewed sources.
Why it exists: Human input should not become permanent truth automatically. KEL turns candidate knowledge into validated, promoted, demoted, or quarantined structures.
Why it matters: KEL lets Aerius learn from human-derived knowledge without accepting every interaction as durable system truth.
Architecture Position: Between human knowledge, memory, reasoning, COMS, and MRMI.

Related modules

COMSMRMIDCRCCO

Related concepts

Human-Driven Knowledge EvolutionKnowledge validationPromotion / demotionQuarantine

Related portfolio item: KEL - Human-Driven Knowledge Evolution Layer

Knowledge & Domain Runtime

DCR

Domain Capsule Runtime

What it does: Turns domain expertise into runtime behavior by binding executable reasoning packages, protocols, tools, verifiers, risk profiles, and authority boundaries into Aerius.
Why it exists: A domain capsule is an executable reasoning package, not merely a document collection. DCR makes domain knowledge operational inside the runtime.
Why it matters: DCR makes domain knowledge operational, so Aerius can reason within governed domain boundaries instead of pasting documents into context.
Architecture Position: Domain reasoning layer, selected by CCO, prioritized by PbR, supported by COMS, and validated before use.

Related modules

KELCCOPbRStack BrainCOMS

Related concepts

Domain CapsuleRuntime BindingProtocol validation gateAuthority boundary

Related portfolio item: DCR - Domain Capsule Runtime

Knowledge & Domain Runtime

CPOR

Conditional Processing Outcome Reuse

What it does: Conditionally reuses prior cognitive processing outcomes when task, context, evidence, time, risk, policy, and reuse scope allow it.
Why it exists: Reuse can save work, but stale reuse is dangerous. CPOR reuses prior outcomes only when context, evidence, time, risk, and policy still match.
Why it matters: CPOR prevents reuse from becoming a cache by checking whether a prior cognitive outcome is still valid.
Architecture Position: Before or during reasoning when a similar prior cognitive outcome exists; connected to COMS, PbR, CCO, policy gates, and traces.

Related modules

COMSCCOPbRMRMIDCR

Related concepts

Conditional ReuseTask signatureContext compatibilityReuse trace

Related portfolio item: CPOR - Conditional Processing Outcome Reuse

EXPRESSION & ACTION

Expression & Action

Modules activate conditionally based on task, context, evidence, risk, policy, domain need, and available resources.

Intent to Output Chain

Intent

CEA

Expression

Action Governance

Governed Output

Expression & Action

CEA

Cognitive-Emotional Architecture

What it does: Manages cognitive-affective state, ethical shaping, controlled uncertainty, expression intent, continuity, and communication behavior.
Why it exists: Expression is not just tone. CEA governs uncertainty, ethical shaping, cognitive-affective state, and continuity before output reaches a person.
Why it matters: CEA keeps communication behavior aligned with state, ethics, uncertainty, and safety rather than surface style alone.
Architecture Position: Cross-cutting layer influencing reasoning, communication, uncertainty expression, safety, and output behavior.

Related modules

CCOVoice / ExpressionIntent ActionIMCRCC

Related concepts

Cognitive-affective stateExpression intentEthical shapingControlled uncertainty

Related portfolio item: CEA - Cognitive-Emotional Architecture

Expression & Action

Voice / Expression

Intent-Driven Multi-Modal Cognitive Expression Orchestration

What it does: Coordinates how cognitive intent becomes multimodal expression across voice, gaze, facial expression, gesture, and other expressive channels.
Why it exists: Voice or gesture without cognitive intent is cosmetic. Voice / Expression links multimodal output to state, intent, and governance.
Why it matters: Voice / Expression acts as an output orchestrator, making expression part of the cognitive architecture rather than a presentation layer.
Architecture Position: After or alongside CEA and before external expressive output.

Related modules

CEAIntent ActionCCO

Related concepts

Expression intentVoiceGazeGestureMultimodal output synchronization

Related portfolio item: Voice / Expression Orchestration

Expression & Action

Intent Action

Cognitive Intent-Driven Physical Action Orchestration

What it does: Governs how cognitive intent becomes response, digital action, physical action, human review request, or blocked action.
Why it exists: Tool access is not action governance. Intent Action decides whether intent should become response, action, human review, or block.
Why it matters: Intent Action separates the ability to act from the authority, safety, and policy decision to act.
Architecture Position: Near the output and action boundary, applying safety, policy, role, context, risk, and human-review constraints.

Related modules

CCOPbRCEADCRPolicy Gates

Related concepts

Cognitive intentSemantic action planAction governancePolicy gate

Related portfolio item: Intent-Driven Physical Action

TRACE & GOVERNANCE

Trace & Governance

Modules activate conditionally based on task, context, evidence, risk, policy, domain need, and available resources.

Trace & Governance

Trace / Evidence

Trace and Evidence Structures

What it does: Make reasoning, observation, reuse, and action inspectable after execution by recording what happened, why, what evidence was used, and what policies applied.
Why it exists: A fluent answer is not an inspectable process. Trace and evidence structures record what happened, what supported it, and what policies applied.
Why it matters: Trace / Evidence enables reconstruction of how a decision was reached instead of treating trace as a simple log.
Architecture Position: Cross-cutting across observation, memory, reasoning, domain capsule use, reuse, expression, action, and policy gates.

Related modules

CORCOMSCPORDCRIntent Action

Related concepts

TraceabilityEvidence recordObservation traceMemory evidence

Related portfolio item: Multiple items including COR, COMS, CPOR, DCR, and Hybrid Cognitive Orchestrator Architecture

Trace & Governance

Policy Gates

Policy, Risk, Authority, Privacy, and Human-Review Gates

What it does: Determine whether observation, memory use, domain capsule use, reuse, output, or action should proceed under risk, privacy, authority, safety, or human-review constraints.
Why it exists: Safety cannot live only at the final output. Policy gates create checkpoints across observation, memory, domain use, reuse, expression, and action.
Why it matters: Policy Gates make governance part of the runtime process rather than a final moderation pass.
Architecture Position: Across the architecture, not only as a final content filter.

Related modules

CORDCRCPORCEAIntent ActionHuman Review

Related concepts

Policy GateRisk gateHuman ReviewAuthority boundary

Related portfolio item: Multiple items including COR, CEA, Intent Action, DCR, and Hybrid Cognitive Orchestrator Architecture

Trace & Governance

Human Review

Human Review Pathways

What it does: Escalate runtime behavior to a person when risk, uncertainty, authority, privacy, or policy requires review.
Why it exists: Human review is not failure. It is the governance path Aerius uses when risk, uncertainty, authority, or policy requires a person.
Why it matters: Human Review gives Aerius an explicit escalation path for decisions that should not be fully automated.
Architecture Position: Can be triggered by PbR, COR, Intent Action, DCR, CEA, or policy gates.

Related modules

PbRCORDCRCEAIntent ActionPolicy Gates

Related concepts

Human ReviewPolicy GateRisk-adaptive reasoningAction trace

Related portfolio item: Multiple items including COR, Intent Action, DCR, CEA, and Hybrid Cognitive Orchestrator Architecture

HOW MODULES WORK TOGETHER

Coordinated runtime layers, not separate products.

Aerius modules are not isolated SaaS features. They are coordinated cognitive runtimes that activate according to task, context, evidence, risk, policy, domain need, and resources.