Repository structure for Nous-OSS organized by the Mind Model — four layers of consciousness

Repository Folder Structure

This document defines the repository structure for Nous-OSS.

The structure is organized by the Mind Model — four layers of consciousness that mirror the architecture of the human mind. See the Mind Model (architecture reference) for the philosophical foundation.

Everything that IS Nous lives inside self/. Everything else — documentation, examples, scripts — exists outside the being.

Top-Level Structure

nous-core/
│
├── .apps/                            # Installable app packages
├── .skills/                          # Installable skill packages + .system process infrastructure
├── .workflows/                       # Installable workflow packages
├── .projects/                        # Local workspace state and project instances
├── .contracts/                       # Shared contract bundles and contract-local assets
├── self/                             # The being
│   ├── apps/                         # Senses — interaction surfaces
│   ├── cortex/                       # Layer 1 — Consciousness
│   ├── memory/                       # Layer 2 — Memory System
│   ├── subcortex/                    # Layer 3 — Subconscious Processing
│   ├── autonomic/                    # Layer 4 — Infrastructure
│   └── shared/                       # Cross-layer nervous system
├── docs/                             # Written about the being
├── examples/                         # Demonstrations of the being
├── scripts/                          # Tools used during development
└── package.json

The hidden root directories are the canonical package and workspace stores. Installable packages live in .apps/, .skills/, and .workflows/; active local project state lives in .projects/; shared contracts live in .contracts/.

self/

Everything inside self/ is Nous. The four layers of consciousness, the shared nervous system, and the senses through which Nous interfaces with the world.

Nothing outside self/ is part of the runtime. Docs describe the being. Examples demonstrate it. Scripts support development. But the being itself is contained within this boundary.

self/apps/ — Senses

How Nous perceives the world and communicates with the user. These are part of the being — your senses are not accessories, they are you.

self/apps/
├── app-sdk/                         # Browser-runtime SDK for installable app panels
├── cli/                              # Terminal interface
├── web/                              # Chat UI + Projects UI + Dashboard + Marketplace + MAO + mobile operations + public MCP edge
└── bridge/                           # Approved messaging bridge app and connector adapters

app-sdk/

Browser-runtime SDK for installable app panels.

Phase 15.2 adds self/apps/app-sdk/ as the canonical workspace package for the browser-side panel SDK consumed by installable apps. The Phase 15.2 in-scope surface is:

NousPanel
useTool
useConfig
useTheme
useNotify

Phase 15.3 extends the same SDK surface with:

usePersistedState
onActivate
onDeactivate

Phase 15.5 extends the same SDK surface with live config convergence:

PanelBridgeClient.subscribeConfig() for additive host-owned config refreshes
NousPanel / useConfig() subscription-driven updates when trusted hosts push config.changed
No iframe-local or browser-local settings authority beyond the canonical host bridge snapshot

Panels use this package to speak the canonical versioned postMessage bridge to the trusted host. The SDK is a bridge client and projection helper only: it lets sandboxed panel code invoke app tools and read host-projected config/theme state through the host bridge, while keeping host internals, privileged routing, and second-source-of-truth state out of the panel surface.

The lifecycle and persistence split remains explicit. preserveState is host-owned in-session DOM preservation for iframe panels; it keeps inactive panels hidden without turning the browser into a durable state authority. Cross-session panel state flows through usePersistedState over the trusted host bridge and the canonical /mcp handoff into app-scoped runtime-owned state.

cli/

Terminal interface. Command parsing, streaming output, trace visibility, project switching.

Primary interface for power users and automation.

CLI depends only on public interfaces from shared/.

web/

Web application containing integrated operator surfaces:

Chat interface — conversational interaction with project-scoped context
Projects UI — advanced workflow authoring, staged visual debugging, canonical project dashboard, governed configuration, schedule settings, and project-scoped escalation queue acknowledgement
Dashboard — system health, project status, memory inspection, and discovery projection
Marketplace — governed package browse, package detail, moderation, advisory discovery, and project-scoped app install entry
MAO operator surface — density-grid observability, run-graph inspection, reasoning-preview handoff, and governed project control
Mobile operations surface — phone-sized project status, escalation acknowledgement, voice follow-up posture, and read-only trust summaries
Chat escalation inbox — acknowledgement of the same canonical in-app escalation queue used by Projects
Voice-control server surface — in-process tRPC composition over the canonical voice runtime for turn state, degraded-mode visibility, interruption handling, text-first recovery flows, and mobile continuity projection
Public MCP edge — Streamable HTTP /mcp ingress plus OAuth discovery metadata for approved external clients

Primary interface for most users.

The same app host also owns the machine-facing /mcp route and the /.well-known/oauth-protected-resource/mcp plus /.well-known/oauth-authorization-server/mcp discovery documents. The host remains transport-thin: it parses HTTP, composes shared services at bootstrap, and hands admitted work into the canonical gateway runtime rather than a web-local shadow API. The trusted app-panel host also uses this same /mcp boundary adapter for lifecycle reconciliation and persisted-state bridge traffic instead of introducing a second host-local persistence or control seam.

Phase 15.4 extends the same host with canonical app-install preparation and execution transport for package-detail surfaces. The host can launch the shared three-stage install wizard, but secret and OAuth handling plus persisted config truth remain in the backend install service instead of browser-owned state.

Phase 15.5 extends the same host with canonical app-settings preparation and save transport for installed app package-detail surfaces. The web package detail view can reuse the shared AppSettingsSurface, refetch canonical settings truth after save, and push additive config refresh events to active app panels without introducing browser-owned settings state.

bridge/

Messaging integrations for mobile-first and asynchronous interaction.

Phase 11.1 ships the first production bridge app here. Phase 14.6 keeps the bridge app as connector-native adapter/runtime compatibility scaffolding while the canonical communication-gateway runtime now owns connector registration and session truth.

Telegram adapter (current production connector)
Bridge runtime that composes ICommunicationGatewayService in process and registers connector identity with the canonical gateway
Future adapters for Matrix / Slack and later messaging surfaces

Connector-native parsing and outbound transport stay app-local in this package. Canonical routing, identity-binding, acknowledgement, suppression, trust, and delivery truth remain in the communication-gateway runtime below.

Apps continue to follow the same app-hosted composition rule used elsewhere in the repo: the bridge process wires its runtime graph at bootstrap, hosts the canonical gateway seam in process, and never invents a second control plane or connector-owned state model.

