Capability Authoring & Activation
Relevant source files
The following files were used as context for generating this wiki page:
Capability Authoring & Activation represents the core mechanism by which Noesis evolves its internal intelligence and tools. It allows the system to reflect on user interactions, identify potential improvements (learning signals), and author coupled revisions to its prompt modules, skills, and tools. These revisions are then subjected to rigorous evaluation via a "preflight" process before being atomically activated within the runtime. Sources: plans/noesis-autonomous-compounding-implementation-plan.html:105-115, AGENTS.md:5-15
The system ensures that self-modification remains safe by separating the authoring of candidates (handled by LLM reflection) from the authority to activate them (handled by the Protected Control Plane). Every activation is evidence-linked, meaning it must cite specific historical evidence or corrections that justify the change. Sources: AGENTS.md:25-30, plans/noesis-high-leverage-correction-plan.html:420-435
Architectural Overview
The capability lifecycle is structured as an autonomous loop that moves from signal detection to permanent activation or restoration.
The diagram shows the transition from raw learning signals to the final disposition of an active capability revision. Sources: plans/noesis-autonomous-compounding-implementation-plan.html:560-575, plans/compounding-partnership-product-loop.html:435-445
Key Components
| Component | Responsibility | Source |
|---|---|---|
| Reflector | Analyzes signals to form hypotheses and experiment briefs. | plans/noesis-autonomous-compounding-implementation-plan.html:645-650 |
| Revision Author | Generates concrete prompt modules, skill definitions, and tool code. | plans/noesis-autonomous-compounding-implementation-plan.html:650-655 |
| Preflight Lab | Executes paired baseline vs. candidate trials using blinded judges. | plans/noesis-autonomous-compounding-implementation-plan.html:635-645 |
| Atomic Controller | Manages the transactional staging and commitment of active definitions. | packages/runtime/src/atomic-activation.ts:100-115 |
| Effect Gateway | Authorizes dangerous external effects requested by new capabilities. | AGENTS.md:38-42 |
Capability Revisions
A CapabilityRevision is a coupled bundle of definitions that represent a single unit of behavior. This bundle includes prompts, skills, tools, and a specific toolset/router configuration. To maintain integrity, all revisions are stored as immutable, byte-stable snapshots. Sources: packages/runtime/src/atomic-activation.ts:135-150, AGENTS.md:20-24
Revision Materialization
Before a revision can be activated, the system materializes its complete definition slots. This process involves verifying that every component (prompts, skills, tools, and routers) is present and uniquely identified by content digests. Sources: packages/runtime/src/atomic-activation.ts:160-185
Structure of a Capability Revision as defined in the system. Sources: plans/noesis-autonomous-compounding-implementation-plan.html:360-380, packages/runtime/src/atomic-activation.ts:160-180
The Atomic Activation Process
Activation is performed via the AtomicActivationController. The process is transactional: the system stages stable active-revision bytes and then atomically updates the SQLite activation pointer. Sources: packages/runtime/src/atomic-activation.ts:400-435, plans/noesis-high-leverage-correction-plan.html:335-345
Preflight Validation
Activation requires a valid PreflightReport. The controller validates several criteria before allowing a commit:
- Identity Bound: Ensures all references in the experiment, preflight, and manifest match the candidate revision.
- Scope Bound: Verifies the candidate's capability ID and activation scope match the baseline.
- Rails Check: Confirms all protected rails (security, authority, performance) have passed.
- Control Validation: Ensures existing pins or vetoes are respected.
Sources: packages/runtime/src/atomic-activation.ts:210-280
Activation Outcomes
The activateFromPreflight function returns one of the following states:
- activated: The revision is now live and will be served to subsequent turns.
- pending_approval: The revision requires explicit user approval (e.g., due to authority expansion).
- blocked: The revision failed policy checks or preflight rails.
- rejected: The revision was explicitly denied during the approval phase.
Sources: packages/runtime/src/atomic-activation.ts:60-85
Serving Capabilities in the Runtime
Once activated, a capability is served according to its Activation Pin. The TurnIntelligencePlanner resolve active revisions into a FrozenTurnPlan before model execution. Sources: packages/runtime/test/turn-intelligence.test.ts:100-115, plans/noesis-high-leverage-correction-plan.html:180-195
Context Compilation
When a turn is admitted, the runtime freezes the selected definitions:
- Prompt Pining: The exact byte-digest of the prompt module is used to ensure identity.
- Tool Isolation: Only the tool revisions registered in the frozen plan are available.
- Retrieval Citations: Any historical context retrieved must cite authoritative SQLite rows or file revisions.
Sources: AGENTS.md:20-24, packages/runtime/test/turn-intelligence.test.ts:145-160
The sequence of pinning and serving capabilities for a specific user turn. Sources: packages/runtime/test/turn-intelligence.test.ts:130-160, plans/compounding-partnership-product-loop.html:435-450
Autonomy and Risk Policy
Activation is governed by an ActivationAutonomyPolicy. This policy determines the level of automaticity allowed based on the risk associated with the change. Sources: packages/runtime/src/atomic-activation.ts:50-58, plans/noesis-autonomous-compounding-implementation-plan.html:815-835
| Risk Level | Default Action | Restriction |
|---|---|---|
| Low Risk | Auto-activate after preflight. | Limited to read-only skills or internal prompt modules. |
| Medium Risk | Approval Required. | Generated code within existing effect limits. |
| High Risk | Explicit User Action. | Changes to credentials, network access, or external effects. |
| System Kernel | Blocked. | Self-modification of the protected kernel or authority rules is forbidden. |
Sources: plans/noesis-autonomous-compounding-implementation-plan.html:815-840, packages/runtime/src/atomic-activation.ts:350-370
Authority Receipts
For modifications involving protected state, the system requires an AuthorityReceipt. The deep protected adapter verifies the issuer, effect, resource, and operation before committing any mutation. Sources: plans/noesis-high-leverage-correction-plan.html:420-435, AGENTS.md:38-42
Conclusion
Capability Authoring & Activation creates a self-improving intelligence loop grounded in evidence. By combining LLM-driven authoring with a deterministic, transactional activation process, Noesis ensures that every adaptation is both measurable in its impact and reversible in the event of failure. The use of frozen plans and immutable snapshots guarantees that the behavior observed during evaluation is identical to the behavior served in production. Sources: plans/compounding-partnership-product-loop.html:775-790, plans/noesis-high-leverage-correction-plan.html:470-485