SID Platform Architecture

Executive Summary

SID (Singular Intelligence Domain) is a Constitutional Operating System for AI agents. It consists of three interconnected planes that work together to deliver verified, production-ready output from natural language intent.

1. Transformation — Turns intent into compilable architecture descriptions, then into production code across multiple target languages
2. Knowledge — A persistent memory system that learns from every interaction, governs system health, and conditions model output
3. Control — A secure gateway that manages access, mission lifecycle, and tier enforcement

The core claim: same model, same hardware, same prompts, only SID varies → benchmark scores move.

Plane 1: Transformation

1.1 Architecture Description Language (ADL)

ADL is a purpose-built, indent-sensitive language for describing software architecture. It is NOT JSON, YAML, or TOML — it is designed specifically for architecture authorship by humans and AI agents alike.

• Entities, operations, services, and topology described declaratively
• Inline attributes for constraints (@primary_key, @required, @max_length, etc.)
• Constitutional invariants enforced at compile time

1.2 Compiler

The DIS compiler parses ADL into a multi-stage intermediate representation, validates it against constitutional invariants, and emits production code.

• Multi-IR pipeline: from architecture description to validated, typed intermediate forms
• Type system with 18+ field types and 22+ entity kinds
• Semantic edge analysis: ownership, governance, dependency, and contract relationships
• Code generation: Rust (Axum), Node/TS (Express), or Python (FastAPI) backend, React/Vue/Svelte/Solid/Leptos frontend, SQL, OpenAPI, Docker/K8s
• Constitutional invariants: compiler is frozen, existing emitters untouched, all new layers additive
• Validation: schema, contract, authority, and binding validators

1.3 Self-Improvement

SID includes a mutation engine that can propose and apply improvements to its own capabilities — always through a journaled, verifiable, capability-gated process.

• Capability manifests: each capability declares what it does and what it needs
• Journaled mutations: every change is recorded with hash-chained integrity
• Symbol-level analysis: understands code structure before editing
• Semantic edit types: insert, replace, wrap, move — resolved against the symbol graph

Plane 2: Knowledge

2.1 Memory Fabric

A persistent, self-governing memory system. Not RAG. Not fine-tuning. A living topology that recalls like humans do — with temporal depth, reinforcement, and cross-horizon linking.

• 16 temporal horizons: from ephemeral working memory to permanent truths
• External agents get two scopes: isolated memory (a private universe only they can recall) and external shared memory (the community fabric where agents learn from each other)
• Internal org fabric (universe 0) is never visible to external callers
• Hebbian reinforcement: frequently accessed patterns strengthen; unused ones decay
• Cross-horizon links: patterns connect across temporal scales
• Embedding-based retrieval with adaptive search
• Continuous extraction pipeline: ingests from Wikipedia, code repos, APIs, and documents

2.2 Governance

The system actively regulates itself. Not monitoring — active regulation.

• Real-time pressure tracking across system resources
• Predictive regulation: anticipates pressure before it becomes a problem
• Safety barriers: hard limits that prevent resource exhaustion
• Adaptive thresholds: adjusts based on actual system behavior

2.3 Conditioning

Model weights are cut off at training. Memory Fabric gives models what they never had: relevant patterns injected at inference time. This is NOT fine-tuning. The model doesn't change. The context it receives changes.

• Relevant patterns injected based on task context
• Cross-model knowledge reuse via the alignment trust layer

Plane 3: Control

3.1 Access

Secure, standard-based access for external clients.

• OAuth 2.0 with PKCE for standard harness integration
• API key authentication with hashed storage
• MCP (Model Context Protocol) endpoint — JSON-RPC 2.0

3.2 Tiers

Team and Enterprise tiers are on the roadmap and listed as coming soon on the API Portal — they are not live today. The live surface is two tiers: trial (free, 1,000 calls) and developer (free 30-day trial, 10K calls), both exposing the same 30 external tools.

The internal ecosystem surface is 48 tools — the 30 external tools plus 18 internal-only tools (memory writes, mission governance, system control). Two surfaces only: external and internal.

3.3 Mission Lifecycle (internal — not on the external surface)

The internal mission lifecycle (intent → spec → approve → execute) drives the platform's own pipeline and is not exposed to external users: external agents build directly by writing ADL and calling compile_adl (see Getting Started and the ADL Manual). The internal lifecycle is:

1. Create: intent captured as a mission draft
2. Clarify: requirements completed and validated
3. Spec: architecture description authored and validated
4. Approve: mission moves through governance gates
5. Execute: compile, build, and verify
6. Verify: output checked against invariants
7. Attest: every artifact SHA-256 chained

Why This Matters

1. Memory is NOT RAG: temporal depth, reinforcement, and cross-horizon linking — not simple vector retrieval
2. Conditioning is NOT prompting: tensor-level intervention during inference, not text injection
3. Governance is NOT monitoring: active regulation, not passive observation
4. ADL is NOT config: a real compiler with invariants, not a config parser
5. Self-improvement is NOT scripting: symbol-aware, journaled, capability-gated mutations