self/cortex/ — Layer 1: Consciousness

The thinnest layer. The highest authority. Decides, reflects, inhibits, authorizes.

self/cortex/
├── Cortex/                              # Prefrontal Cortex engine
└── core/                                # Central executive loop + AgentGateway runtime harness

Cortex/

The Prefrontal Cortex engine.

Responsibilities:

Reflection (evaluating outputs, checking confidence)
Inhibition (deciding what not to do)
Projection (simulating consequences before committing)
Tool authorization
Memory write approval
Policy enforcement
Escalation decisions
Tier configuration (0–5)

Only this package may authorize side effects.

core/

The central executive loop. The spine that connects consciousness to everything below.

Responsibilities:

Orchestrates the runtime flow for single agent cycles and the deterministic AgentGateway turn loop
Orchestrates long-running project supervision loops
Calls the Cortex engine
Coordinates the subcortex through interfaces
Coordinates memory through interfaces
Persists execution traces and gateway-linked runtime evidence

Phase 12.1 adds self/cortex/core/src/agent-gateway/ as the canonical internal agent execution harness. Workflow run-state authority remains in the Phase 9 workflow runtime throughout the migration.

Phase 12.2 adds self/cortex/core/src/internal-mcp/ as the scoped Internal MCP composition layer for the gateway runtime. This folder owns the internal tool catalog, authorization matrix, request normalization, capability handlers, lifecycle handlers, and output-schema validation seam used by AgentGateway. These handlers wrap canonical subcortex and memory interfaces; they do not replace the underlying workflow, witness, scheduler, escalation, or memory authorities.

Phase 14.4 extends the same Internal MCP lane with the canonical workflow lifecycle tool family: workflow_list, workflow_inspect, workflow_start, workflow_status, workflow_pause, workflow_resume, and workflow_cancel. Read projections remain available only on the ratified internal lanes, while mutations stay Cortex::System-only and execute with witness-linked runtime evidence instead of introducing an app-local control seam.

Phase 12.3 adds self/cortex/core/src/gateway-runtime/ as the boot assembly for the long-lived Principal/System pair. Phase 12.4 completes that assembly by adding the gateway-backed turn executor, trace recorder, and runtime-owned project API composition so active runtime callers, canonical packet stamping, and trace continuity all converge under the gateway-managed path.

Phase 12.5 extends self/cortex/core/src/gateway-runtime/ with the durable System backlog queue (backlog-types.ts, backlog-store.ts, backlog-queue.ts) and canonical backlog analytics publication through the existing runtime-health and replica seams. Queue pressure remains runtime truth inside core rather than app-local telemetry or a second scheduler.

Phase 13.1 adds self/cortex/core/src/public-mcp/ plus boundary mapping helpers beside self/cortex/core/src/internal-mcp/. These files translate external ortho.* names onto the canonical flat internal catalog, keep phase gating at the public boundary, and preserve the existing AgentGateway/Internal MCP execution seam.

The legacy CoreExecutor implementation is retired in Phase 12.4 after caller cutover and parity verification. Gateway-managed execution now completes only through task_complete(), which validates canonical node output schemas and stamps the final nous.v: 3 packet.

Core is the bridge between consciousness and the layers below. It does not make decisions — it coordinates the flow that allows the Cortex to make decisions.

self/memory/ — Layer 2: Memory System

The learning system. Stages, compresses, consolidates, retrieves, and governs access to knowledge.

Memory is its own layer because it is neither consciousness nor subconscious. It receives experiences from above (through Cortex-approved writes) and serves context upward (through retrieval). It has internal processing (distillation) that runs on its own schedule.

self/memory/
├── stm/                              # Short-term memory
├── ltm/                              # Long-term memory
├── mwc/                              # Memory write candidate ingress/orchestration
├── distillation/                     # Experience → pattern compression
├── retrieval/                        # Budgeted, scored retrieval orchestration
├── knowledge-index/                  # Cross-project intelligence
│   ├── meta-vectors/                 # Project-level embeddings
│   ├── taxonomy/                     # Topic tagging and structural links
│   ├── relationships/                # Background relationship mapping
│   └── discovery/                    # Query-time project selection
├── access/                           # Memory access policy engine
└── stubs/                            # Contract stubs for fail-close surfaces

stm/

Short-term memory. Working context for active interactions.

Responsibilities:

Recent conversation state
Active working context
Summaries of evicted older context
Recent tool outputs

Optimized for context window efficiency. Older entries are summarized before eviction.

ltm/

Long-term memory. Durable, structured knowledge.

Responsibilities:

Structured facts
User preferences
Experience records (outcome-labeled with sentiment)
Distilled patterns
Project-scoped and global knowledge

All entries include provenance metadata. All entries are auditable, exportable, and deletable.

Implemented in the current runtime as @nous/memory-ltm (Phase 8.2). The package owns:

Document-backed durable entry storage
Mutation audit history and tombstone creation
Lifecycle-aware query/export defaults
Governed typed-write flows for fact and preference
Coupling of approved typed writes to the Phase 8.1 vector-index path

mwc/

Memory write candidate ingress and mutation orchestration. Implemented as @nous/memory-mwc.

Responsibilities:

Accept Cortex-approved memory write candidates
Evaluate mutation requests at the candidate/orchestration boundary
Delegate durable typed entry persistence and lifecycle mutations to @nous/memory-ltm
Preserve STM-specific operations such as compact-stm

This package is the ingress seam between Cortex-approved write intent and the durable memory runtime.

distillation/

The compression engine. Implemented as @nous/memory-distillation (Phase 4.3). Phase 8.4 adds the prototype evaluation harness that selected structured-summary-v1, and Phase 8.5 promotes that approved path into the live project-scoped production runtime. Prototype comparators remain package-local and test-only; scheduler-triggered orchestration, autonomy enforcement, and operator-facing visibility stay in later phases.

Responsibilities:

Identify clusters of related experience records (tag/project strategies; semantic deferred)
Compress clusters into pattern statements with provenance (basedOn, supersedes, evidenceRefs)
Assign initial confidence from sentiment consistency and volume; support refresh (confirming signals) and decay (staleness, contradiction)
Persist only guarded promote decisions; hold or reject contradictory, stale, or weakly supported clusters
Mark superseded records for archival via ILtmStore.markSuperseded
Support supersession reversal — restore source records to active, retire pattern (caller emits audit)
Emit lifecycle and export outputs for downstream governance and visibility consumers
Policy gate: caller must invoke policy evaluation before distillation writes when scope is cross-project or global

