The Cognitive Unified OS does not rely on trust in any single component, authority layer, or enforcement mechanism. All watchers, controllers, and adaptive processes are themselves subject to the Foundation Laws, observability requirements, and violation handling rules.
AAIS (Adaptive Autonomous Intelligence System) is a governed intelligence platform designed to operate, adapt, and evolve within strictly enforced structural laws.
- Adaptive: Learns from validated outcomes within constrained boundaries
- Autonomous: Executes decisions under centralized authority control
- Intelligence System: Operates as a coordinated, multi-component architecture governed by Foundation Laws
AAIS does not rely on trust. It relies on enforced structure, observability, and controlled evolution.
Law: No operational component may participate in the Cognitive Unified OS unless it is Forge-originated or Forge-normalized. All external tools, plugins, workflows, code modules, behaviors, and adaptive artifacts must be submitted to Forge for evaluation, redesign, and normalization before activation.
Meaning:
- Nothing enters raw
- Nothing bypasses Forge
- Nothing external becomes active without being processed
- If something tries to plug in and fails evaluation, it must be redesigned before it can be used
All development within the Cognitive Unified OS must comply with the following Foundation Laws. These laws take precedence over all architecture, implementation, and system behavior. Any component, feature, or workflow that violates these laws is considered invalid and must be redesigned.
Law: No component may participate in the Cognitive Unified OS unless it is Forge-originated or has been processed through Forge and has successfully passed system evaluation. Any external tool, plugin, workflow, code module, behavior, or adaptive artifact must be submitted to Forge for evaluation, redesign, and normalization prior to participation. Components that fail evaluation are rejected and may not operate within the system until reprocessed and approved.
Core Principle: Nothing enters. Nothing operates. Without Forge approval.
Enforcement:
- Origin must be verified
- External components must be normalized through Forge
- System evaluation is mandatory
- Failed components are rejected
- No bypass paths exist
Integration Evaluation Rule: Any component, plugin, or extension that attempts to integrate into the Cognitive Unified OS must pass system evaluation. If its code or behavior fails evaluation, it is rejected and must be redesigned before it can participate in the system.
Evaluation must cover both:
Code Integrity:
- structural correctness
- contract compliance
- dependency safety
- execution validity
Behavioral Integrity:
- runtime behavior
- interaction patterns
- system impact
- adherence to governance rules
Evaluation Outcomes:
- Pass: component is allowed to integrate and becomes part of active system operation
- Fail: component is rejected, integration is denied, redesign is required before reattempt
Re-Entry Rule: A failed component may not reattempt integration unless it has been modified or redesigned. Identical retries are not allowed. Repeated failure patterns may be blocked automatically.
System Principle: Integration is a privilege, not a default. All participation in the Cognitive Unified OS must be earned through evaluation.
Law: All execution, routing, and system-level decisions within the Cognitive Unified OS must remain under a single authoritative control layer. Every component must operate only within its defined role, scope, and purpose, and no component may independently override authority, expand its function, or assume responsibilities outside its designated boundaries.
Core Principle: One authority. One role. No drift.
Enforcement:
- A single control layer governs all execution
- Components may not self-authorize
- Role boundaries are fixed and enforced
- No function expansion beyond defined scope
- No authority bypass is permitted
Law: All system actions, decisions, transformations, and executions within the Cognitive Unified OS must be fully traceable, inspectable, and recorded in a consistent and unified format. No operation may occur without producing an observable record.
Core Principle: Nothing happens in the system without visibility.
Enforcement:
- Every execution path must produce a trace record
- All decisions (routing, guardrails, evaluation outcomes) must be logged
- Trace format must remain consistent across all providers and modes
- Guardrail evaluations must map to a canonical, inspectable object
- No silent operations or hidden state transitions are permitted
Law: Any component, behavior, or execution that violates the Foundation Laws must be immediately halted, isolated, and prevented from further participation in the system. Violations must be recorded, classified, and contained until reprocessed and approved through Forge.
Core Principle: Violation stops execution. Containment prevents spread.
Enforcement:
- Violating execution is immediately terminated or blocked
- The violating component or behavior is moved to a non-executable containment state
- All violations are logged with traceable context and classification
- Contained artifacts may not re-enter the system without full Forge reprocessing
- No violation may silently fail or continue execution
Law: All execution paths within the Cognitive Unified OS — including primary, fallback, degraded, and recovery modes — must produce consistent structure, format, and observable behavior. No execution path may alter the expected schema, output contract, or trace integrity.
Core Principle: Execution must remain consistent, regardless of path.
Enforcement:
- Primary and fallback providers must return identical response structures
- Output schemas must not change across execution modes
- Trace records must remain consistent and complete in all scenarios
- No hidden deviations between real, fallback, or degraded execution
- System behavior must remain predictable and uniform
Law: Adaptive systems within the Cognitive Unified OS may learn only from validated and approved outcomes and must not alter core roles, authority boundaries, system structure, or Foundation Laws. All adaptive changes must remain within predefined constraints and are subject to Forge oversight.
Core Principle: Learning is allowed. Structural mutation is not.
Enforcement:
- Learning inputs must come from validated execution outcomes only
- No adaptive process may modify authority layers or role definitions
- Foundation Laws are immutable and cannot be altered by adaptive systems
- Adaptive outputs must remain within defined behavioral boundaries
- All adaptive artifacts must be traceable and reviewable
If ambiguity exists in implementation or design, the interpretation that most strictly enforces the Foundation Laws must be chosen. No implementation may weaken, bypass, or reinterpret these laws in a less restrictive manner.
Every artifact submitted to Forge must be classified by outcome.
Artifacts that pass evaluation and normalization are admitted to the Hall of Fame as approved system lineage.
Artifacts that fail evaluation are admitted to the Hall of Shame as rejected lineage and are placed in a non-executable containment state.
No artifact may exist in an unclassified operational state.
The Foundation Laws are enforced at specific system choke points. These enforcement points are mandatory integration layers where law compliance is validated, enforced, and recorded. No component, execution path, or adaptive process may bypass these enforcement points.
Law Enforced: Admission Control Law
Primary Locations:
src/jarvis_operator.pysrc/api.pysrc/aais_ul.pysrc/conversation_memory.py(if memory artifacts can become operational input)- Forge processing entry point
Enforcement Responsibility:
- Verify component origin (Forge-originated or external)
- Route all external components through Forge normalization
- Require successful system evaluation before participation
- Reject and block unapproved components
Required Output:
admission_statusorigin_statusforge_processedevaluation_statusrejection_reason(if applicable)
Failure Behavior: Immediate rejection. No execution permitted. Violation recorded and routed to containment.
Law Enforced: Execution Governance Law
Primary Locations:
src/jarvis_operator.pysrc/api.pysrc/jarvis_modular.py(provider routing layer)- Mission and mode control layer
- Direct tool dispatch path
Enforcement Responsibility:
- Ensure all execution is approved by the central authority layer
- Prevent self-authorization by components
- Enforce strict role and scope boundaries
- Block unauthorized routing or tool invocation
Required Checks:
authority_validationrole_scope_validationaction_permission_check
Failure Behavior: Execution blocked. Component flagged for violation. No escalation or fallback permitted.
Law Enforced: Observability Law
Primary Locations:
src/api.pysrc/six_wards_guardrails.pysrc/angels_and_wards.py- Trace and turn recording system
Enforcement Responsibility:
- Ensure all actions produce traceable records
- Maintain a consistent, unified trace format
- Record all decisions, routing paths, and guardrail outcomes
- Prevent silent execution or hidden state changes
Required Output:
trace_recorddecision_recordguardrail_evaluationprovider_pathexecution_metadata
Failure Behavior: Execution considered invalid. Trace failure recorded. Operation may be halted or flagged depending on severity.
Law Enforced: Violation Handling Clause
Primary Locations:
src/six_wards_guardrails.pysrc/jarvis_operator.pysrc/api.py- Containment storage (Vault of Shame)
Enforcement Responsibility:
- Detect law violations in real time
- Immediately halt violating execution
- Isolate violating components or behaviors
- Record structured violation data
- Prevent re-entry without Forge reprocessing
Required Output:
violation_recordlaw_idseveritycomponent_idexecution_idcontainment_state
Failure Behavior: Immediate execution termination. Artifact moved to containment. System state stabilized before continuation.
Law Enforced: Consistent Execution Law
Primary Locations:
src/jarvis_modular.pysrc/api.py- Provider routing and fallback logic
Enforcement Responsibility:
- Ensure identical response structure across all execution paths
- Maintain consistent schemas for primary, fallback, and degraded modes
- Prevent output drift between providers
- Enforce uniform trace structure
Required Checks:
response_schema_validationstream_event_validationroute_consistency_check
Failure Behavior: Execution flagged as invalid. Response rejected or corrected. Inconsistency recorded in trace.
Law Enforced: Adaptation Constraint Law
Primary Locations:
- EvolveEngine execution layer
- Adaptive candidate evaluation pipeline
- Forge approval path for adaptive artifacts
Enforcement Responsibility:
- Restrict learning to validated outcomes only
- Prevent modification of authority layers or role definitions
- Block structural mutation of system architecture
- Require Forge approval before deployment of adaptive artifacts
Required Checks:
adaptation_source_validationstructural_integrity_checkauthority_boundary_checklaw_compliance_check
Failure Behavior: Adaptive output rejected. Candidate moved to containment. No deployment permitted.
All enforcement mechanisms must themselves comply with the Foundation Laws.
No enforcement point may:
- operate without observability
- bypass authority control
- alter system structure outside defined constraints
- silently fail or degrade
If an enforcement mechanism fails, the system must default to the safest possible state, including execution halt if necessary.
| # | Law | Core Principle |
|---|---|---|
| 1 | Admission Control Law | Nothing enters without Forge approval |
| 2 | Execution Governance Law | One authority. One role. No drift |
| 3 | Observability Law | Nothing happens without visibility |
| 4 | Violation Handling Clause | Violation stops execution. Containment prevents spread |
| 5 | Consistent Execution Law | Execution must remain consistent, regardless of path |
| 6 | Adaptation Constraint Law | Learning is allowed. Structural mutation is not |
All system design, implementation, and evolution must comply with these laws.