This is the current "sleep cycle" runtime slice: offline consolidation through the production distillation engine rather than query-time summarization. Background scheduling, autonomy decisions, and UI visibility are layered on later; they are not owned by this package.

Designed for independent iteration. Swap distillation strategies without touching storage or retrieval.

retrieval/

Query-time context assembly. Implemented as @nous/memory-retrieval (Phase 4.2).

Responsibilities:

Embed the current situation
Score candidates by semantic similarity, sentiment weight, recency, and confidence (deterministic formula; tie-break by entry.id)
Enforce retrieval token budget with truncation telemetry
Merge results from project-scoped and cross-project sources
Assemble labeled context for the LLM prompt
Log all retrieval decisions

SentimentWeightedRetrievalEngine combines semantic similarity, sentiment valence (via getSentimentWeight), recency, and confidence. Configurable weights default to semantic relevance primary. All retrieval flows through PolicyEnforcedRetrievalEngine; when policy denies, the response includes policyDenial for trace linkage.

Phase 6.1 cross-project retrieval: Queries may specify targetProjectIds explicitly for multi-project scope. No hidden cross-project joins — all cross-project reads are policy-gated and explicit. When targetProjectIds is present, the engine applies a selection policy (token budget, result cap) and returns selectionAudit (projectIdsQueried, candidateCount, resultCount, truncationReason) for audit.

Retrieval is reconstruction, not lookup. The same knowledge may surface differently depending on the question.

knowledge-index/

Cross-project intelligence. Implemented as @nous/memory-knowledge-index (Phase 6.2, runtime-expanded in Phase 9.4). The layer that makes cross-referencing cheap at query time and now exposes a canonical runtime seam for refresh, snapshots, and policy-filtered discovery.

knowledge-index-runtime.ts — The Phase 9.4 facade that owns one-project-at-a-time refresh, text-query embedding, policy filtering, snapshot assembly, and bounded-support diagnostics. This is the implementation behind IKnowledgeIndex.

knowledge-refresh-store.ts — Append-only refresh ledger for auditable refresh outcomes, duplicate-suppression inputs, and latest-refresh lookup per project.

meta-vectors/ — One embedding per project summarizing its domain, themes, and knowledge profile. MetaVectorStore (IVectorStore-backed) and MetaVectorService; Phase 9.4 adds auditable metadata (evidenceRefs, inputDigest, refreshRecordId) and refresh-on-pattern inputs.

taxonomy/ — Topic tags assigned to projects. Phase 9.4 adds document-backed assignment records so project-to-tag and tag-to-project lookups stay canonical and queryable beyond in-memory test support.

relationships/ — Background relationship graph maintained by periodic evaluation (Phase 6.3). Phase 9.4 upgrades the store to deterministic semantic edge IDs and document-backed inspection so repeated refreshes can diff created, updated, and invalidated edges.

discovery/ — Query-time orchestrator (Phase 6.3) plus the Phase 9.4 runtime assembly that combines meta-vector search, taxonomy links, relationship graph, and policy filtering to determine relevant candidate projects without performing retrieval.

access/

Memory access policy enforcement. Implemented as @nous/memory-access (Phase 3.2).

Responsibilities:

Evaluate can_read_from and can_be_read_by policies per project
Evaluate inherits_global for global memory access
Enforce node-level overrides (more restrictive only)
Gate all cross-project retrieval through policy checks
Support read, write, and retrieve actions with deterministic evaluation order
Emit durable denial evidence with POL-* reason codes for unauthorized attempts
Consume project control-state (hard_stopped blocks all access)

The policy decision engine (MemoryAccessPolicyEngine.evaluate()) is synchronous and replay-deterministic. Callers supply project config and control state as inputs.

stubs/

Contract stubs and fail-close baselines for memory interfaces used in tests and incomplete runtime surfaces.

Phase 3.3 surface integration: Policy enforcement is wired at (1) core-executor — policy gate before mwcPipeline.submit() for cross-project memory writes; (2) PolicyEnforcedRetrievalEngine — wraps IRetrievalEngine, evaluates policy before delegating, filters results by policy; (3) StubProjectApi.memory — optional policy deps run gate before throwing for read/write/retrieve when cross-project or global scope.

Phase 3.4 policy observability: All policy decisions derive from canonical truth. Denials include PolicyDecisionRecord (reasonCode, traceId, evidenceRefs). Export hooks for Phase 4 (learning loop) and Phase 5 (workflow foundation) are documented in .worklog/phase-3/phase-3.4/export-hooks.mdx.

Phase 6.1 cross-project contract: Cross-project retrieval requires explicit targetProjectIds (from project discovery or allowlist). Policy evaluation runs before any cross-project read. Selection policy governs token budget and result cap; selectionAudit preserves audit trails for why results were selected. No recommendation path bypasses policy denial.

Default: open. Isolation is opt-in.

self/subcortex/ — Layer 3: Subconscious Processing

The workhorse. Does the actual work — model invocation, tool execution, workflow orchestration, scheduling, escalation. Processes below the level of conscious orchestration. Surfaces results upward. Never commands upward.

self/subcortex/
├── router/                           # Model role → provider routing
├── providers/                        # Model provider adapters
├── tools/                            # Tool execution and capability gating
├── workflows/                        # Workflow graph engine
├── projects/                         # Project container and lifecycle
├── apps/                             # Canonical app runtime (Deno subprocess, MCP-over-IPC)
├── communication-gateway/            # Human messaging ingress/egress control plane
├── public-mcp/                       # Public MCP discovery, admission, bootstrap, and audit runtime
├── endpoint-trust/                   # Peripheral pairing, trust, capability, and transport runtime
├── voice-control/                    # Canonical voice turn safety, interruption, and continuation runtime
├── registry/                         # Registry governance, moderation, and compatibility runtime
├── nudges/                           # Advisory discovery runtime and ranking
├── artifacts/                        # Versioned binary asset management
├── scheduler/                        # Time-triggered and recurring execution
├── escalation/                       # Principal notification channels
├── mao/                              # Multi-agent observability aggregation and control projection
├── sandbox/                          # Execution isolation (WASM)
└── sdk/                              # Project API surface for packages

router/

Role-based model routing.

Responsibilities:

Resolve model role → provider
Apply profile configuration
Handle fallback and failover rules
Enforce privacy constraints
Support heterogeneous provider types (text, image, video, vision, embedding)

Routing decisions are deterministic and logged.

Router does not execute models directly.

providers/

Model provider adapters for all model types.

providers/
├── local/                            # Local runtime models
├── remote/                           # Remote API models
└── wasm/                             # WASM models

Responsibilities:

Normalize input/output schemas across provider types
Support multiple I/O modalities (text, image, video, structured data)
Support multiple execution models (streaming, synchronous, async/batch)
Provide streaming support for text models
Report token/compute usage
Abstract provider-specific differences

Phase 12.5 adds in-process per-endpoint inference lanes in self/subcortex/providers/src/inference-lane.ts, inference-lane-registry.ts, and lane-aware-provider.ts. These files own bounded concurrency, agent-class priority ordering, Principal-only preemption, exclusive voice-call lease handling, wait-estimate analytics, and the narrow lease-release notification seam while preserving existing routing and failover authority above the concrete providers.

No orchestration logic lives here.

tools/

Tool interface definitions and execution wrappers.

Responsibilities:

Tool schema validation
Capability declaration
Permission metadata
Execution mediation

Phase 9.4 adds internal knowledge-index tools:

discover_projects — governed, policy-filtered discovery for text queries
refresh_project_knowledge — canonical one-project refresh for meta-vector, taxonomy, and relationship projections

Each tool declares:

Name and version
Input and output schemas
Required capabilities
Permission scope

Tools execute only through Cortex authorization.

workflows/

Workflow graph engine. The runtime for protocol and hybrid projects.

Phase 9.1 establishes the first concrete workflow-runtime baseline in @nous/subcortex-workflows.

Responsibilities:

Resolve canonical workflow definitions from project-scoped configuration
Build deterministic derived graphs from canonical node and edge definitions
Validate DAG structure and reject invalid workflow graphs before execution
Evaluate fail-closed admission before any run is created
Track canonical run, node, and dispatch-lineage state
Execute node-based workflow graphs
Checkpoint and resume on interruption
Conditional branching based on node outputs and quality gates
Mixed execution model support (synchronous, streaming, async/batch, scheduled)
Node-level governance enforcement (MUST / SHOULD / MAY)
Progress tracking and state persistence

This is the engine that makes protocol projects operational.

Current Phase 9.3 modules in this package include graph builder, graph validator, traversal, admission, governed node execution, checkpoint/runtime continuation handling, run-state, workflow-engine foundations, and canonical trigger provenance persistence.

Phase 14.3 extends the workflow engine with installed-package binding resolution:

Projects can reference installed workflow packages through packageBindings in project workflow configuration. The engine resolves the definition through the matching binding at runtime and falls back to inline project-authored definitions when no binding applies.
resolveDefinitionSource exposes the resolved source as ResolvedWorkflowDefinitionSourceSchema metadata so monitoring and debug surfaces can distinguish installed package definitions from inline definitions without re-deriving source from project config.
All ADR-007 and ADR-008 runtime contracts — deterministic DAG traversal, centralized admission, evidence-linked run state, governed node execution, wait states, correction arcs, and committed-checkpoint continuation — remain unchanged by binding resolution.

projects/

Project container and lifecycle management.

Responsibilities:

Project creation and type assignment (protocol, intent, hybrid)
Namespace management
Model role assignments per project
Governance configuration
Memory access policy storage
Tool permission sets
Execution trace tracking
Project lifecycle (create, configure, execute, evolve, archive)

Projects are first-class isolation boundaries.

Phase 14.3 adds document-loading modules to self/subcortex/projects/src/package-store/:

document-loader.ts — parses and normalizes installed skill and workflow package documents. Classifies skill packages as atomic, composite, or legacy_hybrid, loads composite constituent skills through the shared dependency resolver with deterministic DAG cycle rejection, and loads workflow packages by parsing WORKFLOW.md, nous.flow.yaml, and steps/*.md with nous.kind: workflow_step step admission.
legacy-hybrid-bridge.ts — provides explicit compatibility normalization for legacy hybrid skill packages, keeping them callable during the migration period without silent behavior divergence from decomposed loading paths.

Phase 14.4 extends the same package-store lane with canonical installed-workflow read helpers:

document-loader.ts / index.ts — add deterministic listInstalledWorkflowPackages(...) and inspectInstalledWorkflowPackage(...) helpers over .workflows/, keeping legacy hybrids out of canonical installed-workflow discovery while preserving compatibility-only loading paths.

Phase 15.4 adds self/subcortex/projects/src/app-install/ as the project-scoped app-install lane:

config-store.ts — persists non-secret app config plus secret-presence metadata for one project/package pair
service.ts — prepares install contracts from registry releases, validates required config, delegates vault/OAuth setup, runs install hooks, activates apps, and owns rollback cleanup
index.ts — exports the install seam for host bootstrap and test consumers

Phase 15.5 adds self/subcortex/projects/src/app-settings/ as the project-scoped app-settings lane:

service.ts — prepares canonical settings contracts, validates candidate config, stages secret mutation, enforces config-version compare-and-swap, owns deactivate -> update -> reactivate, and performs rollback/recovery
index.ts — exports the settings seam for host bootstrap and test consumers

apps/

Canonical app runtime for installed .apps packages. Implemented in Phase 14.5 as @nous/subcortex-apps.

Responsibilities:

Activate installed app packages as Deno subprocesses behind the existing RuntimeMembrane.onAllow seam
Compile manifest permissions into deterministic Deno CLI flags with ratified hard-deny posture (--deny-env, --deny-run, --deny-ffi)
Own MCP-over-IPC handshake, activation config delivery, and app-exposed tool registration through the canonical Internal MCP catalog
Integrate app lifecycle (activate, deactivate, enable, disable) with the package lifecycle orchestrator and witness-linked evidence
Track app health and heartbeat visibility through runtime-owned seams
Export only the contract and registration seams Phase 15 needs for panel delivery

Nous core stays on Node.js; apps run as Deno subprocesses. MCP over IPC is the sole app-to-core communication path. The IAppRuntimeService interface lives in @nous/shared and is consumed by cortex-core and gateway-runtime for health projections and capability-handler integration.

communication-gateway/

Canonical human messaging ingress and egress runtime. Implemented in Phase 11.1 as @nous/subcortex-communication-gateway.

Responsibilities:

Validate normalized channel ingress before any privileged route or delivery action
Enforce explicit identity-binding posture (unbound, active, revoked)
Resolve canonical routes for approval intake, project messaging, escalation acknowledgement, advisory delivery, and system notices
Persist delivery attempts with idempotent egress identity, bounded retry, failover controls, and fail-closed unknown_external_effect handling
Bridge escalation acknowledgement and advisory delivery through the existing escalation and nudge runtimes instead of creating local truth
Defer endpoint identity, pairing, capability, and signed-envelope authority to the endpoint-trust runtime instead of connector-owned state

public-mcp/

Canonical machine-to-machine MCP ingress runtime. Implemented in Phase 13.1 as @nous/subcortex-public-mcp.

Responsibilities:

Serve protected-resource and authorization-server discovery documents through thin host adapters
Validate bearer posture, audience, origin, and scopes before any tool mapping or bootstrap action
Derive source-local namespaces and persist external-only bootstrap manifests in public_mcp_namespace_registry
Persist witness-linked admit and reject audit projections in public_mcp_audit_projection
Hand admitted execution to the core public MCP bridge and existing AgentGateway/Internal MCP seams instead of introducing a second runtime

endpoint-trust/

Canonical endpoint trust, pairing, capability-governance, and signed-transport runtime. Implemented in Phase 11.2 as @nous/subcortex-endpoint-trust.

Responsibilities:

Persist manual peripheral pairing state and Principal approval evidence before any endpoint becomes trusted
Register endpoints with immutable sensory or action direction and explicit capability manifests
Enforce capability grants and revocations as canonical runtime truth rather than adapter-local flags
Validate signed endpoint transport envelopes with nonce, TTL, session, and monotonic-sequence checks
Require operator-control-compatible confirmation posture for high-risk action commands
Revoke sessions and trust state immediately on lost-device, compromised-device, or MITM incidents
Consume registry install-eligibility posture so untrusted or blocked connector and device packages cannot become active trusted endpoints
Emit witness-linked evidence and route incident escalation through existing canonical seams

voice-control/

Canonical voice turn-taking, interruption, degraded-mode, and confirmation runtime. Implemented in Phase 11.3 as @nous/subcortex-voice-control.

Responsibilities:

Persist canonical voice turn, decision, assistant-output, barge-in, continuation, degraded-mode, and session-projection state
Require combined semantic, silence-window, and explicit-handoff signals before a turn can become execution-ready
Reuse the shared confidence-governance runtime for clarify, block, and text-confirm decisions instead of creating voice-local policy
Force dual-channel confirmation for destructive or T3 voice actions and block voice-only authorization paths
Stop assistant output immediately on barge-in, record timing evidence, and require explicit continuation rather than automatic resume
Push risky controls into text-first degraded mode when confidence, handoff stability, or interruption recovery posture is unsafe
Preserve route, escalation, endpoint-trust, and witness continuity so chat, Projects, MAO, and later mobile surfaces read the same canonical truth

registry/

Registry governance, moderation, and compatibility enforcement runtime. Implemented in Phase 10.1 as @nous/subcortex-registry.

Responsibilities:

Canonical registry package, release, maintainer, governance-action, and appeal persistence
Signed metadata-chain validation with replay, downgrade, expiry, signer, and digest checks
Install/update eligibility projection for lifecycle consumers without taking executable-state authority
Moderation ladder and maintainer-governance state transitions
Witness-linked registry evidence and reuse of the existing escalation runtime for high-risk blocks

nudges/

Advisory feature-discovery runtime. Implemented in Phase 10.2 as @nous/subcortex-nudges.

Responsibilities:

Canonical nudge signal intake with evidence-linked source references
Candidate envelope generation from registry eligibility, discovery explainability, and policy-denial posture
Governed ranking-policy selection and seven-component score calculation
Durable suppression evaluation across delivery surfaces (dismiss_once, snooze, mute_category, mute_project, mute_global)
Delivery and delivery-block record generation with reason codes and evidence refs
Advisory-only acceptance routing that records lifecycle authorization intent for marketplace packages and non-executing advisory acknowledgements for other source types

This package computes what should be recommended and why. It does not install, enable, dispatch, or execute directly.

artifacts/

Versioned binary asset management.

Responsibilities:

Store project-scoped binary artifacts (images, videos, LoRAs, configs, reports)
Version artifacts with full provenance (which node, when, what parameters)
Persist artifact integrity refs and prepared-versus-committed visibility state
Support export and deletion consistent with memory governance
Enable artifact referencing from workflow nodes and memory entries

Phase 9.3 implements this package as @nous/subcortex-artifacts, backed by the autonomic document store. The runtime exposes canonical version records, project-scoped read/delete contracts, and integrity verification on retrieval.

scheduler/

Time-triggered and recurring execution.

Responsibilities:

Cron-like scheduling for recurring tasks
Calendar-style one-shot execution
Hook and system-event envelope submission through the canonical ingress gateway
Duplicate-safe redispatch using ingress idempotency instead of scheduler-local side effects
Configurable delivery mode, workmode, and workflow bindings per schedule

The clock of the subconscious.

Phase 9.3 implements this package as @nous/subcortex-scheduler. It persists schedule definitions and due cursors locally, but all actual execution still flows through ingress and workflow admission rather than a scheduler-local shortcut.

escalation/

Multi-channel Principal notification.

Responsibilities:

Deliver escalation messages through configured channels
Support: in-app notification, push, Signal, Slack, SMS, email, voice call
Structured escalation contracts (what happened, why, recommendation, what's needed, timeout default)
Response tracking across surfaces
Priority mapping per project and per channel

Phase 9.6 implements the first canonical in-app escalation runtime here as @nous/subcortex-escalation. The package owns the document-backed escalation queue, acknowledgement records, project-scoped list/get behavior, and the shared truth consumed by both Projects and chat.

mao/

Multi-agent observability and operator control projection.

Responsibilities:

Aggregate density-grid, inspect, urgent-overlay, and run-graph views from canonical workflow, opctl, escalation, and scheduler truth
Produce evidence-linked reasoning previews without exposing hidden private reasoning
Derive project-control impact and resume-readiness summaries for the MAO operator surface
Preserve deep-link continuity into Projects, Chat, and Traces without creating a second runtime model

sandbox/

Execution isolation.

Responsibilities:

WASM runtime integration
VM isolation (if used)
Capability gating enforcement

Foundational for package execution and future skill runtime.

sdk/

The Project API surface. The mediated contract through which drop-in packages interact with Nous.

sdk/
├── interfaces/                       # API contract definitions
├── runtime/                          # SDK runtime for package execution
└── validation/                       # Package manifest validation

Responsibilities:

Define the Project API contract (memory, model, tool, artifact, escalation, scheduler)
Provide the runtime that bridges packages to the Nous governance stack
Validate package manifests at install time
Enforce capability declarations

See Packages and Plugins (architecture reference) for the full design.

Canonical Root Stores Outside `self/`

The package and workspace stores live outside self/. They are things the being has acquired or is actively working on, not organs the being grew.

.apps/                                # Installable app packages
├── approved-connector/
├── dashboard-extension/
└── ...

.skills/                              # Installable skill packages
├── .system/                          # System-owned process infrastructure
├── image-quality-assessment/
├── react-best-practices/
└── ...

.workflows/                           # Installable workflow packages
├── persona-engine/
├── deal-scout/
└── ...

.projects/                            # Local workspace state, not an install target
├── principal-inbox/
├── synthetic-persona-lab/
└── ...

.contracts/                           # Shared contract store
├── packets/
├── schemas/
└── ...

`.skills/` and `.skills/.system/` — Knowledge

Skills are educational packages. They teach Nous how to think about a domain.

A skill contains:

Structured instructions and rules
Best practices organized by priority
Reference material and documentation
Scripts for validation or analysis (optional)

Each skill package is identified by a canonical SKILL.md manifest. The manifest root conforms to the agentskills.io baseline shape; Nous-specific metadata is namespaced under metadata.nous.* rather than mixed into the shared frontmatter root. Skill packages are classified into one of three tiers:

Atomic — a standalone skill with a single SKILL.md and no constituent dependencies.
Composite — a skill that declares constituent skill dependencies through dependencies.skills. Constituent skills are loaded on demand through the shared dependency resolver rather than eagerly — progressive disclosure keeps the initial load surface minimal and DAG cycles are rejected deterministically.
Legacy hybrid — a package that predates the decomposed skill/workflow model. It remains callable during the transition period and is explicitly tagged legacy_hybrid so loading paths apply compatibility normalization without silent divergence from decomposed loading behavior.

Skills inform reasoning across any project or workflow that touches that domain. They do not execute work directly. .skills/.system/ remains reserved for system-owned process infrastructure and follows the same discovery path under the canonical root layout.

Phase 14.4 proves the additive fork-and-swap migration path by introducing .skills/.system/identity-alignment/ as a decomposed system skill while keeping the legacy .skills/.system/a-soul-is-born/ package intact for compatibility.

`.workflows/` — Workflow Packages

Workflow packages are executable packages. They give Nous a specific plan to execute.

A workflow package contains:

Workflow graph definitions (nodes, connections, governance levels)
Custom node logic (validation, transformation, integration)
Model role assignments and configuration
Prompt templates and configuration
Artifact schemas and storage definitions
Memory access policy defaults
Scheduling and escalation configurations

The canonical source of truth for a workflow package is structured across three files inside the package directory:

WORKFLOW.md — the top-level workflow manifest and authoritative identity/metadata source for the package.
nous.flow.yaml — graph topology owned by the workflow package. Declares the node graph, edges, and entry points.
steps/*.md — individual step files. Step frontmatter must declare nous.kind: workflow_step for the step to be recognized during package loading.

Installed workflow definitions are distinct from project-scoped bindings and runtime instances. A project can reference an installed workflow package through a packageBindings entry without duplicating the definition into project-local configuration or run state. The workflow engine resolves the definition through this binding at runtime, and the resolved source is recorded as workflowDefinitionSource so debug and monitoring surfaces can distinguish an installed package definition from a project-authored inline definition.

Workflow packages produce artifacts and outcomes. All execution is sandboxed. All interaction with Nous goes through the Project API. The canonical package type is workflow; legacy manifest inputs that still say project are normalized at validation ingress so stored runtime state and registry records stay canonical.

Phase 14.4 adds .workflows/.system/a-soul-is-born/ as the first decomposed hybrid-migration pilot in the canonical workflow store. The package depends on the new identity-alignment skill and coexists with the untouched legacy hybrid path instead of replacing it in place.

`.apps/` — Installable Apps

App packages add installable operator surfaces and runtime extensions outside the built-in self/apps/ senses.

An app package can declare:

Required permissions and tool declarations
Optional panels and entrypoints
App-scoped configuration fields
Optional adapters and lifecycle hooks

Phase 14.7 adds .apps/telegram-connector/ as the first first-party reference app in this store. It proves the canonical Deno app lifecycle, namespaced tool registration, progressive connector/full-client configuration, and host-owned communication-gateway integration without reusing self/apps/bridge/ as the runtime source of truth.

Phase 15.1 adds the canonical app-panel host seam for installable apps. Manifest-declared app panels are served through the existing web host at /apps/:appId/panels/:panelId and mounted into trusted shell surfaces as sandboxed iframe panels, rather than through an app-owned parallel UI runtime or alternate host path.

Phase 15.4 extends installable apps with a canonical host-owned install flow. App packages still declare permissions, config fields, and optional lifecycle hooks in the manifest, but hosts now prepare a shared install contract and render the same staged install wizard instead of accepting package-authored install UIs or storing secrets locally.

Phase 15.5 extends the same posture with a canonical host-owned settings flow after install. Installed app packages still declare config in the manifest, but hosts now reuse a shared settings surface, save through the project-scoped settings service, and push additive config refreshes to active panels without exposing secret values or inventing an app-owned settings UI runtime.

This keeps the distinction clear: self/apps/ contains first-party senses that are part of the being, while .apps/ stores installable packages that can extend the operator experience.

`.projects/` — Workspace State

.projects/ stores active local project instances, project configuration, and user workspace state. Discovery classifies it as workspace state rather than as a package store, so it is not treated as an install target alongside .apps/, .skills/, or .workflows/.

`.contracts/` — Shared Contracts

.contracts/ is reserved for shared packet, schema, and contract assets that need a canonical root outside self/. Discovery classifies it as shared_contracts, not as an installable package store.

Composition

Workflow packages reference skills. App packages expose additional tools, panels, or adapters. Local project instances in .projects/ compose the installed packages into active runtime work without collapsing workspace state into the installable package stores.

self/autonomic/ — Layer 4: Infrastructure

Invisible infrastructure. The foundational services that keep the organism alive. The cortex never reasons about these. The subcortex never surfaces them. They maintain the conditions that make everything above them possible.

self/autonomic/
├── credentials/                      # Encrypted credential vault, injector, and OAuth brokerage
├── storage/                          # Persistence backends
├── embeddings/                       # Embedding model abstraction
├── runtime/                          # OS and environment abstraction
├── config/                           # Configuration schema and validation
└── health/                           # Monitoring, maintenance, diagnostics

storage/

Persistence abstraction layer with multiple backend types.

storage/
├── src/
│   ├── sqlite-document-store.ts      # Structured document storage
│   ├── sqlite-vector-store.ts        # IVectorStore local runtime backend
│   ├── in-memory-vector-store.ts     # Deterministic test/runtime baseline
│   ├── in-memory-document-store.ts   # In-memory document baseline
│   └── stubs.ts                      # Contract stubs for fail-close surfaces
└── __tests__/                        # Contract and behavior tests

Responsibilities:

Vector storage (for embeddings and semantic search) with deterministic ordering semantics
Document storage (for structured memory entries, configs, traces)
Graph storage (for relationship mapping)
Pure I/O — no knowledge of memory types or business logic

Backends are swappable through interfaces.

credentials/

Credential infrastructure for installed app packages.

Responsibilities:

Encrypted app-scoped credential storage
Injection-only outbound request execution
Direct-to-vault OAuth token brokerage
Namespace purge for package removal and lifecycle cleanup

This package stays in the autonomic layer because apps never receive plaintext credential material; higher layers consume the credential seams only through shared interfaces.

embeddings/

Embedding model abstraction.

Responsibilities:

Generate vector embeddings
Support local or remote embedding providers
Provide retrieval query interface

Does not know what the vectors are for. Generates them on request.

runtime/

Environment and OS abstraction.

Responsibilities:

Cross-platform path handling
Environment configuration
System-level capability mediation

No direct filesystem access should occur outside this layer.

config/

Configuration schema and validation.

Responsibilities:

Cortex mode presets (tiers 0–5)
Model role assignments
Profile definitions (local-control, local-all, remote-all)
Validation and defaults

health/

System monitoring and maintenance.

Responsibilities:

Health diagnostics
Log management
Garbage collection
Maintenance scheduling
Backup coordination

You only notice the autonomic layer when it fails.

self/shared/ — Cross-Layer Nervous System

Shared types, interface contracts, event schemas, and error definitions used across all layers.

self/shared/
├── types/                            # Shared type definitions
├── interfaces/                       # Cross-layer interface contracts
├── events/                           # Event schemas
└── errors/                           # Error types

types/

Shared type definitions. Memory entry types, project types, model role types, governance levels, etc.

Phase 7.2 package-contract additions live here:

package-manifest.ts — package identity/provenance/trust/compatibility schema
package-lifecycle.ts — lifecycle event and reason-code contracts
package-compatibility.ts — API range and capability-delta gate contracts

Phase 9.1 adds:

workflow.ts — canonical workflow definition, derived graph, admission, run-state, and dispatch-lineage schemas

Phase 9.3 adds:

scheduler.ts — canonical schedule definitions, trigger variants, workmode binding, and due-cursor state
artifacts.ts — versioned artifact write/read/delete/list contracts, integrity refs, and lineage
ingress-trigger.ts / ingress-outcome.ts expansions for explicit workmode_id, duplicate return linkage, and workflow-admission rejection posture

Phase 9.4 and Phase 9.5 add:

knowledge-index.ts — canonical project discovery, refresh, taxonomy, and relationship-runtime contracts
workflow-monitoring.ts — workflow-surface snapshot, node projection, diagnostics, validation, and save-input schemas used by the Projects UI and web server

Phase 11.4 expands:

workflow-monitoring.ts — stage projections, canvas-node and canvas-edge overlays, checkpoint and scheduler debug summaries, node inspect payloads, and visual-debug snapshots used by the advanced Projects surface

Phase 11.5 expands:

project-surface.ts — mobile operations snapshot, aggregated continuity, and phone-sized projection contracts
escalation.ts — acknowledgement summaries reused across Chat, Projects, and mobile operations
voice-control.ts — additive mobile follow-up projection reuse over canonical continuation and degraded-mode posture
endpoint-trust.ts — project-level trust summary projections surfaced into mobile continuity views
mao.ts — continuity link metadata reused by cross-surface handoff helpers

Phase 12.1 adds:

agent-gateway.ts — canonical AgentInput / AgentResult contracts, gateway budgets, correlation snapshots, typed inbox/outbox payloads, lifecycle-hook request shapes, and summary-oriented run snapshots for the internal runtime harness

Phase 13.1 adds:

public-mcp.ts — canonical public MCP discovery, admission, JSON-RPC, namespace, mapping, audit, and normalized execution-request contracts used at the machine-facing boundary

Phase 9.7 adds:

mao.ts — density-grid, run-graph, inspect, urgent-overlay, reasoning-preview, and project-control contracts used by MAO and linked surfaces

Phase 11.3 adds:

voice-control.ts — canonical voice turn, signal-bundle, interruption, continuation, degraded-mode, confirmation, and session-projection contracts
additive voice_projection support in mao.ts so operator surfaces can read canonical voice session posture without inventing local state

Phase 10.1 adds:

registry.ts — canonical registry package, release, maintainer, moderation, governance, appeal, metadata-validation, and install-eligibility contracts
nudge.ts — canonical nudge signal, candidate, decision, and feedback object contracts required by Phase 10.2 consumers

Phase 10.2 expands:

nudge.ts — ranking-policy, suppression, delivery, feedback-record, and acceptance-routing contracts used by the advisory discovery runtime and later delivery surfaces

Phase 14.1 adds:

package-manifest.ts — canonical package-type normalization, including legacy project to canonical workflow ingress compatibility
app-permissions.ts / app-manifest.ts — shared app permissions, tools, panels, adapters, lifecycle, and install-validation contracts
package-store.ts — canonical five-root store layout and discovery snapshot contracts for .apps/, .skills/, .workflows/, .projects/, and .contracts/

Phase 14.3 adds:

package-documents.ts — canonical schemas for atomic and composite skill package documents, workflow package documents (manifest, flow graph, and step files), loaded package views, project workflow package bindings (ProjectWorkflowPackageBindingSchema), and resolved workflow-definition source metadata (ResolvedWorkflowDefinitionSourceSchema) for debug and monitoring surfaces.

Phase 14.4 adds:

workflow-lifecycle.ts — canonical request/response schemas for Internal MCP workflow lifecycle list, inspect, start, status, pause, resume, and cancel operations, including mutation-result evidence and warning projections.

Phase 14.6 adds:

app-credentials.ts — canonical schemas for app-scoped credential storage, injection requests, revoke flows, OAuth brokerage, and purge summaries
additive connector registration and session projections in communication-gateway.ts
additive credential-setup fields in package-resolution.ts so install-time vault provisioning stays lifecycle-owned

Phase 9.6 adds:

project-surface.ts — canonical project dashboard, configuration snapshot, blocked-action, health-summary, and field-provenance schemas
project.ts expansions for governance defaults, escalation preferences, and package-default intake provenance
escalation.ts in-app escalation queue, acknowledgement, and queue snapshot contracts
scheduler.ts schedule upsert inputs used by the Projects operating surface

interfaces/

Cross-layer contracts. When the cortex calls the subcortex, or memory calls storage, the contract is defined here. No layer imports directly from another layer's implementation.

This is the critical composability mechanism. Layers depend on interfaces, not implementations.

Phase 7.2 adds:

project-api.ts — canonical seven-surface Project API membrane contract for package runtime mediation

Phase 9.1 expands:

subcortex.ts — workflow engine interfaces for definition resolution, graph derivation, admission, run progression, and state retrieval

Phase 9.3 further expands:

subcortex.ts — scheduler and artifact request/result contracts, plus workflow start trigger provenance
project-api.ts — project-scoped artifact request/result contracts and scheduler binding surfaces
ingress.ts — callable ingress gateway and reservation-based idempotency interfaces

Phase 9.5 further expands:

subcortex.ts — workflow-runtime list/graph retrieval surfaces used by the Projects monitoring projection

Phase 9.6 further expands:

subcortex.ts — scheduler upsert/get and escalation get/listProjectQueue/acknowledge interfaces used by the Projects and chat operating surfaces

Phase 9.7 further expands:

subcortex.ts — IMaoProjectionService snapshot, inspect, graph, and project-control methods used by the MAO surface and web server

Phase 12.1 further expands:

agent-gateway.ts — IAgentGateway, IAgentGatewayFactory, IScopedMcpToolSurface, lifecycle-hook seams, write-only inbox handles, and emit-only outbox sinks used by the new internal runtime harness

Phase 13.1 further expands:

subcortex.ts — IPublicMcpGatewayService for discovery metadata, admission, visible-tool listing, and guarded execution across the public MCP edge

Phase 11.3 further expands:

subcortex.ts — IVoiceControlService methods for turn start, evaluation, assistant-output registration, barge-in handling, continuation resolution, and session projection reads

Phase 10.1 further expands:

subcortex.ts — IRegistryService submission, metadata validation, install-eligibility, governance, maintainer, and appeal interfaces used by the registry runtime and lifecycle consumers

Phase 10.2 further expands:

subcortex.ts — INudgeDiscoveryService signal intake, candidate generation, ranking, suppression, delivery, feedback, and advisory acceptance-routing interfaces used by the nudge runtime and later surface projections

Phase 14.3 further expands:

subcortex.ts — resolveDefinitionSource on IWorkflowEngine for resolving whether a project's active workflow definition originates from an inline project-authored source or an installed workflow package binding, returning ResolvedWorkflowDefinitionSourceSchema metadata for monitoring surfaces.

Phase 14.4 further expands:

subcortex.ts — IWorkflowEngine.cancel(...) so the Internal MCP workflow control surface can perform additive cancel transitions without moving workflow truth out of the canonical runtime.

events/

Event schemas for inter-layer communication. Standardized event structure for all system events.

errors/

Standardized error types. Consistent error handling across all layers.

shared/ contains no execution logic and no business logic. It is the type system and contract registry.

Dependency Rules

cortex/     → depends on interfaces in shared/
              → calls memory/ and subcortex/ through interfaces
              → never touches autonomic/ directly

memory/     → depends on interfaces in shared/
              → calls autonomic/ (storage, embeddings) through interfaces
              → never touches cortex/ or subcortex/ directly

subcortex/  → depends on interfaces in shared/
              → calls autonomic/ (storage, embeddings) through interfaces
              → called by cortex/ through interfaces
              → never calls cortex/ directly

autonomic/  → depends on interfaces in shared/
              → called by memory/ and subcortex/ through interfaces
              → never touches cortex/
              → never initiates upward communication

shared/     → no dependencies on any layer
              → no execution logic

apps/       → depends on shared/ interfaces
              → communicates with the system through cortex/
              → never reaches into subcortex/ or autonomic/ directly

Processing flows down. Results flow up. Authority flows from the cortex. No layer reaches upward to command a layer above it.

Implementation Priority

Bottom-up stability. Build the foundation before the intelligence.

shared/ — types, interfaces, contracts
autonomic/config/ — configuration schema
autonomic/storage/ — persistence backends
autonomic/runtime/ — OS abstraction
autonomic/embeddings/ — embedding generation
subcortex/providers/ — model adapters
subcortex/router/ — model routing
subcortex/tools/ — tool execution
subcortex/projects/ — project containers
memory/stm/ — short-term memory
memory/ltm/ — long-term memory
memory/access/ — access policy engine
memory/retrieval/ — retrieval orchestration
cortex/Cortex/ — Prefrontal Cortex engine
cortex/core/ — central executive loop
self/apps/cli/ — terminal interface
memory/distillation/ — pattern compression
memory/knowledge-index/ — cross-project intelligence
subcortex/workflows/ — workflow graph engine
subcortex/artifacts/ — artifact management
subcortex/scheduler/ — scheduled execution
subcortex/escalation/ — Principal notification
self/apps/web/ — web UI
self/apps/bridge/ — messaging integrations
autonomic/health/ — monitoring and maintenance

Future Expansion

This structure accommodates future additions without restructuring:

self/subcortex/
├── skills/                           # Skill SDK and runtime
└── policy/                           # Advanced policy engine

self/apps/
└── mobile/                           # Native mobile application

New capabilities are added within the layer they belong to. The structure scales with the system.

This folder structure embodies the Mind Model. It is the architectural boundary between what Nous is and what exists around Nous.

All development must respect these layer boundaries and dependency rules.

Repository Folder Structure

On this page