CodeSentinel: A SEAM-Governed Development, Security, and Intelligence Platform

1Introduction and Prior Art

CodeSentinel is a cross-platform maintenance, security-monitoring, and development-governance platform. It integrates command-line control, scheduled maintenance, repository diagnostics, configuration checks, commit- and gate-time credential scanning, file-integrity verification, alert routing, repository hygiene, tiered memory, policy evaluation, and evidence retention within a unified operational architecture.

The platform treats repository state as a governed data stream. Observations enter through scanners, process monitors, integrity checks, and development audits; policy and intelligence layers classify those observations; authorized execution surfaces apply maintenance or remediation; audit and memory systems retain the resulting evidence. This closed-loop structure supports reproducible diagnosis and longitudinal analysis of repository health.

The system builds on familiar prior-art categories: repository maintenance automation, configuration and credential scanning, integrity baselines, scheduled operations, audit logging, and policy-driven development workflows. CodeSentinel combines those categories under the SEAM contract, coordinating security, efficiency, awareness, and minimalism as one operating system. ORACL adds historical context and evidence continuity, while CIDS supplies the embedded security control plane.

2Distribution and Technical Lineage

CodeSentinel has three evidence surfaces rather than one primary version. Package metadata defines the externally reproducible PyPI surface, the public repository defines the most advanced public-source surface, and the active development line defines unpublished integration evidence. A capability inherits no feature or status from another surface.

2.1Package identity

The codesentinel package is published on PyPI at 1.1.1 with 12 observed top-level commands. The public joediggidyyy/CodeSentinel tree reaches 1.1.3.b1 + hotfix2 while retaining the same version string. Both are lean core releases: neither contains CIDS, the governance/evidence command cluster, the CaSTaP adapter, ORACode/ORACall, or full ORACL. PyPI release metadata and downloadable artifacts identify the package version; the README badge is stale and is not release identity.

2.2Active source architecture

The active source architecture, versioned 1.1.5 in package metadata, integrates ORACL memory and evidence flows, CIDS, policy and job-state controls, validation surfaces, and extended reporting infrastructure. This surface is not publicly downloadable. Its capabilities are included only where runtime observation, retained evidence, or operator confirmation establishes their status. [A1]

Availability

PyPI public package   GH public source  
DEV unpublished development line

Evidence status

LIVE active use   IMPL functional when invoked   PARTIAL incomplete integration   PLANNED specified, not built   UNRESOLVED conflicting or insufficient evidence

TABLE 1 · Distribution and architecture surfaces

Availability	Version	Evidence role	Status
PyPI	1.1.1	Downloadable 12-command core baseline	IMPL
GH	1.1.3.b1 + hotfix2	Most advanced public-source baseline; lean package tree	IMPL
DEV	1.1.5	Unpublished governance, full ORACL/ORACode, CaSTaP, and CIDS integration evidence	IMPL

3Platform Composition and Controlled Execution

The application contract is exposed through the command-line interface and a Python orchestration object. In the active development line, CodeSentinel composes configuration, alert routing, SessionMemory, the cadence scheduler, lazy DevAudit access, and a permanent process monitor. Construction starts the monitor when enabled; shutdown hooks persist memory and stop monitoring. The scheduler is composed but does not become active merely because the object exists. A 2026-07-17 runtime status probe reported loaded configuration, operational OK, and an inactive scheduler. [A2]

3.1Composition and lifecycle

Repository diagnostics, integrity state, process observations, and retained operational context enter the loop as evidence. Policy and authority gates decide whether an action may proceed; observations and ORACL advice do not authorize mutation. Approved actions execute through bounded CLI or Python surfaces, and their outputs return to logs, manifests, SessionMemory, or reports. If the process monitor cannot start, the core retains a degraded None monitor state and emits a warning rather than claiming supervision. Sections 5 through 7 separate autonomous runtime, governance authority, and ORACL advice; Section 8 begins the independent CIDS enforcement boundary.

3.2Control surfaces and recoverable mutation

The public releases provide a smaller core CLI, while the development line exposes 50 top-level commands grouped by operational role. [A18][A19] Command registration is not capability evidence; each report claim follows observed behavior. The Python object returns structured status, scan, maintenance, and DevAudit results. Development-line safe-edit and filesystem controls classify targets, stage changes, prefer archival to deletion, and preserve finalize or rollback evidence. Their selected runtime tests passed 29/29 on 2026-07-17. [A9]

TABLE 2 · Runtime and evidence surfaces

Surface	Availability	Authority and runtime role	Evidence product	Status
Command-line interface	PyPI GH DEV	Operator-triggered control surface; public and development inventories differ	Exit status, structured output, logs, and command-specific artifacts	IMPL
Python orchestration object	PyPI GH DEV	Composes configuration, alerts, memory, scheduler, DevAudit, and process supervision	Structured dictionaries plus subsystem logs and retained state	IMPL
Safe edit and governed filesystem	DEV	Policy-gated mutation with target classification and archive-first handling	Staged content, verification result, archive manifest, finalize or rollback record	IMPL
Process-monitor composition	DEV	Constructor-started child tracking and cleanup when enabled	Monitor status and bounded cleanup history	IMPL
SessionMemory handoff	DEV	Persists context at shutdown; it advises but does not authorize mutation	Session state and continuity records	IMPL

4Security, Active Integrity, and Credential Custody

CodeSentinel holds several distinct kinds of protected state, each with its own authority, verification method, and recovery path. Scanning surfaces inspect the repository and its configuration and route findings into evidence; four protected-state domains hold integrity over repository files, the operations task SSOT, the credential VAULT, and the managed execution environment.

4.1Scanning surfaces

Three scanning surfaces operate at distinct points in the workflow. Built-in scan PARTIAL routes repository diagnostics through the CLI — bloat analysis, configuration checks, and structured findings — delivering diagnostic and configuration auditing. Dependency-vulnerability and code-security analysis are explicit placeholders. DevAudit IMPL runs a development audit on invocation; a direct 1.1.5 run completes cleanly and returns structured audit findings.

Four protected-state domains carry integrity, each with its own baseline, transition rules, and recovery path.

4.2Repository integrity

A bounded SHA-256 baseline records the repository's trusted state. Exclusion patterns keep transient trees — caches, environments, logs, and archives — outside the baseline, a whitelist admits approved additions, and a critical-file policy marks paths that must hold constant. Baseline generation carries a file-count safety cap that keeps a scan bounded.

Verification walks the workspace against the baseline and classifies every deviation — modified, missing, unauthorized-new, and critical-file violation — at graded severity, then returns structured statistics (files checked, passed, modified, missing, unauthorized, and critical) alongside a security-event record for each violation. The monitor advances through explicit generate, verify, report, reset, and rebaseline states, and a live baseline holds in the observed workspace as of 2026-07-17. It governs repository files and operates independently of the CIDS integrity mechanisms. [A3][A5]

The graded outcomes carry the section's operative distinction. A modified file and an unauthorized addition both break the baseline, and they mean different things: one records drift in known content, the other records content that entered the workspace outside the whitelist. Critical-path violations sit at the top of that ramp because the policy marks those paths as constants. The severity classification is what converts a hash comparison into an actionable security record.

4.3Operations-task SSOT integrity

Canonicalized SHA-256 hashing seals operations/tasks.json against an integrity sidecar held beside it. Verification returns one of three states: a match confirms the SSOT, an absent task file or sidecar reports a not-yet-initialized baseline, and a hash mismatch is a hard failure that signals an out-of-band edit. Every authorized mutation passes a guarded atomic write that refreshes the sidecar under a recorded author, and a forced rebaseline touches only the sidecar — never the task data — so the authoritative record stays intact while its baseline is re-established. Archive and restore manifests preserve task-artifact lineage across collision and rollback. The task SSOT is its own protected-state domain and stands in active operational use.

4.4VAULT custody and CaSTaP boundary

VAULT custody is layered. A checksum guardian computes a SHA-256 hash over the credential store and reports one of three integrity states — verified, uninitialized, or violated — so tampering surfaces on the next check. Every authorized edit is a deliberate act: it records a reason, an authorizer, and a UTC timestamp into a tamper-evident audit trail, then re-establishes the baseline under explicit lock and rebaseline. A bootstrap boundary confines exposure — credentials load once into the session environment, and operational code reads them only from environment variables, never from the store directly. Names-only environment-profile validation then confirms that a profile's required variables are present, by canonical name or approved alias, without surfacing a single value. This is integrity custody: it guarantees tamper detection and authorized-edit control, and it holds stored content under integrity protection rather than encryption at rest. [A6][A7]

Two transport-facing surfaces sit beyond the store, each carrying its own status. CaSTaP IMPL, the credential transport, is tested and fail-closed and awaits active wiring in 1.1.5; Section 11 specifies it. A development credential-operations CLI IMPL seals VAULT-held credentials into context-bound CaSTaP packets and recovers them only under matching context, failing closed on a context mismatch; a bounded end-to-end run confirms the full seal, inspect, and recover cycle. A no-key convenience path and payload re-serialization remain development concerns held for hardening.

4.5Managed environment and script trust

Canonical-environment enforcement binds execution to a registered environment identity through a registry and a manifest, so a mutable script runs only from a known, recorded environment. Script authorization, revocation, and hash verification gate which scripts may execute, a policy audit records the trust decisions, and archive-first pruning preserves recoverability in place of deletion. The authorization, verification, and revocation paths operate today. One environment-detection boundary — repository-marker classification of the canonical environment — carries PARTIAL and is tracked in Section 18. [A8][A10]

The four domains share a method and diverge in everything else. Each holds its own baseline, resolves failure on its own terms, and recovers through its own path.

TABLE 3 · Protected-state domains

Domain	Baseline	Verification outcome	Failure semantics	Recovery path	Status
Repository integrity	Bounded SHA-256 baseline under exclusion, whitelist, and critical-path policy	Five graded classes with structured statistics	Graded severity per violation class	Reset to a new baseline, or explicit rebaseline	LIVE
Operations-task SSOT	Canonicalized hash held in an integrity sidecar	Match, not-yet-initialized, or hash mismatch	Mismatch is a hard failure signalling an out-of-band edit	Sidecar-only rebaseline preserving task data	LIVE
VAULT custody	Checksum over the credential store	Verified, uninitialized, or violated	Tamper surfaces on the next check	Authorized edit under recorded reason, authorizer, and UTC timestamp, then lock and rebaseline	LIVE
Managed environment and script trust	Registry and manifest binding execution to a registered environment identity	Authorization, revocation, and hash verification outcomes	Unregistered scripts stop at the gate; one detection boundary carries PARTIAL	Archive-first pruning preserving recoverability	PARTIAL

Together these surfaces hold CodeSentinel's protected state under verifiable, recoverable custody.

5Autonomous Operations and Runtime Supervision

CodeSentinel's maintenance and supervision layer runs as a governed runtime surface. The public package exposes the core maintenance and alert entry points; the development line carries the full scheduler, monitor, watchdog, posture, inactivity, and retention surfaces. The scheduler dispatches preconfigured task categories under policy and mode gates, the monitor and watchdog keep execution bounded, and alerts record evidence without taking authority.

5.1Coordinated maintenance cadence

The primary cadence scheduler and the archive-maintenance scheduler move as separate but coordinated lifecycles. The primary scheduler dispatches daily, weekly, biweekly, and monthly work categories; it fails closed when scheduling support or runnable jobs are absent, honors companion start and stop coordination, retains last-run summaries, and reports inactive status instead of inventing liveness. The archive scheduler keeps its own task-state records and error backoff, and the uptime field remains a placeholder, so the report states activation and retained outcomes rather than a fabricated uptime value.

5.2Persistent and per-command supervision

The permanent process monitor tracks CodeSentinel child processes, detects parent loss, performs bounded terminate-or-force-kill cleanup, checks for zombies where supported, and keeps a bounded cleanup history. The command watchdog wraps a single command, enforces a timeout, attempts process-tree termination, captures output, and returns an explicit timeout/result state. These surfaces stay separate from the CIDS lane watchdogs and from gate-worker cleanup.

Four supervision lifecycles run across the platform, and each answers a different question about a different span of time.

TABLE 4 · Supervision lifecycles

Lifecycle	Scope	Duration	Trigger	Failure semantics	Evidence
Permanent process monitor	CodeSentinel child processes	Spans the session	Parent loss or zombie detection	Bounded terminate, then force kill	Bounded cleanup history
Per-command watchdog	One wrapped command	Spans one invocation	Timeout expiry	Process-tree termination with explicit timeout state	Captured output and result state
Gate workers	One lifecycle gate	Spans one gate evaluation	Gate completion	Teardown after gate behavior concludes; two Windows paths carry PARTIAL	Gate outcome record
CIDS lane watchdogs	Internal and external Sentry lanes on the Edge node	Continuous under systemd	Health probe failure	Bounded restart attempts, then escalation	JSONL telemetry, dated 2025-12-11

5.3Automation safety and evidence envelope

Mode posture gates unattended hooks: manual posture blocks them, while agent and auto posture permit them without creating task authority. Inactivity freeze and thaw pause state under snapshot-bound trip and refractory controls, and thaw resumes only when the snapshot and mode match. Automation retention records invoked work as a manifest plus append-only index, while alerts stay in the evidence lane: console and file delivery work, the file timestamp defect is repaired, Slack URL validation rejects unsafe destinations, and external email and Slack delivery remain unobserved.

The guard on the thaw edge is what makes the freeze protective. Resuming requires the environment to match the conditions captured when the freeze tripped, so a surface that changed underneath a paused operation stays paused until an operator resolves the difference. The refractory window then prevents an immediate re-trip from converting a single inactivity event into a cycle.

The current 2026-07-17 regression batch passes 20/20 across scheduler guardrails and status, process monitoring, command watchdog behavior, inactivity persistence fallback, and repaired file-alert timestamps. That batch reinforces the section contract without widening it: the scheduler dispatches work, the monitor and watchdog supervise execution, and alerting records evidence. [A11][A12]

6Governance, Job State, and Evidence Production

Work inside CodeSentinel passes through an explicit authority structure. Policy and lifecycle gates constrain what may proceed, a canonical task record holds the sole authority to change job state, a continuity layer preserves session and campaign context across time, and a family of derived views renders that state as evidence. Each layer holds a distinct authority, and the boundaries between them are load-bearing: exactly one of them writes lifecycle state.

The figure's decisive feature is the count of solid edges entering the canonical record: one. Gates decide whether work proceeds and the record decides what the state becomes, which keeps a blocked gate from silently leaving a job half-transitioned. Everything below the record reads from it, so a dashboard or a stored campaign frame can go stale and be corrected by regeneration rather than by reconciliation between competing sources of truth.

6.1Policy enforcement and lifecycle gates

A policy layer resolves the rules that apply to a request and routes evaluation to the responsible guard. Guards evaluate remediation first: where a condition is correctable, the layer offers the correction before it reaches a hard outcome, and enforcement applies where correction is unavailable or declined. A gate sequence then binds the working day — preflight, beginning-of-day, pre-job, post-job, repair, and end-of-day — with each gate positioned at a point where authorized work begins or concludes. [A13]

Gates permit work, block it, or record a degraded override under explicit authority, and every outcome is retained as evidence. Authority to change a job's lifecycle state stays with the canonical task record described in 6.2; a gate constrains whether work proceeds and leaves the state transition to that record. Retained policy events carry provider-qualified assurance, and the distinction is material: a raw SHA-256 value is an integrity digest, local HMAC and simulated key-management signing are separate modes with their own trust properties, and externally backed key-management assurance holds only where a configured provider supplies it. [1][2] Gate-worker cleanup carries PARTIAL on two Windows teardown paths that run after the gate's own behavior completes; Section 18 tracks them. These gate workers stay distinct from the permanent process monitor and per-command watchdog of Section 5 and from the CIDS lane watchdogs of Section 9. [A14][A15]

6.2Canonical job and task state

The operations task record is the single mutation authority for job lifecycle state. Create, classify, start, block, hold, resume, close, archive, and restore transitions all resolve to it, and each passes through a guarded atomic write that leaves the record consistent under interruption. Integrity verification seals the result against the sidecar baseline described in Section 4, so an out-of-band edit surfaces on the next check rather than propagating silently.

Around that authority sit supporting mechanics: deterministic lead selection resolves ownership without ambiguity, artifact lineage ties produced evidence back to the work that generated it, dry-run prediction reports the transition a request would perform before it performs one, and campaign linking connects a job to the continuity structures of 6.3. The canonical surface wraps older internals where lineage requires it, and authority remains undivided — the superseded job surface is a compatibility path rather than a second source of state. Focused lifecycle, integrity, discovery, archive, restore, and linkage coverage passes 106 of 106 checks, and the pipeline stands in active operational use. [A4]

TABLE 5 · Lifecycle transitions

Transition	Trigger class	Authority	Evidence produced	Reversible
create	Work intake	Operator or authorized agent	Task record with canonical identifier	Yes, through archive
classify	Triage	Operator or authorized agent	Classification field and audit entry	Yes, by reclassification
start	Gate-cleared execution	Task record under gate clearance	Start record and lead assignment	Yes, through hold
block	Dependency or gate outcome	Task record under gate outcome	Block record with reason	Yes, through resume
hold	Operator decision	Operator	Hold record with reason	Yes, through resume
resume	Condition cleared	Operator or authorized agent	Resume record and prior-state link	Yes, through hold or block
close	Completion	Operator or authorized agent	Closure record and artifact lineage	Yes, through restore
archive	Retention policy	Task record	Archive manifest preserving lineage	Yes, through restore
restore	Recovery or reopening	Operator	Restore manifest with collision handling	Yes, through archive

Reversibility across the whole matrix is what makes the single-authority design safe to operate. Because archive and restore are themselves transitions with manifests, a closed or archived job remains recoverable through the same authority that closed it, and the lineage tying artifacts to the work that produced them survives the round trip.

6.3Session continuity and advisory state

Session memory and the campaign stack carry context across the boundaries where it would otherwise be lost. Every recorded event holds a canonical identifier and a link to the event preceding it, forming a journal whose head is verified on read, so the chain is tamper-evident and a break is detectable at the point of use. Primary and side frames separate a session's main line of work from its excursions, operations-awareness snapshots capture surrounding state at the moment of record, and temporal continuity plus manifest links let a later reader recover what was known and when.

The layer also holds advisory next-step state: it proposes what follows from the recorded context. That advice informs an operator or an agent and carries no authority to start, close, or otherwise transition a job, which remains with 6.2. Forty-one active journal, tamper-detection, execution, hydration, persistence, and diagnostic checks pass, and the operator confirms the pipeline in active use. Seven absent historical fixtures are fixture debt tracked in Section 18 and stand apart from current capability evidence. Section 7 carries the ORACL tier architecture, confidence flow, and promotion mechanics in depth; Section 5 owns inactivity freeze and thaw.

6.4Derived evidence and behavioral feedback

Dashboards, reports, snapshots, metrics, and completion telemetry are regenerated views over canonical state. Each is reproducible from the record it reads, which keeps the authoritative task data as the one place state lives and lets a stale view be corrected by regeneration. Display enrichment advances monotonically for readability within a rendered view and resolves back to the canonical record rather than writing to it.

Scoring itself is explicit rather than impressionistic. The platform maintains three continuous session scores in the unit interval — knowledge, compliance, and stability — each a weighted blend of observed telemetry. Stability combines guard state g, action success a, security-event continuity σ, and policy cleanliness π:

The policy term π is the design detail worth noting: violations v enter through a smooth inverse-square penalty rather than a threshold, so the score degrades continuously as violations accumulate instead of dropping through discrete steps. Compliance blends precedent s_p, semantic continuity s_s, operator clarity s_o, and automation health s_m, the last of these pairing a maintenance indicator m with stability itself:

Both blends carry weights summing to one, so each score stays in the unit interval and a reader can attribute movement to a named component. Knowledge takes a different shape — a weighted mean over four readings, with cache health r₁, policy state r₂, inter-cycle stability r₃, and session activity r₄ entering at relative weights 1, 2, 2, and 1:

The divergence penalty r_y is deliberately asymmetric. Measuring divergence as the previous knowledge score against current compliance, an over-confident system is corrected at full strength while an under-confident one is penalized at half, so knowledge can recover toward compliance instead of being held down:

That asymmetry is a feedback guard. Without it, a low knowledge score would depress stability, which feeds compliance, which would in turn hold knowledge down — a self-sustaining trough. Halving the penalty in the under-confident direction breaks the loop while leaving over-confidence to be arrested immediately, so drift is corrected faster than it accumulates. The activity term r₄ holds at one for the first four hours of a session and descends to zero by six, which keeps a long-idle session from reporting the confidence of an active one. Scores are advisory throughout: they describe a session's observed condition and inform prioritization, and authorization to act continues to come from the policy and gate layer of 6.1 and the task authority of 6.2.

Behavioral processing runs as an ordered sequence — ingest, score, dashboard, publish — where each stage advances on the success of the one before it. Publication here names the final stage of that pipeline, and the scores and feedback it produces are advisory: they inform prioritization and review, and authorization to act continues to come from the policy and gate layer of 6.1 and the task authority of 6.2. Documentation and evidence indexing, which resolves manifests through a registry and persists bidirectional links, is catalogued in Appendix B and Appendix E. [A22][A23]

7ORACL: Memory, Orchestration, and Advisory Intelligence

ORACL is CodeSentinel's resident memory and evidence layer. It organizes short-term session state, mid-term context summaries, and long-horizon patterns under a controlled promotion flow, indexes that memory so its evidence remains navigable, and returns advice grounded in what it has recorded. Session memory runs on every CodeSentinel surface; the deeper indexing, lineage, and advisory apparatus belongs to the development line. [A24]

7.1Tier model and promotion semantics

The tier model partitions memory by temporal horizon and retrieval cost. The Session Tier holds active context for immediate operations — the working task stack, cached file context, recorded decisions, and point-in-time operational and policy snapshots — under a bounded time-to-live that keeps the latency-sensitive tier small. The Context Tier retains compact summaries for cross-session continuity, written as dated records under a fixed retention lifetime and aged out on a defined schedule. The Intelligence Tier preserves long-horizon patterns and recurring structure.

Promotion is unidirectional and non-blocking: a record moves outward from session to context to long-horizon retention as its immediate relevance decays, and it never travels back inward to reappear as active state. That direction is what keeps the tiers honest — recall reaches back through the index rather than by reviving expired context, so a summary can inform a decision without impersonating current state. The confidence attached to a record travels with it, so a promoted summary carries the strength of the evidence behind it rather than acquiring authority through age.

Residency follows directly from record age. Writing a(r) for the age of record r, and T_s and T_c for the session and context retention bounds:

Promotion to the long-horizon tier applies a confidence ladder rather than age alone. A candidate pattern is scored on the consistency of its observed outcomes and the size of its sample. For an action observed n times with success rate s:

The consistency term in (6) rewards distance from an even split in either direction, so a reliably unsuccessful approach scores as highly as a reliably successful one — both are decisive evidence, and both are worth retaining. Equation (7) makes that explicit by discarding the ambiguous middle band entirely and requiring a minimum sample before any pattern is eligible. Long-horizon enrichment along this path is PARTIAL: the scoring and gate are implemented, while the pipeline that carries promoted patterns into the archive retains development scaffolding.

The figure's organizing relation is the separation between where memory lives and how it is found. Each tier holds records at its own horizon, and a single index spans all three, so retrieval cost stays proportional to the question rather than to the age of the answer.

7.2Index, confidence, and evidence lineage

ORACL couples tiered memory with centralized indexing to recover intent, recent decisions, historical patterns, and their supporting evidence. A link index maintains routable references across records and exports its state for inspection, while a manifest registry resolves documents by source, dataset, and subject so a stored conclusion can be traced to the material that produced it. Together they make lineage a lookup rather than a reconstruction.

Confidence travels with evidence through that index. A record carries the provenance of its supporting material, and a retrieval returns both the answer and the path back to its source, so a reader can judge the strength of a claim by following its lineage rather than by trusting its position in the store.

Recommendations drawn from historical cases carry their own score, computed over a set S of similar prior cases with success rate s, where Δd is the age in days of the most recent case:

Equation (8) governs advice rather than promotion, and it weights three properties a reader would otherwise have to infer: how much evidence exists, how decisive that evidence is, and how recent it is. Recency decays linearly to zero across a ninety-day window, so a recommendation resting on stale precedent reports lower confidence without being withheld. The consistency term is shared with (6), which keeps a single notion of decisiveness across both the promotion ladder and the advisory path.

TABLE 6 · ORACL tiers and evidence roles

Layer	Primary role	Analytical role
Session Tier	Active task context and immediate cache	Supports reconstruction of in-flight decisions
Context Tier	Recent summaries and cross-session continuity	Preserves local history through compact indexed records
Intelligence Tier	Long-horizon patterns and historical structure	Anchors recurring decisions and repository-wide memory
Central index	Lookup and routing across the tiers	Makes the evidence path explicit and navigable

7.3Journal integrity, expiry, and manifest links

The memory layer keeps an append-only event journal as its continuity record, and integrity rests on digests taken over the live structures it tracks — the task set, the working stack, the recorded decisions, and the cached file context. Because each exported state carries those digests alongside a session identifier and timestamp, a later reader can establish whether the memory they are reading is the memory that was written. The journal in the observed workspace holds tens of thousands of records as of 2026-07-18, and continuity spans months of dated context files.

Retention is explicit at both horizons. Session state expires under a bounded time-to-live, and context records age out under a fixed lifetime, so the store stays proportionate to its useful window and expiry is a scheduled property rather than a cleanup afterthought. Manifest links bind stored records to the documents and datasets that produced them, and archived context is retained separately from the active tier, which keeps historical material available for lineage while holding it out of current state. Section 5 owns inactivity freeze and thaw, and Section 6 owns the canonical job-state custody that this layer records against. [A20][A21]

The temporal view exposes what the structural model cannot: promotion is driven by age at the tier boundaries and by evidence strength at the long-horizon gate, so the two thresholds do different work. Age governs where a record lives, and confidence governs whether it becomes a durable pattern at all.

7.4Advisory surfaces and role separation

ORACL exposes its memory through three surfaces that differ by role rather than by feature. A recall surface answers questions about what the workspace knows, returning records and their lineage. An advisory surface composes recorded state into a proposed next step, delivered as a structured payload that names the frame, the task, the proposed action, and the source that justifies it — so the advice arrives with its own provenance attached. An agent-facing surface presents the same memory to automated callers under the platform's execution contract.

All three return evidence and proposals to the caller that asked for them. Authority to change lifecycle state stays with the canonical task record of Section 6, policy enforcement stays with the gate layer, and network response authority stays inside CIDS. That separation is what makes the advisory layer safe to consult freely: a proposal carries the weight of its evidence, and acting on it remains a separate, authorized decision.

TABLE 7 · Advisory surfaces by role

Surface	Question it answers	Returns	Confidence basis	Authority
Recall	What does the workspace already know?	Records with lineage back to source material	Provenance of the retrieved record	None — evidence only
Advisory	What follows from the current state?	Structured next-step payload naming frame, task, proposed action, and source	Equation (8) over comparable prior cases	None — proposal returned to the caller
Agent-facing	What context applies to this automated call?	The same memory under the platform execution contract	Inherited from the underlying record	None — bounded by the caller's own authority

8CIDS: Authority, Trust Boundaries, and Router Topology

CIDS — the Calamum Intrusion Detection System — is CodeSentinel's router-resident network security subsystem, and it holds an independent authority boundary: every consequential network-security decision for the protected network resolves inside CIDS. The subsystem owns device admission through its whitelist, active neutralization of unauthorized stations, the VPN killswitch, honeypot trap services, normalization of Sentry telemetry, and the CaSTaP transport that seals traffic between its nodes. This section establishes who decides, where enforcement executes, and which boundaries protect both; Sections 9 through 12 then treat each component plane at implementation depth. [A28][A29]

8.1Authority model and decision ownership

The authority model answers one question precisely: which component may decide, which may execute, and which may only observe or advise. Three tiers govern the design. The operator holds final authority for privileged response — lockdown, killswitch engagement, and whitelist policy change. CIDS holds autonomous enforcement authority within operator-set policy: its enforcement agent admits or neutralizes wireless stations against the whitelist at machine speed, without a human in the loop. Every other component — the Sentry lanes, the watchdogs, the EdgeGraph agent, SentryCortex, Sentry-Prime, and the dashboard — observes, transforms, supervises, or renders; none of them originates an enforcement decision. The authority map draws this contract in two edge classes: solid edges carry enforcement or control authority, and dotted edges carry telemetry, evidence, and advice, along which no authority travels.

The map's decisive relation is the vertical pairing at its center: policy flows down from the operator through the whitelist, and enforcement executes autonomously inside CIDS at machine speed. ORACL sits outside the enforcement boundary by design — it receives graduated events as evidence and returns advisory output, and the boundary between the two is a one-way authority wall documented in the consolidation and seam analyses. The authority matrix states that same contract component by component, with the evidence standing behind each claim. [A25]

TABLE 8 · CIDS authority matrix — decision ownership, execution surface, and evidence status

Component	Primary function	Decision authority	Execution surface	Evidence status
Operator	Final authority for privileged response and policy change	Authorizes lockdown, killswitch, whitelist policy	Console and CLI	Authority by design (governance contract)
CIDS enforcement agent	Wireless admission enforcement against the whitelist	Decides and executes autonomous neutralization	L2 deauthentication, L3 filtering	LIVE · operator-confirmed 2026-07
Sentry · internal lane	Host awareness, monologue, Cortex feed	None — observes and reports	Telemetry only	LIVE · operator-confirmed 2026-07
Sentry · external lane	External transport termination and validation	None — validates and forwards	Telemetry only	LIVE · operator-confirmed 2026-07
Watchdogs	Per-lane service supervision and recovery	Restart authority over supervised units	Service restart	LIVE · operator-confirmed 2026-07; 5/5 integration tests 2025-12
EdgeGraph agent	File, port, and neighbor integrity graph; drift detection	None — observes and reports	Telemetry only	LIVE · operator-confirmed 2026-07
SentryCortex	Semantic telemetry state and differential analysis	None — analyzes and stores	Local store	IMPL · runtime graph loads 2026-02
Sentry-Prime	Normalization, deduplication, correlation, forwarding	None — transforms and forwards	Relay pipeline	IMPL · tested, not active/wired in current 1.1.5
Dashboard	Operator surface: status, whitelist administration, monologue	Executes operator-authorized administration only	Authenticated console	IMPL · operationally tested, not active/wired in current 1.1.5
Guards	Honeypot traps, VPN killswitch, nexus integrity, recovery	Execute under CIDS and operator authority	Service actions	LIVE · operator-confirmed 2026-07; last killswitch mode record dated
ORACL	Cognitive analysis over graduated CIDS events	None — advisory output only	Advisory interface	Boundary documented · 2026-06

8.2Router-resident topology

CIDS executes on one enforcement host: the Edge node, which is the network's router (operator-confirmed, July 2026). The active host stack includes the enforcement agent that evaluates wireless station state against the whitelist, both Sentry daemons in separated internal and external lanes, a watchdog instance supervising each lane, the EdgeGraph integrity agent, and the guard set. The same host is the tested deployment target for the CIDS dashboard, and dated proof-of-life records show BRAIN and administrative satellite classes delivering CaSTaP-sealed telemetry to that surface. Both the dashboard and that transport path carry IMPL: operator-confirmed functional under test, inactive and unwired in working 1.1.5. The topology map therefore carries two layers at once — the active enforcement stack, and the separately labeled tested transport and dashboard path — so current operation and proven capability stay legible as distinct claims.

Concentrating enforcement on the router places authority at the network choke point: admission decisions execute where the medium is controlled, deauthentication acts at the access point, and filtering acts on the forwarding path. Lane separation isolates external transport faults from internal awareness, and a watchdog per lane keeps recovery local to the failure. Section 9 details the enforcement agent, the lane contracts, and the recovery plane; Section 10 follows the telemetry through Sentry-Prime, SentryCortex, and the EdgeGraph.

8.3Trust boundaries and transport ownership

Two boundaries structure trust. The enforcement boundary encloses the Edge node: admission, neutralization, killswitch, and trap authority never leave the router. The advisory boundary separates CIDS from ORACL: evidence crosses outward, advice returns, and enforcement authority never transfers. Transport ownership follows the same line: CIDS owns CaSTaP, the Calamum Secure Transfer Protocol that carries traffic between its own nodes. Holding the transport inside the subsystem is what makes the enforcement boundary enforceable rather than merely declared — the ingress a satellite reaches is one CIDS defines, seals, and validates, so admission to the telemetry path is itself a CIDS decision. Operator-confirmed testing across the local, BRAIN, and Edge node classes demonstrated fail-closed rejection of non-CaSTaP traffic, corroborating the December 2025 hardening record. CaSTaP is IMPL: functional and fail-closed under test, inactive and unwired in working 1.1.5. Section 11 specifies the transport lanes in full.

9Router Enforcement Agent, Dual Sentries, and Watchdog Recovery

Five processes implement the Edge-node enforcement and supervision plane: the enforcement daemon, two Sentry lanes in separate failure domains, and a watchdog paired to each lane. Their separation keeps enforcement authority in the daemon while allowing a lane fault to be recovered without touching the other lane or interrupting enforcement.

9.1Router enforcement and safety modes

The enforcement daemon is the router-resident process that executes the active-neutralization path on the Edge node. Implemented in cids_daemon.py, it observes wireless station state on a two-second cycle, evaluates each associated station against the whitelist, and applies two independent controls to an unauthorized station: a Layer 3 drop on its source address and a Layer 2 deauthentication at the access point. Each decision is retained as event evidence, which is what allows an admission outcome to be reconstructed after the fact rather than inferred from current state. [A30]

The whitelist is re-read at the top of every cycle, so authorization is evaluated against current policy rather than against policy as it stood when the daemon started. Writing the cycle as a relation over sets makes the daemon's behavior exact: for observation cycle k, with stations S_k and whitelist W_k, the Layer 3 drop set accumulates while the Layer 2 action set does not.

The two lines are the same predicate with different memory, and the difference is the design. D is persistent state: the daemon tests whether a drop rule already exists before inserting one, so re-observing the same station across cycles leaves the set unchanged. The union is idempotent, D is monotone, and the control converges instead of compounding into duplicate rules. A carries no memory at all — deauthentication is re-issued on every cycle in which the station is still present, because a deauthentication frame is an event rather than a rule and a station that re-associates must be ejected again. One control holds a boundary; the other repeatedly pushes against it, and a station that keeps returning meets both.

The cycle model below asks what happens to a single station between one observation and the next.

A second daemon, cids_daemon_optimized.py, implements the same observation and evaluation path with neutralization held behind a MONITOR_ONLY safety gate. It is a separately selectable build IMPL rather than a runtime toggle on the live daemon, so a deployment that needs detection without enforcement — a survey, a whitelist rehearsal, a shared medium where deauthentication would be inappropriate — selects it deliberately at install time. Sensing, whitelist evaluation, and evidence retention are unchanged in that mode; only the two enforcement controls are withheld. The active-neutralization daemon is the one running on the Edge node.

9.2Dual Sentry lane isolation

The two Sentry lanes are distinct service instances with their own role, configuration, telemetry stream, and failure domain. The internal lane owns host awareness, the monologue record, and the feed into SentryCortex. The external lane terminates external ingress, validates it, and forwards only what survives that validation. Because the lanes are separate instances rather than threads of one process, an external transport fault cannot degrade internal awareness, and the two telemetry streams stay attributable to their source lane.

Both lanes are operator-confirmed live as of 2026-07-16. Their role definitions and supervision wiring rest on a separate 2025-12-11 deployment record, and the two dates answer different questions: one establishes that the lanes are running, the other establishes what they were built to do. The deployed lane instances are the authoritative configuration — the repository carries a single non-templated base service, and the per-lane identity is established at deployment rather than in source.

9.3Watchdog recovery and the response-candidate boundary

Each lane is paired with its own watchdog, and that pairing is what keeps recovery local. A watchdog probes the health of one lane, and on a failed probe it attempts a bounded number of restarts of that lane alone, verifying health after each attempt before treating the recovery as complete. Attempts are bounded so a lane that cannot be restarted surfaces as a persistent fault rather than absorbing the node in a restart loop. Telemetry stays attributed to the lane that produced it throughout, so a recovery is reconstructable afterward: which lane failed, how many attempts it took, and whether the verification succeeded.

The tail of that sequence is where the authority boundary reasserts itself. A verified recovery produces a SentryCortex state differential and a dashboard event IMPL, and those artifacts constitute evidence and a response candidate. A candidate carries no power to act. Neutralization, lockdown, policy change, and escalation all remain behind the CIDS and operator gate established in Section 8, so the recovery plane can observe, restore, and report without ever acquiring the authority to respond.

An integration run on 2025-12-11 records 5/5 checks passing against these recovery paths. That result establishes that the paths work when exercised; recovery durations, attempt distributions, and failure-rate behavior would require a declared observation window, and Section 13 records that empirical surface as one still awaiting its data. [A34][A35]

TABLE 9 · Router enforcement and recovery role matrix

Component	Service or process	Lane or boundary	Primary responsibility	Evidence status
Router enforcement core	cids.service · cids_daemon.py	Edge node	Whitelist evaluation, Layer 3 source drop, Layer 2 deauthentication	LIVE · operator-confirmed 2026-07
Monitor-only variant	cids_daemon_optimized.py	Edge node	Same observation and evaluation path with neutralization withheld	IMPL · implemented safety mode, not the selected build
Internal Sentry lane	cids-sentry@internal.service	Internal telemetry lane	Awareness, monologue, Cortex feed	LIVE · operator-confirmed 2026-07; role recorded 2025-12-11
External Sentry lane	cids-sentry@external.service	External telemetry lane	Transport termination and validation	LIVE · operator-confirmed 2026-07; role recorded 2025-12-11
Internal watchdog	cids_sentry_watchdog@internal.service	Internal recovery lane	Health probe, bounded restart attempt, verified recovery	LIVE · operator-confirmed 2026-07; 5/5 integration checks 2025-12-11
External watchdog	cids_sentry_watchdog@external.service	External recovery lane	Health probe, bounded restart attempt, verified recovery	LIVE · operator-confirmed 2026-07; 5/5 integration checks 2025-12-11
Recovery evidence tail	Cortex differential to dashboard event	Evidence lane	Emits state delta and lane-attributed record as a response candidate	IMPL · dashboard path tested, not active/wired in current 1.1.5
Operator gate	Operator / CIDS response boundary	Privileged response	Lockdown, policy change, and escalation approval	Authority by design (governance contract)

10Sentry-Prime, SentryCortex, EdgeGraph, and Filesystem Intelligence

Section 9 described the processes that hold CIDS authority. This section describes what they know. Four surfaces build local state on the Edge node: a preprocessing relay that turns satellite heartbeats into structured evidence, a lane-local semantic store, a graph agent that watches the node for drift, and a bounded filesystem inspection primitive. Each of them produces evidence, and evidence is the whole of what they produce — the authority to act on it stays where Section 8 places it. [A31]

10.1Sentry-Prime preprocessing and forwarding

Sentry-Prime lives inside the dashboard process. app.py imports SentryPrime and instantiates it once at startup, and the /api/sentry_relay route is the only caller of its pipeline, which makes the dashboard-embedded copy the authoritative implementation rather than one of several. A satellite heartbeat arrives at that route authenticated and decrypted, is attributed to the Sentry role that sent it, and enters preprocessing as a single payload.

Preprocessing runs four stages in a fixed order. Normalization enforces UTC timestamps, rewrites MAC addresses to one delimiter and one case, and coerces port and process fields to consistent types, so that every later comparison is between like and like. Correlation records each port anomaly and each flagged process against the device reporting it, and raises a cross-device finding once the same signature appears on two or more satellites — the property that separates a local oddity from a coordinated one. Enrichment attaches threat indicators for known-suspicious ports and process names and stamps the record with preprocessing provenance; network-context classification is implemented in the same stage and attaches when address resolution supplies an address. Deduplication hashes the alert-bearing fields of the payload and suppresses a repeat of that signature inside a sixty-second window, which keeps a persistent condition from arriving as a flood of identical alerts.

Suppression keys on a signature rather than on the payload. The relay hashes a canonical serialization of the alert-bearing fields alone — origin identity, host, port events, and integrity alerts — and suppresses a record whose signature was last seen inside the window W:

Restricting the signature to alert-bearing fields is what makes suppression useful. A satellite reporting the same anomaly every few seconds varies its benign fields — counters, timings, ambient state — on every send, so a whole-payload hash would differ each time and suppress nothing. Keying on the alert alone means the second and subsequent reports of an unchanged condition collapse, while any change to the condition itself produces a new signature and passes immediately.

What survives deduplication is forwarded into heartbeat handling and reaches the dashboard store. What is suppressed returns a suppression result and is written to the monologue stream, so a suppressed duplicate remains reconstructable rather than vanishing. Both pieces of preprocessing state are bounded: expired signatures are swept from the deduplication cache on a periodic interval, and the correlation buffer is cleared once it exceeds its size limit, so a long-running relay cannot accumulate state without limit. Per-stage timings accumulate alongside processed, suppressed, and error counts, and a failure inside any stage increments the error count and propagates rather than dropping the payload quietly.

A bounded local run on 2026-07-18 exercised the pipeline end to end: it normalized MAC, port, and process fields, attached preprocessing metadata, and suppressed a repeated payload. That establishes the relay as functional when invoked IMPL, tested and awaiting active wiring in working 1.1.5. The standalone Prime coordinator is a different surface, and Section 11 owns it.

The pipeline model below asks how a raw heartbeat becomes structured, reviewable, and retainable without crossing the authority boundary. It traces the relay from satellite ingress through the four preprocessing stages to the dashboard store, and names the evidence each stage leaves behind.

10.2SentryCortex and EdgeGraph local state

Two stores hold local state on the Edge node, and they answer different questions. SentryCortex is a Sentry lane's semantic memory of the device it runs on. EdgeGraph is the node's structural record of itself, maintained so that change becomes visible.

SentryCortex initializes inside a Sentry lane when its module is available, and the lane continues without it when it is not, so the store enhances the lane rather than gating it. Once initialized it ingests each heartbeat as a timestamped telemetry point and maintains process knowledge keyed by process identity, recording first-seen and last-seen times so a process can be placed in time rather than only observed now. It answers three query classes, all of them locally: recent telemetry and process history read from its own tables, while file context reads an ORACode weighted graph loaded at construction and indexed by path for direct lookup. That third class is what lets a lane ask what a file means rather than only what it is. A runtime graph load is recorded on 2026-02 IMPL, and a bounded local run on 2026-07-18 ingested a telemetry point, retained a process record, and returned both database-backed query classes from an in-memory store.

EdgeGraph runs as cids-graph-agent.service on the Edge node and is the live observation core of this section. Each cycle builds three views: file metadata across the filesystem, listening ports with the processes behind them, and the network neighbors visible to the node. Hashing is deliberately selective — a file is hashed when it sits under a critical path or carries an executable, configuration, or script extension; an unchanged modification time reuses the previous hash; and files above a size threshold are marked rather than read — so the cost of a cycle tracks the parts of the node that matter rather than the size of its disk.

Drift is the comparison, not the scan. Each of the three views is differenced against its retained counterpart, and the agent raises what the current cycle holds that the previous one did not:

The asymmetry of that operator is worth stating plainly: it reports appearance. A file that arrives, a port that begins listening, a neighbor that joins the segment — each raises evidence on the cycle it appears. Departure changes the retained graph without raising anything, because the current state simply replaces the previous one. The agent is therefore an instrument for detecting what has been added to a node, which is the shape most host-integrity questions take.

What appears for the first time is raised as drift evidence before the graph is replaced by the current state. The graph persists to disk on a slower interval than the scan, so a restarted agent resumes against known state instead of reporting the entire node as new. An optional uplink can forward a drift summary for analysis and returns commentary to the log; it is advisory in the strict sense and reaches no enforcement path. A Windows implementation of the same agent exists IMPL; the Linux agent is the one running as the Edge-node service.

The model below asks how local telemetry becomes durable state and where each store's results terminate. It places the semantic store, the drift graph, and the bounded capture primitive on one plane and shows what leaves it.

10.3Bounded filesystem inspection and the integration boundary

Filesystem inspection is a primitive with explicit bounds, invoked against approved roots. A capture takes a list of root paths, walks each one, and records name, size, modification time, and permission bits for the entries it can read. It respects the permissions it meets — an unreadable directory is recorded as unreadable and the walk continues past it — so inspection sees exactly what the invoking context already may.

Three independent bounds cap the walk — a maximum depth D, a maximum file count N, and a maximum wall-clock duration T — and the walk halts at a node as soon as any one of them is met:

Recording which disjunct fired is what makes a partial capture legible. The branch is marked truncated and the bound that stopped it is retained beside the mark, so a reader can distinguish a tree that ended because it ran deep from one that ended because it ran long — a distinction that changes what the result means. The primitive carries two bound profiles: an on-demand default, and a tighter periodic profile running one level shallower on roughly half the file and time budget, because a capture folded into a routine cycle can afford less than one an operator has asked for.

Exclusions remove virtual filesystems, high-churn log and cache directories, development artifacts, mount points, and binary and media file classes before the walk reaches them. The result is a metadata tree — names, sizes, timestamps, and permission bits — serialized to JSON and gzip-compressed for transport, and restored by the inverse operation. A bounded local run on 2026-07-18 captured a tree under explicit depth, file, and time caps, compressed it, and restored it to the original structure, establishing the primitive as functional when invoked with its bounds set IMPL.

Where that primitive attaches is a separate question from whether it works. The periodic push that once carried snapshots inside the heartbeat is archived in favor of on-demand capture, and the current caller is a filesystem query verb on the peer back-channel handler. That handler defines its own bearer authentication, persona-tier check, and payload signing, and its initializer awaits a call site in the Sentry path PARTIAL. On-demand remote inspection is therefore an integration boundary still under construction, and Section 11 owns the transport it will sit on.

The crosswalk below ties each surface in this section to the source that implements it, the runtime surface that carries it, and its node class, and it separates the maturity of a primitive from the maturity of the wiring around it.

TABLE 10 · Local intelligence component crosswalk

Component	Key file(s)	Service or surface	Node class	Evidence status
Sentry-Prime relay	services/network_router/cids/dashboard/app.py, services/network_router/cids/dashboard/sentry_prime.py	cids-dashboard.service · /api/sentry_relay	Edge node	IMPL · tested, awaiting active wiring in 1.1.5
SentryCortex local state	services/network_router/cids/sentry/sentry_cortex.py, services/network_router/cids/sentry/cids_sentry.py	cids-sentry@internal.service lane-local store	Edge node	IMPL · runtime graph load recorded 2026-02
EdgeGraph drift agent	services/network_router/cids/cids_graph_agent.py	cids-graph-agent.service	Edge node	LIVE · operator-confirmed 2026-07
EdgeGraph Windows sibling	services/network_router/cids/cids_graph_agent_windows.py	Implementation sibling of the Linux agent	Windows host class	IMPL
Filesystem snapshot primitive	services/network_router/cids/sentry/filesystem_snapshot.py	Bounded local capture, compression, and restore	Edge node and satellite Sentry path	IMPL · bounded capture exercised 2026-07-18
Remote filesystem query integration	services/network_router/cids/sentry/p2p_handler.py	Peer query verb; initializer awaits a Sentry call site	Satellite Sentry path	PARTIAL
Dashboard operator surface	services/network_router/cids/dashboard/templates/index.html, services/network_router/cids/dashboard/app.py	cids-dashboard.service · authenticated console and health endpoints	Edge node	IMPL · Prime's host dependency; Section 12 owns its behavior

11CaSTaP, CalamumUplink, and Sentry Back-Channel Transports

This transport layer asks how CIDS separates sealed authority-bearing traffic from auxiliary relay and peer traffic. CaSTaP is the canonical transport envelope. CalamumUplink layers an RSA-sealed ephemeral key over a CaSTaP packet so satellite Sentries can bind telemetry to runtime context. The P2P back-channel remains a distinct peer surface with bearer-token and persona-tier controls, HMAC signing, roster state, and explicit query, broadcast, register, and heartbeat routes. Emergency recovery stays separate from all of those lanes and is treated as a bounded response path, not a general transport.

11.1Transport taxonomy and authority

Five lanes carry CIDS traffic, and they are separated by what they are permitted to do rather than by what they transmit. CaSTaP is the canonical envelope: a context-bound seal that every other sealed lane is expressed in terms of. CalamumUplink is not a second protocol but a key-transport layer over a CaSTaP packet. Relay and heartbeat carry authenticated evidence into the dashboard path. The peer back-channel supplies coordination verbs between Sentries. Recovery carries bounded local control, and it is the only lane of the five that can change a running system — which is why Section 8 places its authority outside the transport layer entirely.

CaSTaP carries operator-confirmed functional proof-of-life with fail-closed behavior on context mismatch, and the current hardening suite passes 5/5 IMPL, tested and awaiting active wiring in working 1.1.5. The lanes below hold their own maturity independently: CalamumUplink and relay/heartbeat are likewise IMPL, the peer back-channel is PARTIAL, and lane-local recovery retains the LIVE status established in Section 9 without lending it to the transport plane.

11.2CaSTaP and CalamumUplink assurance

CaSTaP binds a packet to the runtime context it was produced in. Sealing canonicalizes that context deterministically, hashes it, and encrypts the payload under AES-GCM with a random nonce, carrying the context hash alongside the ciphertext. Unsealing reverses the order deliberately: the receiver parses the packet and compares context hashes before attempting decryption, so a packet presented in the wrong context is rejected on a hash comparison rather than on a failed authentication tag. That ordering is what makes the failure fast and unambiguous, and it is the sense in which the envelope fails closed — a context mismatch and a tampered payload both terminate the exchange, the first at the comparison and the second at the authenticated decrypt. [3]

CalamumUplink is a key-transport layer over that envelope rather than a parallel protocol. It generates an ephemeral CaSTaP key, seals the payload with it, wraps the key under RSA-OAEP for the receiving identity, and prepends the wrapped key to the resulting packet. The envelope contract is untouched: what changes is how the symmetric key reaches the far side. Reading the two as one protocol with two key-distribution modes is the correct model, and it is why a change to the envelope propagates to both. [4]

The canonical encoder and decoder live in services/network_router/cids/sentry/cids_security.py. A second byte-identical copy sits in the dashboard tree at this checkpoint; it is a duplicate of the same implementation rather than a second protocol authority, and consolidating it does not alter the packet contract. Both paths are IMPL — tested, with the current hardening suite passing 5/5, and awaiting active wiring. [A32]

The next visual asks how CaSTaP itself enforces the boundary once a packet arrives. It follows the canonical envelope from context canonicalization through hash binding and AES-GCM sealing to fast rejection and authenticated unsealing when the runtime context matches.

11.3Relay, heartbeat, and the peer back-channel

The relay is not the mesh, and keeping them apart matters. Relay and heartbeat move authenticated evidence from a satellite to the dashboard along a single directed path: ingress is authenticated and decrypted, preprocessing runs where Section 10 describes it, and enriched state reaches the dashboard store. It is a collection surface, and it terminates at a store IMPL, tested against the current dashboard application and awaiting active wiring.

The peer back-channel is a different shape: Sentries addressing one another and a coordinator. It implements query, register, roster, heartbeat, and broadcast verbs, each behind a bearer-token check and a persona-tier authorization test, with a helper that signs responses under HMAC. An operator-confirmed mesh exercise over the CaSTaP-gated path succeeded on or before 2026-05, which establishes that the verbs work when driven.

Its integration is where the maturity sits PARTIAL. The handler's initializer is not called from the main Sentry path; the broadcast verb builds and signs an envelope and then counts roster members rather than delivering to them; and roster state is held in memory, so it is scoped to the lifetime of the process holding it. Those are the boundaries of what the peer surface currently does, and Section 19 owns the work that extends them.

The final transport visual asks how the peer mesh is organized and where a failure in it terminates. It shows the coordinator-backed roster path, the authenticated peer verbs, and which parts of the surface are implemented against which remain expansion work.

11.4Recovery and failure routing

Recovery is the one lane here that acts rather than carries, and its live portion is deliberately small. Health probing, bounded restart, and post-restart verification run beside each Sentry lane on the Edge node and are LIVE, as Section 9 establishes; a dated 2025-12-11 integration run records 5/5 checks passing against those paths. That surface is local: it restores a process on the node it runs on, under CIDS and operator authority, and it is not a distributed recovery transport.

The distinction matters because the two are easy to conflate. Restarting a lane and re-establishing a federation are different problems with different failure modes, and only the first is implemented. Persistent roster state, coordinator failover, quarantine, transport-wide rate enforcement, replay defense, and protocol-version negotiation are PLANNED, and Section 19 carries their mechanics, dependencies, and the evidence each would need to be promoted.

Taken together the three transport views describe a layered boundary: the envelope protects sealed telemetry through context binding, the relay preserves evidence quality without acquiring authority over it, and the peer surface authenticates its verbs while its delivery and persistence remain incomplete. The inventories below turn that topology into auditable contracts, and the last of them separates the controls that exist today from those that belong to the expansion programme.

TABLE 11 · CIDS transport endpoint and message-contract inventory

Surface	Key file(s)	Auth / trust anchor	Direction	Payload or contract	Evidence status
CaSTaP envelope	services/network_router/cids/dashboard/cids_security.py	Context hash + AES-GCM	Bidirectional packet seal	Canonical packet with header, nonce, hash, ciphertext	IMPL · tested, not active/wired
CalamumUplink	services/network_router/cids/dashboard/cids_security.py, services/network_router/cids/sentry/cids_sentry.py	RSA-wrapped ephemeral key + CaSTaP context	Satellite telemetry uplink	Hybrid seal for telemetry bound to runtime context	IMPL · layered on CaSTaP
Relay / heartbeat	services/network_router/cids/dashboard/app.py	Dashboard auth token + relay contract	Satellite → dashboard	/api/sentry_relay and /api/heartbeat	IMPL · tested dashboard path, currently inactive
P2P back-channel	services/network_router/cids/sentry/p2p_handler.py	Bearer token + persona-tier ACL + HMAC	Peer ↔ peer / coordinator	query, broadcast, roster, register, heartbeat	PARTIAL · coordinator-backed; handler not initialized by the Sentry path
Emergency recovery	services/sentry_watchdog/watcher.py, services/network_router/cids/sentry/cids_sentry_watchdog.ps1, deployment/systemd/cids_sentry_watchdog@.service	Operator + CIDS response gate	Local remediation / escalation	Health probe, bounded restart attempt, verified recovery	LIVE · lane-local recovery; 5/5 integration run 2025-12-11

TABLE 12 · Transport comparison across CIDS lanes

Lane	Primary purpose	Trust anchor	Payload class	Status boundary
CaSTaP	Canonical packet seal between CIDS nodes	Context hash + AES-GCM	Telemetry envelope	CIDS-owned transport authority
CalamumUplink	Wrap telemetry with an RSA-sealed ephemeral key	Public-key seal + CaSTaP context	Telemetry uplink	Layered on top of CaSTaP, not separate from it
Relay / heartbeat	Normalize, enrich, and persist evidence-bearing heartbeats	Dashboard auth token and relay contract	Heartbeat and monologue records	Advisory evidence surface; no enforcement authority
P2P back-channel	Coordinate peer queries, broadcasts, registration, and liveness	Bearer token, persona-tier ACL, HMAC	Peer control messages	Coordinator-backed and fail-closed
Emergency recovery	Local remediation, bounded restart, and escalation	Operator gate plus CIDS response policy	Control actions	Bounded response lane, not a general transport

TABLE 13 · Transport threat, control, and validation matrix

Threat	Affected lane(s)	Control	Status	Evidence or owner
Spoofing	CaSTaP, CalamumUplink, P2P	Context hash binding; bearer token and persona-tier authorization on peer requests	IMPL	Context mismatch rejected before decryption; peer verbs require an authenticated caller
Tampering	CaSTaP, CalamumUplink	AES-GCM tag verification; RSA-OAEP wrapped key integrity	IMPL	Unseal fails on a tampered payload and on a mismatched context
Path escape	Relay/heartbeat, P2P query, filesystem inspection	Fixed endpoint contracts; query-type gating; bounded roots, depth, count, and duration	IMPL	Only declared query verbs dispatch; a capture halts at its first bound with the reason recorded
Resource exhaustion	Watchdog recovery, filesystem inspection	Bounded restart attempts; capture file and duration caps	IMPL	Restart attempts are bounded per lane; bounded capture exercised 2026-07-18
Stale state	Relay/heartbeat, P2P roster	Bounded cache lifetime with periodic sweep; roster last-seen updates	IMPL	Expired signatures swept on a periodic interval; roster entries refreshed on heartbeat
Privilege misuse	Emergency recovery, operator views	Operator and CIDS response gate	LIVE	No transport surface transitions state; the gate is the only path, per Section 8
Replay	CaSTaP, P2P, relay/heartbeat	TTL and counter-based replay defense	PLANNED	Section 19
Peer flooding	P2P back-channel	Transport-wide rate enforcement	PLANNED	Section 19
Coordinator loss	P2P back-channel	Durable roster, coordinator failover, and quarantine	PLANNED	Section 19

12Console, Activity, and Response

Five components produce operator-facing evidence in CIDS, and each writes its own record family to its own store. The honeypot, the killswitch service, the Nexus integrity guard, the recovery manager, and the router enforcement core run as services on the router LIVE. The browser dashboard that renders their activity holds its own maturity independently: it is IMPL, tested and inactive in working 1.1.5, and its read view and access-control layer is scoped PARTIAL.

Those two facts are kept apart throughout this section. A guard being live says nothing about whether a console is available to watch it, and a console being implemented says nothing about whether the guard it renders is running. The subsections below take the record primitives first, then the crosswalk of who produces what and who reads it, then the authority gate that separates observation from response, and finally the four bounded controls that act.

12.1Dashboard, status, and observed event records

The dashboard's monologue writer log_monologue() appends one JSON object per line to a behavioral log. Each entry carries a timestamp, an action label, a message, and a severity. When the caller supplies no severity the writer derives one from the action label, so failure and error actions resolve to error, warning actions to warning, and authentication or startup outcomes to success, with everything else recorded as informational. An event that arrives on a Sentry lane additionally carries that lane's role, which is the whole of the attribution the record holds.

Three read primitives sit over that file and over live process state, and they differ in what survives them. The monologue reader returns the last hundred entries newest first, reading from the file each time. Status assembly get_status_data() composes a fresh view on every read from current process and interface state rather than from a stored snapshot. Stream publication combines a status view and a monologue view into a single frame and re-emits it once per second, so the frame is a rendering of state rather than a record of it. Node presence is held in a heartbeat cache keyed by hardware address, and a purge pass drops any entry unseen for five minutes before status is assembled, which is why a departed node leaves the view instead of persisting in it.

The distinction that organizes this surface is therefore not what each primitive shows but how long what it shows survives, and which component wrote it in the first place.

Solid edges mark what a component writes and thin edges what a reader consumes, and the two store classes never merge. Records that persist survive the process that wrote them and remain readable on the host afterwards; cache and stream state exist only for as long as the surface holding them runs. A console that is inactive therefore withholds the transient view entirely while leaving every persistent record exactly where its producer left it.

12.2Attribution, retention, and view controls

Attribution is per-producer rather than shared. A monologue entry names a Sentry lane only when the event arrived on one. An intrusion record names a source address and, where resolution succeeds, a hardware address. An incident record names a component and a host. Each of those is the attribution its own producer had available at the moment of writing, and no field common to all three carries a reader from one record to another.

Retention follows the producer just as closely. Appended files grow until the host rotates them and outlive the process that wrote them. The heartbeat cache is bounded by its five-minute purge. A stream frame is discarded as soon as the next one is built. Recovery evidence is written once per event as a matched JSON and Markdown pair carrying the recovery level, the action attempted, and its outcome. These are four different retention behaviors, and the console does not impose a fifth on top of them.

The crosswalk below fixes, for each producer, what it records, how long the record lives, what it names, and who reads it.

TABLE 14 · Current event and evidence crosswalk

Producer	Record family	Persistence	Attribution	Read through	Access boundary	Status
Monologue writer log_monologue()	Timestamp, action label, message, severity, optional Sentry role	Appended per event to a behavioral JSONL file	Sentry lane role when the event arrives on a lane	Console monologue panel, last 100 entries newest first	Dashboard read view PARTIAL	IMPL
Status assembler get_status_data()	Composed process, interface, and service view	Rebuilt on each read; nothing stored	Reporting host	Dashboard status widgets	Dashboard read view PARTIAL	IMPL
Heartbeat cache	Node record: hostname, hardware address, last-seen time	Held in memory; purged after five minutes unseen	Reporting node	Active-connections panel	Dashboard read view PARTIAL	IMPL
Stream publication	Combined status and monologue frame	Transient; rebuilt once per second	Inherited from the two composed sources	Event-source client in the console	Dashboard read view PARTIAL	IMPL
Honeypot service	Timestamp, source address, resolved hardware address, trigger, action, method, severity, attack class	Appended per touch to an intrusion JSONL file	Source address and hardware address where resolution succeeds	Intrusion panel and archive review on the host	Host-local	LIVE
Nexus guard and killswitch services	Service log lines carrying the observed condition and the action taken	Appended by each unit to its own service log	Owning service and host	Operator review on the host	Host-local	LIVE
Recovery manager create_incident_report()	Incident record: identifier, recovery level, component, action, outcome, host	One JSON and Markdown pair written per recovery event	Component and host	Archive review	Host-local	LIVE

Read access across the dashboard surfaces is scoped PARTIAL: the layer that decides which reader receives which view is present and incomplete, and Section 18 carries it. A cross-producer record contract, view shaping by reader capability, and a universal pointer from any event back to its supporting evidence file are PLANNED, and Section 19 owns their specification and promotion evidence. The boundary that holds today is the one the crosswalk states: each store is read where it is written, at the maturity of the surface that reads it.

12.3Active response and operator authority

Observation and response are separated by an explicit authority gate. The router enforcement service acts on whitelist and anomaly outcomes under CIDS and operator authority and is LIVE; Section 9 specifies its observation cycle, its neutralization path, and the separately built monitor-only variant. The dashboard's manual response route is IMPL: it is present and gated on explicit operator authorization, it sits inside the application that is inactive in working 1.1.5, and it inherits nothing from the enforcement service's liveness.

Every other surface named in this section is an evidence surface. The console renders, Sentry-Prime preprocesses, SentryCortex holds local semantic state, and telemetry reports. None of them acquires authority to change a running system by producing a record recommending that one be changed. That is what makes the gate an architectural boundary rather than a convention: authority is held by the operator and by CIDS, and the surfaces that observe are constituted so that they cannot exercise it.

What the response plane makes visible is which inputs reach the gate, and what each permitted path writes on the far side of it.

The gate is single, but the paths beyond it are not equivalent. Router enforcement and the three guards act on the host and are live; the manual console route is implemented and waits on the application that hosts it. Each path writes into the store its own component owns, so a permitted action leaves evidence in one place and the action itself tells a reader which place that is.

12.4Integrity guards and recovery evidence

Four controls act, and each is bounded independently of the others. The honeypot presents decoy services, records a touch as an intrusion entry carrying its trigger, severity, and attack class, and neutralizes the source; its safeguards hold the host's own identities outside the set of eligible targets, and captured material is truncated before it is written. The Nexus integrity guard compares each live file against a held reference copy on a fixed interval, restores the reference copy when the two hashes differ, and restarts the service mapped to that file. The recovery manager escalates through bounded levels — restoring or repairing a corrupt service configuration, restarting a failed service, and reinstalling it when a restart does not hold — and writes a matched JSON and Markdown incident record at each level it reaches, so the escalation path is reconstructable from the records alone. [A33]

The killswitch service is live and watches the tunnel continuously. Its operating posture is reported separately from its liveness, because the two are established by different evidence: the dated 2026-02-15 record places the service in logging mode, where a tunnel drop is registered as a critical condition and the access interface is left up for diagnosis. Liveness is what the operator confirms; the mode carries its own date.

Each of these controls writes where it runs. Intrusion entries, service logs, and incident pairs are three stores under three retention behaviors, held on the host that produced them. A reader assembles the picture by consulting them in turn, and the value of that arrangement is that no single store can be corrupted into a misleading account of what the other two observed.

The next section stays separate: Calamum remains an adversarial validation context rather than a response authority, and ORACode remains a retrieval context rather than an operator control surface.

13CIDS Current-Capability Validation and Evidence Matrix

CIDS is proven at its core and advancing at its edges. The router enforcement service, the two separated Sentry lanes with their paired watchdogs, EdgeGraph drift observation, and the integrity and recovery guards are LIVE, in active use on the enforcement host. That set is what the platform's active protection rests on.

The capabilities around that core hold their own maturity rather than being averaged into it. A tested transport awaiting wiring, a handler awaiting its call site, and a read layer in progress are three different conditions, and each carries the evidence that fixes it. The subsections below take the current evidence position first, then the capability matrix across the CIDS planes, then the measurements CIDS presently supports, and finally the questions its evidence leaves open.

13.1Evidence method and status projection

CIDS runs on one enforcement host. As of July 2026 the router enforcement service, the internal and external Sentry lanes, the watchdog paired to each lane, the EdgeGraph drift agent, and the honeypot, killswitch, integrity guard, and recovery manager all run there in active use. Dated records establish what those components were built to do: lane roles and a watchdog recovery run recording 5/5 checks from 2025-12-11, and a killswitch mode record from 2026-02-15.

A second group of surfaces is proven by direct exercise. Bounded runs on 2026-07-18 drove Sentry-Prime normalization and suppression, SentryCortex telemetry and process queries, and capped snapshot capture and restore. The CaSTaP envelope holds functional proof-of-life with fail-closed rejection on context mismatch and passes its hardening suite 5/5. A peer mesh exercise over the sealed path succeeded on or before 2026-05. Each returns what it was built to return when called.

That last clause carries the weight, because several CIDS surfaces are complete and awaiting their call sites. A filesystem query verb sits on the peer handler ready for a Sentry path to invoke it, and the browser dashboard renders every record family it was built for, awaiting activation in working 1.1.5. These are wiring stages, and each component's own maturity is stated alongside the maturity of its wiring wherever the two differ.

CIDS evidence spans December 2025 to July 2026, and each claim below carries the date its evidence was observed rather than inheriting the freshest date around it. Where a component's liveness and its operating posture rest on different records, both are stated: the killswitch service is live and watches the tunnel continuously, and the logging mode it operates in is dated 2026-02-15.

13.2Current capability and evidence matrix

CIDS divides into six planes, each carrying its own evidence. Authority and supervision are live throughout: enforcement, both Sentry lanes, and their paired watchdogs run continuously on the enforcement host. Intelligence, transport, and console each pair a proven core with integration advancing behind it. Response is live where it enforces and operator-driven where a person acts directly.

Two properties follow. Authority and liveness coincide: every capability able to change a running system is one in active use, carrying the strongest evidence in the section. And the advancing work is integration rather than function — the transport seals, the peer verbs authenticate, and the console renders, so what remains is joining proven surfaces to the paths that drive them.

The ledger below states each capability at its own level, with the evidence that fixes it, what it does today, the authority it holds, and the section that specifies it.

TABLE 15 · Current CIDS capability and evidence ledger

Capability	Surface	Status	Evidence class	Evidence date	What it does today	Authority role	Owner
Router enforcement and the CIDS authority core	Enforcement host	LIVE	Active use with runtime corroboration	July 2026	Evaluates station state against the whitelist and acts on the outcome	Holds enforcement authority with the operator	Sections 8, 9
Internal and external Sentry lanes with paired watchdogs	Enforcement host, separated lanes	LIVE	Active use; dated deployment and integration records	Active use 2026-07-16; roles and 5/5 recovery run 2025-12-11	Carries telemetry on two process-separated lanes, each probed and restarted by its own watchdog	Evidence-bearing; recovery acts on lane processes only	Section 9
EdgeGraph drift observation	Edge node, Linux service	LIVE	Active use; implementation inspection	July 2026	Builds file, port, and neighbor views each cycle and raises first appearances as drift	Observation only	Section 10
Honeypot, killswitch service, Nexus integrity guard, and recovery manager	Enforcement host	LIVE	Active use; implementation inspection; dated mode record	Liveness July 2026; killswitch mode recorded 2026-02-15	Four bounded controls run continuously, each writing its own evidence where it runs	Act within individually bounded scopes	Section 12
Sentry-Prime preprocessing and SentryCortex local state	Satellite Sentry path	IMPL	Bounded behavioral probe; implementation inspection	2026-07-18	Normalizes and deduplicates telemetry when invoked; holds local semantic state and answers queries against it	Advisory; no enforcement authority	Section 10
Bounded filesystem snapshot primitive	Satellite Sentry path	IMPL	Bounded behavioral probe	2026-07-18	Captures a bounded metadata tree, compresses it, and restores it by the inverse operation	Read-only	Section 10
Remote filesystem query integration	Peer back-channel	PARTIAL	Implementation inspection	2026-07-18	Carries the query verb; its initializer awaits a call site on the Sentry path	Read-only and authority-neutral	Sections 10, 11
CaSTaP envelope and CalamumUplink key transport	Sealed transport lane	IMPL	Functional proof-of-life; hardening suite	5/5 hardening checks 2026-07-18	Seals a packet to its runtime context and rejects a mismatch before decryption; tested and inactive in working 1.1.5	Transport boundary; carries no decision authority	Section 11
Relay, heartbeat, and the CIDS browser dashboard	Console application	IMPL	Tested function; implementation inspection	2026-07-18	Moves authenticated evidence along a directed path into a store the console renders; the application is inactive in working 1.1.5	Evidence collection and display	Sections 11, 12
Peer query, register, roster, heartbeat, and broadcast verbs	Peer mesh	PARTIAL	Mesh exercise; implementation inspection	Exercise on or before 2026-05	Authenticates each caller by bearer check and persona tier; the handler is not initialized from the main lane, broadcast counts roster members, and roster state is process-scoped	Peer coordination; a refused request carries no authority	Section 11
Dashboard records and manual response route	Console application	IMPL	Implementation inspection; bounded probe	2026-07-18	Writes and reads distinct record families under their own retention; the manual route is gated on explicit operator authorization inside the inactive application	Response only under explicit operator authorization	Section 12
Dashboard read view and access-control layer	Console application	PARTIAL	Bounded probe; implementation inspection	2026-07-18	Decides which reader receives which view; the layer is present and incomplete	Read boundary	Sections 12, 18
Active response and integrity recovery	Enforcement host	LIVE	Active use; implementation inspection	July 2026	Enforcement and the integrity and recovery guards act on the host and each write into the store their own component owns	Acts behind the operator and CIDS authority gate	Sections 9, 12

Authority in CIDS tracks evidence. Every capability able to change the state of a running host is in active use, and the manual console route adds a second path behind explicit operator authorization, activating with the application that hosts it.

13.3Validation coverage and empirical readiness

What is established about CIDS today is functional and behavioral. The watchdog integration run recording 5/5 checks establishes that the recovery paths work when exercised. Bounded probes establish that preprocessing normalizes and deduplicates, that a snapshot captures and restores, and that a sealed packet is rejected on a context mismatch. Each fixes whether a mechanism works.

Performance is a separate measurement with its own requirements. A pass count is a count: five successful recoveries establish that recovery succeeds, while duration, attempt spread, and behavior under load are each their own observation. A latency figure, an availability percentage, a scaling curve, and a recovery-time distribution all require a declared window against a declared workload.

Seven such characterizations apply to CIDS. Each states what it measures, the observation it requires, and the dataset that will support it.

TABLE 16 · Empirical readiness of quantitative CIDS characterizations

Characterization	Required observation	Required measures	Evidence available today	Disposition	Resolution gate
Evidence freshness and availability across activity surfaces	Continuous console operation over a declared window	Record age at read, gap intervals, surface availability fraction	Read primitives exercised inside an inactive application	Awaiting dataset	A declared-window freshness and availability series from an active console
Preprocessing throughput and latency	A declared workload driven through the full preprocessing path	Conserved stage counts in and out, per-stage latency distribution	A bounded functional probe confirming normalization and suppression	Awaiting dataset	Conserved stage counts with a latency distribution over a declared workload
Watchdog recovery timing and reliability	Repeated induced lane failures across both lanes	Per-lane recovery duration, attempts to success, censored non-recoveries	An integration run recording 5/5 checks passing	Awaiting dataset	Per-lane duration, attempt, and censoring data over a declared window
Structural drift rate over time	Continuous drift observation across known change events	Drift events per interval with change boundaries marked	A live observation cycle with no retained comparative series	Awaiting dataset	A dated drift series with its change boundaries annotated
Snapshot scaling behavior	Capture across filesystem trees of materially different sizes	Capture duration and compressed size against tree size	A single bounded capture and restore	Awaiting dataset	A multi-size capture fixture spanning the intended range
Direct versus relayed transport latency	Matched workloads driven over both paths under equal conditions	Percentile latency per path, delivery outcome counts	Functional proof-of-life on the sealed envelope	Awaiting dataset	Matched direct and relayed workloads with percentile latency
Transport control outcomes under pressure	A controlled adversarial fixture driven against the peer surface	Accepted, rejected, replayed, rate-limited, and quarantined counts	Authenticated verbs exercised in a functional mesh run	Awaiting dataset	A controlled fixture producing each outcome class, with the corresponding controls in place

Two of these gates depend on more than data collection. Transport control outcomes require the rate enforcement, replay defense, and quarantine controls that Section 19 specifies, so the fixture and the controls it would measure arrive together. Freshness and availability require an active console, which is the same wiring that advances the dashboard surfaces. The remaining five require only that the observation be made and recorded.

What CIDS does is therefore established on functional evidence, and how fast, how often, and how reliably it does it follows the observations named above. Each gate is specific rather than general, so a characterization becomes supportable as soon as its dataset exists.

13.4Residual uncertainty and resolution evidence

CIDS retains one open current-state condition: peer-mesh liveness. The peer mesh was exercised successfully over the sealed path on or before 2026-05, which establishes that its verbs work; current mesh traffic awaits a fresh exercise on the working build. The killswitch service is active and running LIVE.

CIDS keeps the peer verbs built and authenticated while current mesh traffic awaits fresh observation. Remote query integration, dashboard access, and quantitative characterization retain their bounded evidence requirements alongside that condition.

TABLE 17 · Residual uncertainty register

Open claim	Current status	Last authoritative evidence	What remains open	Evidence that resolves it
Current peer mesh liveness	UNRESOLVED	Mesh exercise over the sealed path, on or before 2026-05	Whether peers currently register, hold roster state, and exchange traffic on the working build	A dated mesh exercise on the current build with registration, roster, and delivery observed
Remote filesystem query integration	PARTIAL	Implementation inspection 2026-07-18	Whether a Sentry call site drives the query verb end to end	An observed end-to-end query initiated from the Sentry path
Dashboard read view and access-control layer	PARTIAL	Bounded probe and inspection 2026-07-18	Which reader receives which view once the layer is complete	A probe covering each reader class against each view the console exposes
Quantitative performance characterization across the seven surfaces above	No eligible dataset	Functional and behavioral evidence only	Latency, availability, drift-rate, scaling, and recovery-time behavior	Declared observation windows and controlled workloads for each surface

An absent dataset and an unobserved system state are different conditions. A capability awaiting performance measurement is working and uncharacterized; the surfaces covered by the final row all hold the maturity their own evidence supports. Section 18 carries the reader-relevant limitations that follow from this register, and Section 19 specifies the expansion work that closes the integration and control gaps behind it.

14Calamum: Adversarial Validation Context

Calamum Test is a project-aware adversarial validation harness, published independently as calamum-test 0.3.1. It executes defined validation work against a declared subject, applies thresholded evaluation to the interactions it captures, and retains reviewable evidence artifacts that record what ran and under what conditions. A focused suite exercised on 2026-07-18 passed 11/11 across its public API, catalog, and signing contracts. The harness develops on its own release line, distinct from the Calamum Intrusion Detection System and its CalamumUplink transport, which operate inside CodeSentinel's enforcement architecture; the shared name records common origin, and each system holds its own runtime.

A retained Calamum run supports a CodeSentinel claim when its subject, conditions, outcome, and provenance map to that claim. Calamum evaluates and records; lifecycle transitions, policy, execution authority, and CIDS response stay with the CodeSentinel surfaces that own them. That separation is what makes a Calamum artifact usable as independent corroboration of detection thresholds, regression behavior, and evidence lineage.

15ORACode: Semantic Retrieval and Evidence Context

ORACode is the graph-construction plane: it turns governed repository artifacts and the relations among them into a versioned semantic substrate. ORACall is the retrieval plane over that substrate, resolving queries into ranked, evidence-linked results. Each rebuild produces a versioned snapshot carrying the repository state at that build. Both planes run in the unpublished development line rather than in the public distributions, PyPI 1.1.1 and GitHub 1.1.3.b1 + hotfix2, and Section 16 sets out the reproducibility boundary that follows.

Development-line CodeSentinel exposes graph build and inspection, retrieval with fallback, search and persona handling, visualization, and advisory integration over these two planes. A locked selected-suite run passed 61/61 across those families, and a focused drift check on 2026-07-18 passed 20/20 across graph linkage, search, persona handling, and graph-rebuild behavior. ORACL remains the temporal memory, continuity, and advice layer described in Section 7; ORACode and ORACall supply semantic construction and retrieval beneath those advisory surfaces. Ranked results, confidence scores, and graph edges inform a decision and carry no authority to transition a job, change policy, execute work, or trigger a CIDS response. [A26][A27]

16Packaging, Distribution, and Reproducibility

16.1Public artifacts and release identity

CodeSentinel publishes the lean core through two distinct artifacts in its distribution lineage. PyPI provides the versioned codesentinel 1.1.1 installation artifact, while the public GitHub release 1.1.3.b1 + hotfix2 supplies the lean source and tag lineage. The unpublished development line carries version 1.1.5 and broader integration evidence. Public reproduction therefore covers the lean core at the identity and contents of each public surface.

16.2Shipping and managed-environment controls

CodeSentinel prepares releases with safeguards that run on invocation. The bounded publication-manifest verifier checks a three-document set associated with a prior public drop and, on 2026-07-18, verified all three declared entries. [A17] The managed-environment control registers authorized environments, resolves one canonical primary, verifies policy before scripts execute, and retires superseded environments through archive-first handling. Its 2026-07-18 inventory resolved the registered set and canonical primary; repository-marker detection carries a narrow PARTIAL edge while the inventory and selection controls remain functional.

16.3Reproducibility boundary

CodeSentinel makes its lean core publicly reproducible through PyPI and GitHub. The development line owns governance and evidence depth, CIDS, CaSTaP integration, full ORACL, and the integrated ORACode/ORACall surface; reproducing those capabilities requires governed access to the unpublished 1.1.5 source and the dated evidence attached to each capability. Each capability retains the status established by its own evidence. CIDS additionally rests on dated private-deployment evidence.

Calamum Test and ORACode/ORACall also publish independently. Calamum Test distributes calamum-test 0.3.1 through PyPI and GitHub. ORACode/ORACall publishes the oracode 0.1.0 source release through its own GitHub repository, where a 2026-07-10 published-clone reviewer loop reproduced installation, graph construction, search, query, and test execution. These independent artifacts reproduce their own project scopes; their CodeSentinel relationships retain the availability and status of the integrated surfaces.

TABLE 18 · Distribution and reproducibility surfaces

Surface	Authoritative identity	Availability	Reproducible scope	Verification evidence	Reproduction limit	Status
PyPI package	codesentinel 1.1.1	PyPI	Versioned installation artifact for the lean core	Public metadata and artifact verification	Integrated capabilities reside on the development line	IMPL
Public GitHub source	1.1.3.b1 + hotfix2	GH	Lean source and tag lineage	Tag and tree verification	Integrated capabilities reside on the development line	IMPL
Development source	Unpublished 1.1.5	DEV	Governance, evidence, ORACL, ORACode/ORACall, CaSTaP, and CIDS integration	Package metadata and import identity agree	Governed access with dated capability evidence	IMPL source surface
Publication-manifest control	Prior-drop three-document set	DEV	Declared publication entries	2026-07-18: all three entries verified	Three-document verification scope	IMPL
Managed-environment control	Registered inventory and canonical primary	DEV	Authorization, verification, primary selection, and archive-first retirement	2026-07-18: inventory and canonical primary resolved	Repository-marker detection edge	IMPL detection PARTIAL
Calamum Test release	calamum-test 0.3.1 public source	PyPI GH	Standalone adversarial validation and retained-evidence contracts	Public metadata, source, and focused contract validation	Independent project; CodeSentinel and CIDS retain their own authority	IMPL
ORACode/ORACall release	oracode 0.1.0	GH	Standalone graph construction and retrieval reviewer loop	2026-07-10 published-clone installation, build, search, query, and test reproduction	CodeSentinel integration remains on the development line	IMPL

17Platform Validation, Audits, and Evidence Surfaces

CodeSentinel validates capability claims against evidence that identifies the subject, conditions, outcome, observation time, and lineage. Its live authority core spans canonical task and QuestStack state, protected-state verification, ORACL continuity, and CIDS evidence production; narrower producers and views retain their own statuses. Canonical records establish authority inside their owned domains; behavioral evidence establishes function under declared conditions; current operational evidence establishes active use. Derived views retain their value by carrying the source and freshness information from which they were produced.

17.1Evidence classes and claim promotion

CodeSentinel gives a dated operational-use attestation and a direct runtime observation equal evidentiary weight when each maps to the same subject and conditions. Focused tests establish behavior under a declared fixture, deployment records preserve dated configuration, and implementation inspection establishes structure. [A36] Status promotion stays within the capability and observation window that the evidence supports.

CodeSentinel draws on nine evidence families, each bounded by its own authority and freshness contract.

TABLE 19 · Evidence classes, authority, and freshness

Evidence class	Answers	Authoritative scope	Canonical or derived	Freshness requirement	Status consequence	Owner or index
Operational-use attestation	Current use, topology, selected mode, and authority assignment	Attested capability and environment	Direct operational evidence	Dated current-use statement	May support LIVE within the dated scope	Owning capability section
Direct runtime observation	Behavior or state observed during an invocation or window	Invoked surface and declared conditions	Direct observation	Observation date or window	Supports LIVE operation or IMPL function at the observed level	Owning capability section
Focused behavioral test or probe	Functional, failure, integrity, or security semantics under a controlled fixture	Named subject, fixture, and result	Controlled observation	Test date, fixture class, and outcome	Supports IMPL for the proven behavior	Owner section and suite evidence
Deployment or service record	Configuration and operating state at the record date	Recorded deployment and role	Dated operational record	Record date; current state follows newer evidence	Supports dated deployment; LIVE follows current observation	Deployment owner
Canonical state or custody record	Authoritative state, transitions, and integrity within an owned domain	Writer and mutation contract	Canonical	Current head and verification time	Supports the owner's status within that domain	State-domain owner
Append-only event or audit record	Ordered component-local observations, actions, and outcomes	Producer and record family	Producer-local record	Event time and retention window	Corroborates behavior; authority remains producer-local	Producer contract
Derived view, metric, or index	Aggregation, navigation, health, or interpretation over source evidence	Referenced source records	Derived and read-only	Generation time and source freshness	Inherits source status and carries read-only authority	Source owner and derived index
External retained evidence	Independent validation mapped to a CodeSentinel claim	Subject, conditions, result, and provenance	Independently owned	Run date and artifact provenance	Corroborates the mapped claim; authority remains independent	Section 14 and dedicated evidence owner
Implementation or configuration inspection	Component identity, wiring, contracts, and bounded static properties	Inspected revision and artifacts	Static implementation evidence	Revision or tree observed	Establishes structure; behavioral evidence promotes to IMPL	Owner section and source index

CodeSentinel keeps a capability's status attached to the evidence that establishes it. A current observation can establish active use for its dated subject, a controlled test can establish function under its fixture, and a derived view can interpret authoritative inputs while preserving their ownership.

17.2Canonical state and derived evidence

CodeSentinel separates state authority from evidence rendering. Canonical operations-task and job records own lifecycle mutation. Protected-state baselines and custody ledgers own integrity inside their domains. Component journals and append-only records preserve events under the producer's contract. CodeSentinel renders dashboards, reports, metrics, health summaries, behavioral scores, and indices as read-only interpretations of those sources. [A16]

CodeSentinel reconstructs an operation through the fields defined by the owning record contract. Cross-system reconstruction maps the producer, record family, observation time, action or outcome, and stable source references across those contracts. Regenerable views carry generation time and source freshness so their interpretation remains traceable to authoritative inputs.

17.3Coverage, freshness, and evidence lineage

CodeSentinel binds validation coverage to the conditions actually exercised. A focused test fixes behavior under its declared fixture; a runtime probe fixes observed behavior or state at a time; an operational-use attestation fixes active use and topology at its date; a deployment record fixes the configuration recorded at its date. Stronger duration, frequency, population, and performance characterizations follow observations designed for those measures.

CodeSentinel retains detailed CIDS capability, empirical-readiness, and residual evidence in the CIDS validation synthesis; it maps independently owned Calamum artifacts through the adversarial-validation context and ORACode/ORACall subsystem evidence through the semantic-retrieval context. CodeSentinel maps its interface taxonomy in Appendix B, repository source lineage in Appendix A, and public external references in Appendix F; its residual claims retain the same scope, freshness, and lineage discipline.

18Limitations and Unresolved Operational Claims

CodeSentinel carries a bounded set of reader-relevant limitations across integration, operational freshness, validation, and public reproducibility. Each entry preserves the working parent capability's status and names the evidence that resolves the narrower condition. CodeSentinel's present operating state remains bounded by the conditions below.

18.1Integration and hardening limits

• Managed-environment detection. Repository-marker classification carries PARTIAL for markerless workspaces; authorization, verification, revocation, inventory, and canonical-primary selection remain functional. Resolution evidence: correct markerless classification with focused coverage inside and outside the canonical environment.
• Day and gate-worker cleanup. Canonical job and task state remains LIVE, blocking and timeout outcomes remain IMPL, and the cleanup tail for day orchestration and timed gate workers carries PARTIAL. Resolution evidence: repeated teardown observations across normal, failure, and timeout paths with released handles and temporary resources.
• External alert delivery. Local console and file channels retain their working status; external email and Slack delivery carries PARTIAL. Resolution evidence: timestamped destination receipt and failure-path coverage tied to the source event.
• Policy-event assurance. Policy enforcement remains IMPL with assurance qualified by the configured digest, local or simulated, and externally backed provider modes. Resolution evidence: provider-specific end-to-end verification for each stronger assurance statement.
• Custody operations. Seal and recover behavior remains IMPL; the optional convenience path remains under hardening. Resolution evidence: contained convenience behavior and focused regression evidence under the established custody contract.
• Dashboard read boundary. The CIDS dashboard remains IMPL, while its read-view and access-control layer carries PARTIAL. Resolution evidence: authenticated and unauthenticated view coverage, capability-shaped access tests, redaction checks, and fail-closed deployment configuration.
• Remote filesystem query. The bounded local snapshot primitive remains IMPL; active remote-query integration carries PARTIAL. Resolution evidence: an authorized and denied end-to-end query fixture with bounded output and observed consumer evidence.

18.2Unresolved operational state

• Peer mesh liveness. Authenticated peer primitives and integration remain PARTIAL after the successful exercise on or before May 2026; current mesh liveness is UNRESOLVED. Resolution evidence: a fresh peer and coordinator observation window covering authenticated query, heartbeat, and delivery.

18.3Validation and reproducibility limits

• Historical fixture coverage. Historical ORACL coverage and one custody fixture carry validation debt; live ORACL remains LIVE and current custody behavior retains its owner status. Resolution evidence: restored authoritative historical fixtures and a corrected custody fixture with focused reruns.
• Archive scheduler uptime. The archive scheduler retains IMPL for its implemented scheduling surface, while uptime remains uncharacterized. Resolution evidence: an implemented uptime calculation with a declared observation window and retained status evidence.
• Quantitative CIDS characterization. Seven freshness, preprocessing, recovery, drift, scaling, transport-latency, and control-pressure characterizations await their declared datasets; every underlying capability retains its owner token. Resolution evidence: the observation window, workload, and measures specified for each characterization in Section 13.
• Public reproducibility. PyPI and public GitHub reproduce CodeSentinel's lean core. Governance depth, CIDS, CaSTaP integration, full ORACL, and integrated ORACode/ORACall retain DEV availability with capability-specific status. The independent oracode 0.1.0 release reproduces its own project scope. Resolution evidence: a versioned public CodeSentinel artifact carrying the relevant implementation and verification material.

19Future Expansion and Platform Evolution

CodeSentinel's forward evolution coordinates CIDS expansion, ORACL and Brain evolution, and core-platform controls through one dependency contract. Present foundations retain the status established in their owning sections. Every expansion target carries PLANNED; executable artifacts that satisfy the stated interface and acceptance contract promote the bounded capability to IMPL, and dated runtime or deployment evidence establishes LIVE operation within its observation window.

Dependencies express security, authority, and evidence prerequisites; calendar order remains independent. Evidence contracts precede broader reach, transport assurance precedes distributed actuation, CIDS retains response authority, and boundary extraction follows stable interfaces and compatibility evidence.

19.1Expansion basis and dependency semantics

The CIDS trajectory comprises twelve connected capabilities: attributable activity records, measurable preprocessing, Triad health exchange, transport assurance, peer federation, bounded filesystem inspection, multi-scope integrity graphs, read-only intelligence tools, capability-shaped console views, fleet rollout, emergency recovery, and repository extraction. Each will advance at its own evidence gate while sharing the contracts shown below.

The first promotion gate is executable conformance: schema fixtures, authorization and redaction tests, deterministic component behavior, and evidence-lineage validation must satisfy the capability's interface contract. Deployment status then follows a dated observation of the same identity and configuration. The graph constrains prerequisites while independent branches progress concurrently.

19.2Evidence and preprocessing foundation

Current CIDS producers preserve component-local activity, status, intrusion, service, and incident records, while the dashboard-embedded Sentry-Prime path carries IMPL normalization, deduplication, correlation, enrichment, bounded buffering, and latency instrumentation. The expansion will establish one attributable Activity Stream event contract across Sentry-Prime, the Triad, policy gates, and console records. Each event will carry freshness semantics and a stable evidence pointer, and capability-aware redaction will shape the visible record before it reaches a consumer. [A38]

Sentry-Prime will expose stable counters for ingress, normalization, deduplication, correlation, enrichment, anomaly handling, forwarding, rejection, and processing latency. Promotion follows producer and consumer schema fixtures, unauthorized-view redaction tests, deterministic pipeline fixtures, counter-conservation and bounded-buffer checks, and a sanitized runtime sample bound to the deployed preprocessing identity.

19.3Triad and local-state completion

The dual Sentry lanes and their watchdogs carry LIVE evidence within their dated deployment scope. SentryCortex local state and bounded filesystem snapshots carry IMPL, EdgeGraph drift observation carries LIVE, and remote filesystem query integration carries PARTIAL. These foundations establish lane supervision, local semantic state, bounded inspection, and file, port, and neighbor observations. CIDS retains response authority throughout.

The Triad will add health exchange, port and process differentials, restart-frequency analysis, quarantine-candidate events, and lane-attributed routing. The filesystem path will add authorized read-only pull, approved-root policy, evidence-path results, caching, differential queries, and traversal-budget reporting. The integrity graph will add scope policy, deterministic chunk identities, dirty-subgraph recomputation, signed hard checkpoints, rollback, backpressure, and a federation-ready schema. [A37][A39]

Promotion follows health and fallback tests, differential fixtures, lane-specific deployment telemetry, authorized and denied path tests, traversal and truncation fixtures, root-hash reproducibility, interrupted-write recovery, accidental host-scan prevention, a delta-cost benchmark, and cross-system schema compatibility. Response candidates remain subject to the operator and CIDS authority gate.

19.4Assured transport and distributed security

The CaSTaP envelope and CalamumUplink key transport carry IMPL evidence for fail-closed context binding and remain inactive in working 1.1.5. Peer query, registration, roster, heartbeat, and broadcast helpers carry PARTIAL; their current mesh liveness remains UNRESOLVED. These foundations establish canonical transport ownership, authenticated verbs, and a prior gated back-channel exercise.

CaSTaP will add canonical envelopes, key identifiers, signatures, receipts, expiry, nonce and counter replay defense, risk classes, rotation, revocation, and posture-bound controls. The peer lane will add persistent roster state, signed broadcast delivery, bounded remote queries, relay and failover, log aggregation, forensic access, transport pinning, rate limits, quarantine, and protocol-version handling. Explicit enablement, whitelist and query authorization, key custody, and publication-safe topology gate distributed operation.

Promotion follows rejection tests for malformed, unsigned, expired, replayed, revoked, and context-mismatched traffic; rotation-overlap and signed-receipt evidence; end-to-end peer fixtures; rate-limit and quarantine checks; relay and failover exercises; roster persistence; log lineage; and a reproducible latency and load benchmark. Transport conveys authenticated evidence and requests while response authority remains with CIDS.

19.5Fleet and recovery expansion

Inventory-driven deployment surfaces, names-only runbooks, staged QuestFrames, and dated rollout records provide the present fleet foundation. The expansion will resolve an environment-backed inventory, run preflight checks, deploy the declared Sentry service set, verify service identity, observe stability over a declared window, append redacted per-node evidence, and close each deployment job with a retained outcome. Dated rollout records establish the configuration observed at their date; current fleet liveness follows the observation window owned by each rollout. [A40]

The fleet gate requires active services, stable heartbeat and relay behavior, zero duplicate spawns, zero authentication-mismatch events, and timeout and error rates measured over the declared window. Each abstract node class advances against its own retained promotion evidence.

TABLE 20 · Satellite and fleet rollout evidence matrix

Abstract node class	Declared service set	Verification	Observation window	Evidence status
Deployment controller	Inventory resolver, rollout coordinator, and evidence writer	Inventory identity, preflight outcome, authorization trace, and retained job closure	From inventory resolution through closure receipt	PLANNED
Satellite Sentry	Sentry lane, lane watchdog, and heartbeat/relay client	Service active, expected process identity, and zero duplicate spawns	Declared per-lane stability window after service verification	PLANNED
Fleet evidence observer	Read-only health, heartbeat, relay, and evidence collection	Heartbeat continuity, authentication-mismatch count, and timeout/error-rate evidence	Matched fleet window with expected heartbeat denominators	PLANNED

The emergency recovery lane follows peer hardening. It will expose a minimal allowlisted command set under signed requests, replay defense, append-only audit, and an explicit privileged-capability gate. Disabled is its standing posture; enablement, use, audit closure, and automatic return to that posture form one retained chain. Promotion requires standing-posture proof, unauthorized and replay rejection, a bounded command-set check, and a recovery drill with rollback evidence.

19.6Read-only intelligence and operator surfaces

The development dashboard carries IMPL for its tested records and manual response route, while its access-control layer carries PARTIAL. The expansion will give the Activity Stream contract one graduated-event representation and expose CIDS status, filesystem snapshots, and peer queries to ORACL as read-only, evidence-emitting tools with explicit availability state. CIDS whitelist policy will gate each request, evidence packets will retain attribution and source lineage, and ORACL will remain advisory.

The console will render persona-shaped operational views with freshness and staleness state, attributable activity, offline-safe assets, bounded paging, and evidence-linked controls. Capability checks and explicit confirmation will contain privileged actions while CIDS and the operator retain decision authority. Promotion follows availability-state fixtures, input and injection tests, schema and evidence-packet conformance, a read-only side-effect audit, authorization-matrix coverage, stale-data rendering, privileged-action audit evidence, offline-asset validation, accessibility checks, and narrow-width rendering. [A41]

19.7Repository and package extraction

CIDS currently resides inside the development-line CodeSentinel source boundary and exposes distinct enforcement, observation, transport, graph, console, and evidence contracts. Extraction will move those capabilities behind an independent CIDS source and package boundary while a CodeSentinel adapter preserves governed integration. Shared schemas, standalone operation, compatibility policy, migration manifests, and cross-repository evidence identifiers will keep authority and lineage stable across the transition. [A42]

CIDS and CodeSentinel will move the boundary artifacts as coordinated contracts. Each boundary surface stays PLANNED until its schema, adapter, standalone behavior, compatibility gate, and evidence lineage pass as one contract.

TABLE 21 · Repository-extraction interface matrix

Interface contract	CodeSentinel adapter	CIDS standalone behavior	Compatibility gate	Evidence lineage
Activity and evidence records PLANNED	Maps platform producers and consumers to the shared attributable-event schema	Emits, validates, redacts, and retains records under the same schema	Producer/consumer fixtures, schema-version policy, and redaction conformance	Stable event identity and evidence pointer
Authority and response candidates PLANNED	Preserves policy gates and routes candidate actions to CIDS authority	Owns enforcement decisions and retains request, receipt, and action lineage	Authority-effect tests, signed receipts, and unauthorized-mutation rejection	Linked request, receipt, decision, and action identifiers
Read-only status, snapshot, and query PLANNED	Exposes nullable, evidence-emitting interfaces to CodeSentinel and ORACL	Serves bounded status and evidence queries under CIDS whitelist policy	Adapter contract, input/schema validation, and explicit unavailable-state fixtures	Query identity and provenance-bearing evidence packet
Deployment and package boundary PLANNED	Binds compatible CIDS package identity through an integration manifest	Installs, operates, validates, and releases under an independent package lifecycle	CodeSentinel-only, CIDS-only, and combined test matrix plus migration manifest	Package version, migration record, and cross-repository evidence identifiers

Promotion requires CodeSentinel-only, CIDS-only, and combined test matrices; adapter contract tests; a migration manifest; package-compatibility evidence; and cross-reference validation over the shared evidence identifiers. The resulting boundary supports independent CIDS operation and preserves CodeSentinel's governed integration.

19.8Acceptance synthesis

All twelve CIDS expansion capabilities carry PLANNED. Their current foundations retain the owner statuses established in Sections 9-13, while each target advances through its own interface, security, acceptance-evidence, and migration-invariant gate. The dependency graph permits independent progress and keeps broader reach behind attributable evidence, transport assurance, and CIDS authority.

TABLE 22 · CIDS expansion dependencies and acceptance evidence

Capability	Present foundation	Planned delta	Dependency or gate	Acceptance evidence	Migration invariant	Status
Activity Stream and attribution	Component-local producers and draft shared contract	Canonical attributable events with redaction, freshness, and evidence pointers	Names-only publication and fail-closed visibility policy	Schema fixtures, producer/consumer conformance, redaction, freshness, and evidence-link tests	Attribution and source lineage remain stable across every producer and view	PLANNED
Sentry-Prime observability	Authoritative dashboard-embedded pipeline IMPL	Stable stage counters through ingress, transformation, forwarding, rejection, and latency	Canonical event schema and preprocessing identity	Deterministic fixtures, counter conservation, buffer bounds, sanitized runtime sample, and deployment identity	The authoritative pipeline identity and conserved event accounting remain fixed	PLANNED
Sentry Triad	Dual lanes and watchdogs LIVE; Cortex paths at owner status	Health exchange, differentials, restart analysis, candidate events, and lane attribution	Shared event schema, exact lane roles, and CIDS authority	Health/fallback tests, differential fixtures, integration contract, lane telemetry, and response-gate evidence	Lane identity remains attributable and CIDS retains final response authority	PLANNED
CaSTaP assurance	Context-bound envelope and key transport IMPL	Canonical identity, signatures, receipts, expiry, replay defense, risk classes, rotation, and revocation	Transport identity, key custody, whitelist, and risk policy	Malformed, unsigned, expired, replayed, revoked, and context-mismatch rejection plus rotation and receipt evidence	Fail-closed context binding, custody, and receipt lineage remain intact	PLANNED
Peer federation	Authenticated peer primitives PARTIAL; liveness UNRESOLVED	Persistent roster, signed broadcast, bounded query, relay/failover, aggregation, rate control, and quarantine	Assured transport, explicit enablement, query authorization, and publication-safe topology	End-to-end fixtures, signature/replay rejection, rate/quarantine tests, failover, persistence, lineage, and load benchmark	Peer identity, authorization, and signed evidence lineage survive routing changes	PLANNED
Bounded filesystem pull	Bounded snapshot primitive IMPL; remote integration PARTIAL	Authorized read-only pull, approved roots, evidence paths, caching, differentials, and budget reporting	Shared events, assured transport, and query authorization	Path, symlink, traversal, truncation, payload-size, and heartbeat-regression fixtures	Traversal stays bounded, results remain evidence references, and heartbeat remains independent	PLANNED
Multi-scope integrity graph	Local EdgeGraph drift observation LIVE	Scope policy, stable chunks, dirty-node recomputation, signed checkpoints, rollback, and backpressure	Canonical graph vocabulary, scope budgets, and atomic checkpoints	Root-hash reproducibility, interrupted-write recovery, host-scan prevention, delta benchmark, and schema compatibility	Stable node identity and atomic checkpoint semantics persist across scopes	PLANNED
Read-only ORACL tools	Graduated-event, data-source, and tool-interface designs	Evidence-emitting CIDS status, snapshot, and peer-query tools with explicit availability	Event and transport contracts, graph/query readiness, CIDS whitelist, and advisory authority	Availability fixtures, input/injection/schema tests, side-effect audit, and evidence-packet conformance	Interfaces remain read-only, nullable, provenance-bearing, and advisory	PLANNED
Console and operator evidence	Dashboard records and manual route IMPL; access layer PARTIAL	Persona views, freshness, contained privileged actions, offline assets, bounded paging, and evidence-linked controls	Shared events, Triad state, capability model, and endpoint-role separation	Authorization matrix, stale-data rendering, action audit, offline assets, accessibility, and narrow-width checks	Views inherit source authority; privileged action remains explicitly gated	PLANNED
Satellite and fleet rollout	Inventory-driven deployment surfaces and dated rollout records	Repeatable Sentry deployment, service verification, stability observation, and redacted node evidence	Environment inventory, preflight, shared events, and transport controls	Active services, heartbeat/relay stability, duplicate/auth counts, and timeout/error rates over a declared window	Abstract node identity and observation windows remain bound to retained rollout jobs	PLANNED
Emergency recovery lane	Bounded recovery-channel design	Minimal allowlisted signed channel with replay defense, audit, explicit enablement, and automatic return	Shared events, assured transport, privilege gate, and peer hardening	Standing-posture proof, rejection fixtures, bounded commands, audit chain, and rollback drill	Disabled remains the standing posture and every use remains attributable	PLANNED
CIDS package extraction	Embedded modules and an interface-preserving separation strategy	Independent package with stable schemas, CodeSentinel adapters, standalone operation, and compatibility policy	Interface stabilization, extraction map, and compatibility contract	CodeSentinel-only, CIDS-only, and combined matrices, adapter tests, migration manifest, and cross-reference validation	Authority, schemas, adapters, and cross-repository evidence identity remain stable	PLANNED

CIDS expansion therefore moves from attributable evidence through assured local and distributed controls to interface-stable extraction. Each promotion preserves the authority and lineage already established by the current system.

19.9ORACL and governed execution evolution

CodeSentinel currently computes advisory knowledge, compliance, and stability scores through the Section 6.4 model, equations (1)-(4), and carries an implemented stability-floor helper within that scoring foundation. ORACL's planned governance scalar will adjust those scores through normalized hot-snapshot observables x_i ∈ [0,1] and combine them as a policy gate:

The min(C′,S′) term is a conjunctive floor: compliance and stability must both support the resulting gate, and K′ scales that floor. Promotion requires a defined observable lattice, adjustment rules, consumer, reason codes, policy thresholds, provenance-bearing output, deterministic edge-case tests, and approval-path integration. G belongs to ORACL policy governance; Brain's planned environmental-health summary remains a distinct measure with a distinct owner. [A46]

ORACL will evolve across separable configuration, surface, service, and execution axes. Repo-native tool and server configuration will make VS Code a derived compatibility renderer rather than the canonical authority. Launcher-neutral task dispatch will let scheduled, continuous-integration, and agent-triggered work use CodeSentinel-owned execution without waiting for a Model Context Protocol (MCP) migration. These movements can promote independently. [A44][A45]

MCP service scenarios cover local desktop access, managed WAN/mobile connector access, and authenticated LAN or remote-node context. No topology is selected by design alone. Each placement advances through its own availability, transport, custody, offline, authentication, and recovery evidence. The planned ORACL MCP runtime will place authenticated health, signed liveness, names-only audit, a versioned tool/evidence packet, and a discoverable tool registry around the native platform. [A43]

MCP tools will separate read-only context and CIDS evidence access from sandboxed and explicitly authorized mutation. Text and path guards, deterministic schemas, bounded execution, and availability reporting govern every tool class. Mutating tools will invoke CodeSentinel's canonical job, filesystem, Git, and post-action gate surfaces; CIDS-domain requests remain advisory and pass through CIDS authority. This architecture creates no parallel writer or shadow enforcement path.

ORACL memory, the canonical job SSOT, local SessionMemory persistence, and ORACode/ORACall retrieval provide the present context foundation. Planned native evolution adds a launcher-neutral dispatcher, SSOT-first contextual selection, stale-plan rejection, explainable proposals, a service-hardened graph watcher, authenticated remote context, authorized agent loops, a supervised shell, and a restricted in-process terminal. The dispatcher, MCP service, connector paths, remote context, and terminal can mature in stages; operator approval and canonical mutation authority remain final throughout.

Brain PLANNED will extend ORACL with event-sourced long-horizon memory, an ORACode-shaped graph carrying typed relations and provenance, partitioned visibility, and a single bounded staged mutation interface. Governance mechanisms port by pattern. The architectural through-line joins CodeSentinel's canonical lifecycle writer, Brain's planned append-only authoritative history and staged mutation path, and an ORACode-shaped derived query substrate. [A47]

TABLE 23 · ORACL and platform-evolution dependencies and promotion evidence

Movement	Present foundation	Planned target and boundary	Dependencies	Acceptance evidence	Status
Derived ORACL governance gate	Current K/C/S computation and stability-floor helper IMPL	Compute G from a defined normalized-observable lattice as an ORACL policy gate distinct from Brain EHS	Observable lattice, adjustment rules, consumer, reason codes, thresholds, and approval authority	Conjunctive-floor and edge tests, provenance output, regime-consumer integration, approval, and unauthorized-mutation rejection	PLANNED
IDE-independent tool and MCP configuration	Workspace-oriented tool/MCP audit hooks IMPL; authority extraction PARTIAL	Make a repo-native tool/server catalog canonical and render VS Code configuration as derived compatibility output	Identity schema, ownership map, secret-reference split, compatible renderer, and audit migration	Canonical/rendered parity, editor-absent audit, multiple-server inventory, deterministic regeneration, secret-free output, and rollback	PLANNED
Launcher-neutral task execution	Native job, gate, filesystem, and Git surfaces IMPL; native-preference boundary PARTIAL	Dispatch scheduled, continuous-integration, and agent-triggered tasks without VS Code execution authority while retaining optional launchers	Exact task mapping, configuration SSOT, timeout policy, modular CLI seams, and compatibility window	Output/exit/evidence parity, editor-absent runs, derived-launcher validation, failure/timeout fixtures, and rollback	PLANNED
MCP service and connector scenarios	Local advisory ORACL LIVE; reusable service and security patterns IMPL	Evaluate independently gated local/desktop, managed-WAN/mobile, and LAN/remote-node service placements with authenticated health and audit	Threat model, protocol contract, signing custody, origin/transport policy, connector registration, and fallback model	Local-only operation, authentication/origin rejection, signed health, stale-heartbeat behavior, selected-connector checks, offline evidence, and no-open-port audit	PLANNED
MCP tools and governed agency	ORACL memory and job SSOT LIVE; ORACode/ORACall and native CLI surfaces IMPL	Versioned tool packets, registry discovery, guarded read-only and sandbox/live lanes, explainable context, and authorized agent execution	Stable schemas/reason codes, availability, CIDS evidence contracts, canonical mutation authority, and approval policy	Registry/schema conformance, fail-closed input tests, read-only audit, lane isolation, proposal fixtures, post-action gate/rollback, and unauthorized-mutation rejection	PLANNED
Persistent semantic and remote context	Foreground graph watcher IMPL; local SessionMemory persistence and retrieval LIVE	Service-harden graph watching and add authenticated, freshness-bound, provenance-validated remote context before cross-node sessions	Watcher-role reconciliation, bounded subprocesses, lifecycle ownership, remote trust/custody, and merge policy	Restart/recovery, duplicate-instance and bounded-rebuild tests, stale/corrupt rejection, authenticated round-trip, and no-authority-transfer evidence	PLANNED
Terminal-native governed operation	Broad CodeSentinel CLI and command-owned mutation surfaces IMPL	Evolve through a supervised shell toward a restricted in-process terminal using the existing command, evidence, policy, and mutation authorities	CLI modularity, callable entry point, command allowlist, transcript redaction, portability, and rollback boundaries	In-process parity, disallowed-command rejection, terminal fixtures, redacted evidence, deterministic help/completion, and native policy/gate parity	PLANNED
Distributed configuration and secret authority	VAULT custody LIVE; managed-environment controls IMPL with a PARTIAL detection edge	Split secret and non-secret contracts, establish EDGE remote authority, retain encrypted bounded fallback, and validate network-first startup	Threat model, source-role split, CIDS stability, cache integrity/expiry, rotation/revocation, and offline recovery	Remote-unavailable fallback, tamper/expiry/revocation rejection, rotation overlap, authority trace, secret-free logs, and rollback drill [A48]	PLANNED
Governed release and evidence control	Ship verification, packaging, offline install, derived configuration/documentation, and report tooling IMPL	Unify ship, package, and publish through release-definition packets, scoped executors, signed request/receipt artifacts, and evidence bundles	Accepted policy, channel/authority model, signing custody, IDE-independent configuration, reproducible rendering, and rollback	Signed verification, least privilege, tamper/replay rejection, channel matrix, artifact parity, deterministic outputs, rollback, and evidence-bundle validation [A49]	PLANNED
ORACode storage evolution	Mirror-v2 indexes, fast-path search, and dedicated ORACode evidence IMPL	Measured sharding, compaction/rotation, publish/rollback rules, and an optional gated storage rung	Baseline and bottleneck evidence, stable schema/provenance, compatibility boundary, and storage-rung gate	Benchmark, shard routing/integrity, interrupted-compaction recovery, retention, publish/rollback, backend parity, and current metrics packet [A50]	PLANNED

Brain's detailed PLANNED architecture is available in the Brain 2 Reference Manual; its research framing is available in the Brain 2 research-fair poster.

20Conclusion

CodeSentinel joins repository observation, policy evaluation, explicitly authorized execution, retained state, and reconstructable evidence into a governed operating loop. Observations enter protected state domains with attributable context; lifecycle supervision and policy gates bound consequential action; canonical job state governs permitted mutations; and dashboards, metrics, and indices project derived evidence. Automation acquires operational meaning through that chain of bounded authority and evidence-bearing outcomes.

ORACL supplies memory, evidence lineage, and advice while CIDS owns network-security decisions and enforcement. Calamum contributes independent adversarial validation, and ORACode contributes semantic retrieval and provenance traversal. Their coordination rests on explicit interfaces and retained evidence: each subsystem preserves its own authority, hands off attributable records, and contributes within its assigned decision rights.

Technical confidence follows the same discipline. Evidence retains the scope established at its owner surface, while public and development surfaces retain their distinct meanings. Each claim is bounded by the named surface, observation, test, or record that makes it reproducible. CodeSentinel's durable value is traceable authority: what the system observed, what governed the decision, what action was permitted, and what evidence survives for reconstruction.

---

AAppendix A · Internal Source Map

Repository-relative sources are grouped by claim owner and evidence class. Implementation, tests, dated deployment records, architecture, and forward design remain separate so that a source supports only the inference its own evidence class permits.

• Platform, security, and operations

• [A1]pyproject.toml, setup.py, and codesentinel/__init__.py — Implementation evidence. Sections 2 and 16 and TABLE B1; package identity, active-source version, Python floor, and declared entry points.
• [A2]codesentinel/core/__init__.py — Implementation evidence. Section 3; runtime composition, degraded construction, and lifecycle ownership.
• [A3]codesentinel/utils/file_integrity.py and codesentinel/cli/integrity_utils.py — Implementation evidence. Section 4; repository baseline, verification, critical-file handling, and rebaseline authority.
• [A4]codesentinel/utils/ops_tasks_registry.py, codesentinel/cli/job_utils.py, codesentinel/utils/job_controls.py, codesentinel/utils/job_status.py, and operations/tasks.json — Implementation evidence. Sections 4 and 6; canonical task-state integrity, lifecycle mutation, recovery lineage, and current state authority.
• [A5]tests/test_integrity.py, tests/test_integrity_monitor.py, tests/test_file_integrity_exclusions.py, tests/utils/test_ops_tasks_registry_integrity.py, and tests/utils/test_ops_tasks_registry_archive.py — Test evidence. Sections 4 and 6; protected repository/task-state behavior and archive recovery.
• [A6]codesentinel/core/vault_guardian.py, codesentinel/core/vault_loader.py, codesentinel/core/vault.py, codesentinel/core/env_ssot.py, and codesentinel/cli/vault_utils.py — Implementation evidence. Section 4; VAULT custody, names-only environment validation, bounded authorization, and audit history.
• [A7]tests/test_vault_guardian.py and tests/cli/test_vault_utils.py — Test evidence. Section 4; custody, lock, authorization, and credential-operation boundaries.
• [A8]codesentinel/utils/venv_broker.py, codesentinel/utils/venv_registry.py, codesentinel/utils/venv_manifest.py, codesentinel/utils/venv_policy.py, and codesentinel/cli/venv_utils.py — Implementation evidence. Sections 4 and 16; managed-environment inventory and script-execution trust.
• [A9]codesentinel/utils/can_destroy_policy.py, codesentinel/utils/path_policy.py, codesentinel/utils/safe_edit.py, codesentinel/cli/fs_utils.py, and codesentinel/cli/edit_utils.py — Implementation evidence. Sections 3 and 4; destructive-action classification, archive-first mutation, staged verification, rollback, and cleanup.
• [A10]tests/test_venv_broker.py, tests/test_safe_edit.py, and tests/cli/test_fs_utils.py — Test evidence. Section 4; managed-environment and recoverable-mutation controls.
• [A11]codesentinel/utils/scheduler.py, codesentinel/utils/archive_maintenance_scheduler.py, codesentinel/utils/process_monitor.py, codesentinel/utils/process_watchdog.py, codesentinel/utils/alerts.py, codesentinel/utils/mode_manager.py, codesentinel/utils/automation_retention.py, and codesentinel/utils/inactivity_listener.py — Implementation evidence. Section 5; cadence, archive work, supervision, bounded commands, alert routing, posture, retention, and inactivity control.
• [A12]tests/test_scheduler_guardrails.py, tests/test_process_monitor.py, and tests/test_process_watchdog.py — Test evidence. Section 5; scheduler and process-supervision guardrails.
• [A13]codesentinel/utils/policy_lookup.py, codesentinel/utils/policy_router.py, codesentinel/utils/policy_guard.py, codesentinel/utils/policy_enforcer.py, codesentinel/utils/policy_signer.py, and codesentinel/cli/policy_utils.py — Implementation evidence. Section 6; policy lookup, advisory routing, blocking authority, assurance, and remediation.
• [A14]codesentinel/cli/gate_utils.py, codesentinel/cli/day_utils.py, codesentinel/utils/gate_guards.py, and codesentinel/utils/gate_exit_codes.py — Implementation evidence. Section 6; lifecycle gate order, guard policy, repair boundary, and outcome semantics.
• [A15]tests/cli/test_job_utils.py, tests/cli/test_job_ssot.py, and tests/cli/test_gate_utils.py — Test evidence. Section 6; canonical job-state and lifecycle-gate behavior.
• [A16]codesentinel/utils/dashboard_manager.py, codesentinel/cli/dashboard_utils.py, codesentinel/cli/report_utils.py, codesentinel/utils/metrics_wrapper.py, codesentinel/utils/completion_tracker.py, codesentinel/utils/non_agent_reporter.py, codesentinel/utils/docs_manifest.py, and codesentinel/utils/manifest_registry.py — Implementation evidence. Sections 6 and 17 and Appendix E; derived dashboards, metrics, reports, manifests, registry resolution, and evidence discovery.
• [A17]docs/SHIP_MANIFEST.json and docs/schemas/SHIP_MANIFEST.json — Implementation evidence. Section 16; bounded shipping inventory and schema contract.
• [A18]codesentinel/cli/__init__.py — Implementation evidence. Sections 3-7 and TABLE B2; registered top-level command taxonomy and help grouping.
• [A19]tests/cli/test_main_help_layout.py — Test evidence. TABLE B2; visible group order, membership, and layout.

• ORACL and governed context

• [A20]codesentinel/utils/session_memory.py, codesentinel/cli/memory_utils.py, and codesentinel/utils/manifest_registry.py — Implementation evidence. Sections 6 and 7; tiered context, QuestStack continuity, persistence, expiry/freeze controls, and manifest linkage.
• [A21]tests/test_session_memory_workflow.py, tests/test_session_memory_persistence_regressions.py, and tests/test_session_memory_guard.py — Test evidence. Section 7; SessionMemory workflow, persistence, and guard behavior.
• [A22]codesentinel/utils/kcs_scoring.py, codesentinel/utils/kcs_metrics.py, codesentinel/utils/behavioral_pipeline.py, and codesentinel/cli/behavioral_cli.py — Implementation evidence. Sections 6, 7, and 19; K/C/S computation, stability-floor logic, behavioral evidence, and publication gating.
• [A23]tests/manual/test_kcs_calculation.py, tests/cli/test_behavioral_cli_command.py, and tests/cli/test_behavioral_artifacts_pairing.py — Test evidence. Sections 6 and 7; K/C/S and paired behavioral-artifact validation.
• [A24]docs/architecture/general/ORACL_MEMORY_ARCHITECTURE.md, docs/architecture/oracl/ORACL_INTEGRATION_ARCHITECTURE.md, and docs/architecture/general/ORACL_CENTRALIZED_INDEX_PROPOSAL.md — Architecture evidence. Sections 7, 17, and 19; memory tiers, advisory orchestration, confidence flow, and evidence-index boundaries.
• [A25]docs/reports/security/ORACL_CIDS_SEAM_ANALYSIS.md — Architecture evidence. Sections 7-8 and 19; ORACL advice, CIDS enforcement, and coordination boundaries.
• [A26]codesentinel/cli/oracode_utils.py, codesentinel/cli/oracall_utils.py, codesentinel/utils/oracode_context_overlay.py, codesentinel/utils/oracall_signer.py, and tools/oracode/graph_watcher.py — Implementation evidence. Sections 7 and 15 and TABLE 23; semantic retrieval, context overlay, signed linkage, and the foreground graph watcher.
• [A27]tests/oracall/test_linkage_regression.py, tests/cli/test_oracall_search.py, and tests/cli/test_oracode_graph_rebuild_cli.py — Test evidence. Sections 7 and 15; ORACall/ORACode linkage, search, and graph-rebuild behavior.

• CIDS authority and implementation

• [A28]docs/architecture/security/CIDS_SPEC.md and projects/oracl/_extracted/CIDS_CONSOLIDATION_ANALYSIS_20260606.md — Architecture evidence. Sections 8-13; CIDS authority, embedded ownership, and component boundaries.
• [A29]docs/reports/CIDS_ECOSYSTEM_ARCHITECTURE_REPORT.md and docs/reports/CIDS_ECOSYSTEM_OPERATIONAL_ARCHITECTURE.md — Architecture evidence. Sections 8-13; entity, data-flow, operational-plane, and historical topology context.
• [A30]services/network_router/cids/cids_daemon.py, services/network_router/cids/cids_daemon_optimized.py, services/network_router/cids/cids.service, services/network_router/cids/deploy_cids.sh, and services/network_router/cids/deploy_hardening.sh — Implementation evidence. Sections 8-9; enforcement variants, service identity, and installation boundary without deployment inference.
• [A31]services/network_router/cids/sentry/cids_sentry.py, services/network_router/cids/sentry/sentry_prime.py, services/network_router/cids/sentry/sentry_cortex.py, services/network_router/cids/cids_graph_agent.py, services/network_router/cids/cids_graph_agent_windows.py, and services/network_router/cids/sentry/filesystem_snapshot.py — Implementation evidence. Sections 9-10; Sentry lanes, preprocessing, correlation, graph intelligence, and bounded filesystem snapshots.
• [A32]services/network_router/cids/sentry/cids_security.py, services/network_router/cids/dashboard/cids_security.py, and services/network_router/cids/sentry/p2p_handler.py — Implementation evidence. Section 11; CaSTaP, CalamumUplink, and P2P primitives without current-mesh inference.
• [A33]services/network_router/cids/dashboard/app.py, services/network_router/cids/dashboard/sentry_prime.py, services/network_router/cids/cids_honeypot.py, services/network_router/cids/cids_killswitch.py, services/network_router/cids/integrity/nexus_guard.py, and services/network_router/cids/integrity/cids_recovery_manager.py — Implementation evidence. Sections 10-12; console ingress/read surfaces, embedded preprocessing, response, and integrity/recovery controls.
• [A34]services/sentry_watchdog/watcher.py, services/network_router/cids/sentry/cids_sentry_watchdog.ps1, deployment/systemd/cids_sentry_watchdog.service, deployment/systemd/cids_sentry_watchdog@brain.service.d/override.conf, and deployment/systemd/cids_sentry_watchdog@edge.service.d/override.conf — Implementation evidence. Sections 9 and 11; watchdog logic, platform lanes, and instance configuration.
• [A35]tests/test_cids_hardening.py, tests/test_sentry_watchdog_module.py, and tests/test_sentry_watchdog_integration.py — Test evidence. Sections 9, 11, and 13; CIDS hardening and watchdog controls.
• [A36]docs/reports/deployment/DEPLOYMENT_VERIFICATION_20251208.md — Dated deployment record. 2025-12-08; Sections 8, 12, and 13; bounded rollout, honeypot, and enforcement evidence for that observation date.

• Forward-design sources

• [A37]docs/operations/plans/PHASE3_SENTRY_TRIAD_PLAN_20251211.md and docs/operations/plans/PHASE7_SENTRY_WATCHDOG_PLAN_20251211.md — Plan/specification evidence. Sections 9, 11, 13, and 19; dated Triad/watchdog role and validation design without present-liveness promotion.
• [A38]docs/operations/contracts/CIDS_ACTIVITY_STREAM_CONTRACT_V0.md and docs/operations/contracts/CIDS_ACTIVITY_STREAM_CONTRACT_V0.json — Plan/specification evidence. Section 19 and FIG. 21; planned event, attribution, redaction, and evidence-pointer contract.
• [A39]docs/operations/ssot/CIDS_MULTISCOPE_INTEGRITY_GRAPH_STRATEGY_SSOT_20260220.md — Plan/specification evidence. Section 19 and FIG. 22; planned multiscope integrity, chunking, checkpoint, budget, and federation boundaries.
• [A40]docs/operations/queststacks/QS-OPS-CIDS-SATELLITE-ROLLOUT-20251216.md — Plan/specification evidence. Section 19 and FIG. 23; staged fleet rollout, observation windows, and stability acceptance.
• [A41]docs/reports/ui/DASHBOARD_MULTI_PAGE_REFACTOR_WIREFRAMES_20251229.md — Plan/specification evidence. Section 19; planned console information architecture, persona views, privilege containment, and operator evidence surfaces.
• [A42]docs/architecture/CIDS_SEPARATION_STRATEGY.md — Plan/specification evidence. Section 19 and FIG. 24; planned repository/package extraction and compatibility boundary.
• [A43]projects/oracl/_extracted/ORACL_FULL_SYNTHESIS_20260606.md and projects/oracl/_extracted/ORACL_SURFACE_EXPANSION_PLAN_v1.2_20260606.md — Plan/specification evidence. Section 19 and TABLE 23; ORACL surface, MCP, connector, governed-agency, continuity, and terminal scenario families.
• [A44]jobs/CORE_JOB_0005_CODESENTINEL-CORE_PLAN_PATH-TO-FULL-AGENCY_20260303/legacy/CORE_JOB_0005_CODESENTINEL-CORE_PLAN_PATH-TO-FULL-AGENCY_20260303.md and jobs/OPS_JOB_0110_IDE_AGNOSTIC_TOOLS_CONFIG_SSOT_20251228/legacy/OPS_JOB_0020_IDE_AGNOSTIC_TOOLS_CONFIG_SSOT.md — Plan/specification evidence. Section 19 and TABLE 23; launcher-neutral execution and repository-owned tool/MCP configuration authority.
• [A45]docs/reports/operations/CODESENTINEL_NATIVE_TOOL_PREFERENCE_AUDIT_20260327.md — Architecture evidence. Section 19 and TABLE 23; present native-tool routing and the boundary of the broader independence program.
• [A46]docs/metrics/reports/KCS_COEFFICIENT_CALCULATION_AT_A_GLANCE.md and docs/operations/plans/ORACL_ADVICE_TELEMETRY_PIPELINE_INTEGRATION_BRIEF_20251215.md — Plan/specification evidence. Section 19 and equation (13); the proposed governance scalar and its advisory-consumer boundary.
• [A47]brain/docs/manuals/BRAIN2_REFERENCE_MANUAL/04-ENVIRONMENTAL_HEALTH_SCORING_AND_CAPABILITY_VIEW.md, brain/docs/manuals/BRAIN2_REFERENCE_MANUAL/05-REFERENCE_ARCHITECTURE.md, brain/docs/manuals/BRAIN2_REFERENCE_MANUAL/07-EVENT_SOURCED_MEMORY_MODEL.md, brain/docs/manuals/BRAIN2_REFERENCE_MANUAL/08-FLASHDELTAMANIFEST_ONLY_WRITE_PATH.md, brain/docs/manuals/BRAIN2_REFERENCE_MANUAL/09-BRAIN2_MEMORY_GRAPH_ORACODE_SHAPED.md, and brain/docs/manuals/BRAIN2_REFERENCE_MANUAL/21-KNOWN_GAPS_DESIGN_INTENDED_NOT_YET_EVIDENCED.md — Plan/specification evidence. Section 19 and TABLE 23; planned environmental health, event-sourced memory, typed provenance, bounded mutation, and known-gap boundaries.
• [A48]docs/operations/plans/ENV_SSOT_NETWORK_PRIMARY_20251227.md — Plan/specification evidence. Section 19 and TABLE 23; distributed configuration/secret authority and bounded offline behavior.
• [A49]jobs/JOB_0027_CODESENTINEL-CORE_PLAN_DOCS-GENERAL_20260503/CODESENTINEL_SHIP_PUBLICATION_POLICY_REPLACEMENT_SCRATCHPAD_20260503.md — Plan/specification evidence. Section 19 and TABLE 23; governed release-definition, request/receipt, evidence-bundle, and rollback design.
• [A50]docs/operations/plans/ORACODE_SQLITE_MIRROR_V2_PROPOSAL_20251218.md — Plan/specification evidence. Section 19 and TABLE 23; ORACode storage, mirror, compaction, compatibility, and rollback evolution.

BAppendix B · Package and Entry-Point Metadata

Package metadata establishes declared identity and discoverability. Target resolution, runtime execution, and public availability remain separate evidence questions.

TABLE B1 · Package and entry-point metadata

Surface or entry point	Declared identifier / target	Availability	Status	Technical role / evidence boundary
Package identity and Python floor	codesentinel · >=3.8	PyPI GH DEV	IMPL	Declared package and interpreter-compatibility metadata; not proof of every interpreter/platform combination
PyPI release	1.1.1	PyPI	IMPL	Downloadable lean-core package artifact
Public GitHub release	1.1.3.b1 + hotfix2	GH	IMPL	Lean public-source and tag lineage; hotfix identity remains distinct from the version string
Active source	1.1.5	DEV	IMPL	Unpublished integration metadata
Primary CLI	codesentinel = codesentinel.cli:main	PyPI GH DEV	IMPL	Operational entry point; command availability remains surface-scoped
Setup CLI	codesentinel-setup = codesentinel.launcher:main	DEV	IMPL	Declared target resolves in active source; no aggregate cross-platform execution claim
Setup GUI	codesentinel-setup-gui = codesentinel.gui_launcher:main	DEV	UNRESOLVED	Declared target does not resolve; the differently located GUI implementation is not equivalent wiring

TABLE B2 · Top-level CLI group-to-capability crosswalk

CLI group	Top-level commands	Count	Architectural owner	Availability / status boundary	Appendix treatment
Core operations	status, scan, clean, fs, search, git	6	Sections 3-5	PyPI GH DEV · IMPL / PARTIAL	Names only; runtime, scan, cleanup, filesystem/search, and trust behavior remain with the owner sections
Governance & lifecycle	day, gate, job, dashboard, reports, plan, ops, integrity, memory, policy	10	Sections 4-7 and 17	DEV · IMPL / PARTIAL	Registration does not imply that every command mutates canonical state
Knowledge & documentation	docs, index, format, pdf, tags	5	Section 17 and Appendix E	DEV · IMPL	Evidence discovery is retained; formatting, PDF, and tag helpers remain non-architectural utilities
ORACode & agent surfaces	oracall, oracode, agents, advise, behavioral, learn, insight, workbench, edit, feedback	10	Sections 6, 7, and 15	DEV · IMPL / PARTIAL	Advisory/retrieval roles remain distinct from canonical job and CIDS authority; lab surfaces gain no architectural status
Runtime, setup & release	ship, vault, credentials, venv, update, integrate, setup, flash	8	Sections 4 and 16	DEV · IMPL / PARTIAL	Custody, environment, and release behavior remain owner-scoped; setup/integration helpers create no independent architecture claim
Diagnostics, GUI & labs	sim, maintenance, alert, schedule, test, dev-audit, gui, apex, benchmark, wagonwheel, metrics	11	Sections 4-5	DEV · IMPL / PARTIAL / UNRESOLVED	Included maintenance, alert, and audit roles retain owner status; simulator, GUI, Apex, benchmark, and WagonWheel remain metadata-only or non-architectural
Total	Distinct registered top-level names	50	Owner sections above	Per-command evidence only	No group-level execution, public-availability, or support inference

CAppendix C · CIDS Component, Service, and Interface Crosswalk

CIDS remains an embedded DEV subsystem. Its implementation, service, node-class, and interface identities resolve to the status and authority boundaries established in Sections 8-13; route or source presence alone supplies no liveness inference.

TABLE C1 · CIDS component, service, node, and status crosswalk

Component or lane	Canonical implementation	Service / process identity	Node class	Authority / evidence role	Status / date qualifier	Owner
Active-neutralization enforcement	services/network_router/cids/cids_daemon.py	cids.service	Edge / router	Evaluates admission policy and executes CIDS neutralization	LIVE · observed 2026-07-16	Sections 8-9
Monitor-only daemon	services/network_router/cids/cids_daemon_optimized.py	Selectable alternative build	Edge / router	Observes and evaluates with neutralization withheld	IMPL · no live-service inference	Section 9
Internal Sentry lane	services/network_router/cids/sentry/cids_sentry.py	cids-sentry@internal.service	Edge	Internal awareness, monologue, and Cortex feed; no enforcement authority	LIVE · observed 2026-07-16; role dated 2025-12-11	Sections 8-9
External Sentry lane	services/network_router/cids/sentry/cids_sentry.py	cids-sentry@external.service	Edge	External ingress validation and forwarding; no enforcement authority	LIVE · observed 2026-07-16; role dated 2025-12-11	Sections 8-9
Internal-lane watchdog	services/network_router/cids/sentry/cids_sentry_watchdog.ps1	cids_sentry_watchdog@internal.service	Edge	Probes and performs bounded restart of the internal lane only	LIVE · observed 2026-07-16; integration dated 2025-12-11	Section 9
External-lane watchdog	services/network_router/cids/sentry/cids_sentry_watchdog.ps1	cids_sentry_watchdog@external.service	Edge	Probes and performs bounded restart of the external lane only	LIVE · observed 2026-07-16; integration dated 2025-12-11	Section 9
Dashboard-embedded Sentry-Prime	services/network_router/cids/dashboard/sentry_prime.py	cids-dashboard.service in-process pipeline	Edge	Authoritative normalization, correlation, enrichment, deduplication, and forwarding pipeline	IMPL · tested 2026-07-18; inactive/unwired	Sections 10, 13
Standalone Sentry-Prime coordinator	services/network_router/cids/sentry/sentry_prime.py	Standalone coordinator application	Coordinator	Heartbeat, roster, and health surface; distinct from the embedded pipeline	PARTIAL	Sections 10-11
SentryCortex	services/network_router/cids/sentry/sentry_cortex.py	Lane-local in-process store	Edge / satellite	Semantic telemetry state and local queries; advisory only	IMPL · graph load 2026-02-11; bounded probe 2026-07-18	Sections 10, 13
EdgeGraph Linux agent	services/network_router/cids/cids_graph_agent.py	cids-graph-agent.service	Edge	Local file, port, and neighbor drift observation	LIVE · observed 2026-07-16	Sections 10, 13
EdgeGraph Windows sibling	services/network_router/cids/cids_graph_agent_windows.py	Implementation sibling	Windows host	Platform sibling of the local drift agent; no service-liveness inference	IMPL	Section 10
Filesystem snapshot primitive	services/network_router/cids/sentry/filesystem_snapshot.py	Bounded in-process primitive	Edge / satellite	Read-only, capped metadata capture, compression, and restore	IMPL · exercised 2026-07-18	Sections 10, 13
Remote filesystem query integration	services/network_router/cids/sentry/p2p_handler.py	Peer query handler; Sentry initializer pending	Satellite	Authority-neutral query transport around the bounded primitive	PARTIAL · inspected 2026-07-18	Sections 10-11, 18
Canonical CaSTaP / CalamumUplink	services/network_router/cids/sentry/cids_security.py	CIDS transport library	CIDS nodes	Context-bound packet sealing and fail-closed transport authority	IMPL · 5/5 hardening checks 2026-07-18; inactive/unwired	Sections 8, 11, 13
Dashboard CaSTaP consumer copy	services/network_router/cids/dashboard/cids_security.py	cids-dashboard.service consumer	Edge	Byte-identical consumer copy; never a second protocol authority	IMPL · inherits canonical transport behavior only	Section 11
P2P handler/coordinator primitives	services/network_router/cids/sentry/p2p_handler.py	Authenticated peer Blueprint	Peer / coordinator	Query, broadcast, roster, registration, and heartbeat primitives	PARTIAL · tested on or before 2026-05; current mesh UNRESOLVED	Sections 11, 13, 18
Browser dashboard application	services/network_router/cids/dashboard/app.py	cids-dashboard.service	Edge	Evidence ingress, status rendering, records, and privileged manual response	IMPL · tested 2026-07-18; inactive/unwired	Sections 11-13
Dashboard read/access layer	services/network_router/cids/dashboard/app.py	cids-dashboard.service read boundary	Edge	Shapes reader access to dashboard views	PARTIAL · probed 2026-07-18	Sections 12, 18
Honeypot	services/network_router/cids/cids_honeypot.py	cids-honeypot.service	Edge / router	Bounded trap, intrusion evidence, and source neutralization	LIVE · observed 2026-07-16	Sections 12-13
VPN killswitch	services/network_router/cids/cids_killswitch.py	cids-killswitch.service	Edge / router	Watches the tunnel; service liveness and operating mode remain separate claims	LIVE · observed 2026-07-16; logging mode dated 2026-02-15	Sections 12-13
Nexus integrity guard	services/network_router/cids/integrity/nexus_guard.py	nexus-guard.service	Edge / router	Compares held references, restores drifted files, and restarts mapped services	LIVE · observed 2026-07-16	Sections 12-13
Recovery manager	services/network_router/cids/integrity/cids_recovery_manager.py	Recovery-manager process	Edge / router	Bounded escalation with component-local incident evidence	LIVE · observed 2026-07-16	Sections 12-13
Inventory-driven fleet deployer	deployment/deploy_fleet.py	Inventory-backed deployment process	Fleet control	Present source foundation for the X10 rollout contract; not a current deployment	PLANNED	Section 19

TABLE C2 · CIDS endpoint, message, and authority crosswalk

Interface family	Route or contract	Method / direction	Producer → consumer	Authentication / context control	Authority effect	Status	Owner
Relay health	/api/sentry_relay/health	GET	Dashboard relay → health reader	No verified gate	Reports relay state; no mutation or enforcement authority	IMPL · inactive application	Sections 10-11
Sentry relay ingress	/api/sentry_relay	POST · inbound	Satellite Sentry → embedded Prime	Bearer check plus CaSTaP context binding	Transforms and forwards evidence only	IMPL · tested/inactive	Sections 10-11
Heartbeat ingress	/api/heartbeat	POST · inbound	Satellite/relay → dashboard store	Bearer check plus CaSTaP context binding	Updates evidence/cache state; no enforcement authority	IMPL · tested/inactive	Sections 11-12
Status and event reads	/api/status, /api/graph_metrics, /api/monologue, /stream	GET / SSE · outbound	Dashboard stores → console reader	Read-view/access layer remains incomplete	Derived read-only views; source records retain authority	IMPL routes · access PARTIAL	Section 12
Filesystem-map reads	/api/fs_map, /api/fs_map/<mac>	GET · outbound	Dashboard cache → authorized reader	Bearer check	Read-only bounded snapshot access	IMPL routes; remote producer integration PARTIAL	Sections 10, 12, 18
Manual response	/api/kill	POST · privileged	Authorized console → CIDS response path	Bearer check and explicit operator gate	Executes a privileged response under CIDS/operator authority	IMPL · inactive application	Sections 8, 12
Peer query	/api/p2p/query	POST · peer request	Authorized peer → Sentry handler	Bearer/persona check plus HMAC	Returns bounded read data; authority-neutral	PARTIAL	Sections 10-11
Peer broadcast	/api/p2p/broadcast	POST · peer fan-out	Authorized peer → roster members	Bearer/persona check plus HMAC	Attempts evidence delivery; roster count is not delivery proof	PARTIAL	Section 11
Peer roster	/api/p2p/roster	GET · peer read	Authorized peer → coordinator state	Bearer/persona check plus HMAC	Reads process-scoped coordination state	PARTIAL	Sections 11, 13
Peer registration	/api/p2p/register	POST · peer control	Peer → coordinator	Bearer/persona check plus HMAC	Registers process-scoped peer state; no enforcement authority	PARTIAL	Section 11
Peer heartbeat	/api/p2p/heartbeat	POST · peer control	Peer → coordinator	Bearer/persona check plus HMAC	Refreshes process-scoped liveness evidence	PARTIAL; mesh liveness UNRESOLVED	Sections 11, 13, 18
Coordinator heartbeat	/api/heartbeat	POST · inbound	Satellite Sentry → standalone Prime	Bearer check	Normalizes, caches, and forwards advisory evidence	PARTIAL	Sections 10-11
Coordinator roster	/api/p2p/roster	GET · outbound	Standalone Prime → authorized Sentry	Bearer check	Reads the coordinator's process-local roster	PARTIAL	Section 11
Coordinator health	/health	GET	Standalone Prime → health reader	No verified gate	Reports process health only	PARTIAL	Section 11

DAppendix D · CIDS Evidence and Validation Ledger

CIDS evidence retains the observation date and evidence class attached to each claim. Current service observations, historical deployment records, focused probes, and derived views remain independently scoped; a newer date elsewhere does not refresh an older claim.

TABLE D1 · Dated CIDS capability-evidence ledger

Capability	Evidence class	Date / window	Evidence statement	Supported status / claim	Freshness / inference boundary	Owner
Router active neutralization	Operator observation	2026-07-16	The enforcement service was observed in active use on the enforcement host.	LIVE enforcement	Supports the observed service and authority assignment, not another component's liveness.	Sections 8-9, 13
Router intrusion response	Dated deployment record	2025-12-06	A bounded router response event corroborated the active-neutralization path.	Dated enforcement behavior	Event evidence supports that response only; current state follows the 2026-07-16 observation.	Sections 9, 13
Internal and external Sentry lanes	Operator observation	2026-07-16	Both separated telemetry lanes were observed live.	LIVE lanes	Does not establish dashboard, transport, or peer-mesh liveness.	Sections 8-9, 13
Paired lane watchdogs	Operator observation	2026-07-16	One watchdog per Sentry lane was observed live.	LIVE supervision	Liveness does not characterize recovery-time distributions.	Sections 9, 13
Lane roles and deployment identity	Dated deployment record	2025-12-11	Internal/external role separation and per-lane supervision wiring were recorded.	Dated role/deployment evidence	The record establishes purpose and topology at that date; current liveness comes from 2026-07-16.	Sections 9, 13
Watchdog recovery path	Automated test	2025-12-11	An integration run recorded 5/5 checks across the bounded lane-recovery paths.	IMPL recovery behavior	Pass count establishes exercised behavior, not duration, reliability, or load response.	Sections 9, 11, 13
BRAIN/admin satellite path	Dated deployment record	2025-12-11	Satellite classes and their sealed telemetry roles were corroborated in the retained rollout record.	Dated deployment/role evidence	No current satellite or watchdog liveness follows without a current observation.	Sections 8, 11
EdgeGraph Linux agent	Operator observation	2026-07-16	The drift-observation service was observed in active use.	LIVE observation	Supports the Linux service only; the Windows sibling remains IMPL.	Sections 10, 13
SentryCortex graph context	Runtime probe	2026-02-11	The ORACode-backed graph loaded for the local semantic store.	IMPL graph load	One graph load does not establish continuous lane initialization or service liveness.	Sections 10, 13
Sentry-Prime preprocessing	Runtime probe	2026-07-18	A bounded run normalized telemetry, added preprocessing provenance, and suppressed a repeated alert signature.	IMPL when invoked	The hosting dashboard remained inactive/unwired in working 1.1.5.	Sections 10, 13
SentryCortex local queries	Runtime probe	2026-07-18	An in-memory run ingested telemetry, retained process state, and returned database-backed query classes.	IMPL local query behavior	Bounded process scope; no deployment or continuous-initialization inference.	Sections 10, 13
Filesystem snapshot	Runtime probe	2026-07-18	A capped metadata tree was captured, compressed, and restored to its original structure.	IMPL bounded primitive	Does not establish active remote-query integration or scaling behavior.	Sections 10, 13
CaSTaP fail-closed behavior	Runtime probe	2026-07-17	The sealed transport functioned under test and rejected nonconforming context.	IMPL functional transport	The transport and dashboard path remained inactive/unwired in working 1.1.5.	Sections 8, 11, 13
CaSTaP hardening controls	Automated test	2026-07-18	The focused hardening suite recorded 5/5 checks.	IMPL tested controls	Separate from the 2025-12-11 watchdog checks and from operational deployment.	Sections 11, 13
P2P back-channel primitives	Runtime probe	On or before 2026-05	A CaSTaP-gated mesh exercise succeeded across authenticated peer primitives.	PARTIAL tested primitives	Current mesh liveness remains UNRESOLVED; broadcast roster count is not delivery proof.	Sections 11, 13, 18
Dashboard and Sentry-Prime path	Runtime probe	2026-07-17	The dashboard/relay path was functionally exercised.	IMPL tested application path	The application remained inactive/unwired in working 1.1.5.	Sections 10-13
Dashboard records and manual response	Implementation inspection	2026-07-18	Record families and the explicitly gated manual response route were inspected with a bounded read probe.	IMPL routes; read layer PARTIAL	Route existence does not inherit live router-enforcement status.	Sections 12-13, 18
Derived dashboard snapshot	Derived evidence view	2026-02-15	A retained dashboard view recorded the state presented by its source records.	Dated derived state	The view inherits source scope and cannot supersede newer direct observations.	Sections 12-13
Honeypot service	Operator observation	2026-07-16	The bounded trap service was observed in active use.	LIVE guard	Supports service liveness, not dashboard availability.	Sections 12-13
Honeypot deployment	Dated deployment record	2025-12-08	The bounded rollout record verified the honeypot deployment and related enforcement context.	Dated deployment evidence	Current liveness comes from the later 2026-07-16 observation.	Sections 8, 12-13
Killswitch service	Operator observation	2026-07-16	The tunnel-watching service was observed active and running.	LIVE service	Service liveness does not refresh its separately recorded operating mode.	Sections 12-13
Killswitch operating mode	Dated deployment record	2026-02-15	The retained record placed the service in logging mode for that observation.	Dated action posture	The record states mode at that date; it is not a present-liveness or unresolved-status claim.	Sections 12-13
Nexus guard and recovery manager	Operator observation	2026-07-16	Both bounded integrity/recovery controls were observed in active use.	LIVE controls	Each retains its own action scope and evidence store.	Sections 12-13

TABLE D2 · Partial and unresolved evidence-resolution ledger

Surface	Parent capability status	Narrow residual status	Last authoritative evidence	Current inference allowed	Evidence required to resolve	Owner
Current P2P mesh liveness	Peer primitives PARTIAL	UNRESOLVED	Successful sealed-path exercise on or before 2026-05	Authenticated verbs worked in that exercise.	A dated current-build window observing authenticated registration, roster, heartbeat, query, and delivery	Sections 11, 13, 18
Remote filesystem query integration	Local primitive IMPL	PARTIAL	Implementation inspection and bounded local probe, 2026-07-18	The bounded local primitive functions; the query verb exists.	Authorized and denied end-to-end queries initiated by the Sentry path with bounded output and observed consumer evidence	Sections 10-11, 13, 18
Dashboard read-view/access layer	Dashboard IMPL	PARTIAL	Bounded probe and inspection, 2026-07-18	The application renders its record families when invoked.	An access-control matrix covering authenticated/unauthenticated reader classes, view shaping, redaction, and fail-closed configuration	Sections 12-13, 18
Activity freshness and availability	Dashboard IMPL; read layer PARTIAL	Awaiting dataset	Read primitives exercised inside an inactive application, 2026-07-18	Functional reads only	A declared-window series of record age, gap intervals, and surface availability	Sections 13, 18
Preprocessing throughput and latency	Sentry-Prime IMPL	Awaiting dataset	Bounded normalization/suppression probe, 2026-07-18	Functional pipeline behavior only	Conserved stage counts and per-stage latency distributions over a declared workload	Sections 13, 18
Watchdog recovery timing/reliability	Watchdogs LIVE	Awaiting dataset	5/5 integration checks, 2025-12-11	Exercised recovery success only	Per-lane durations, attempt counts, and censored non-recoveries over a declared window	Sections 9, 13, 18
Structural drift rate	EdgeGraph LIVE	Awaiting dataset	Active-use observation, 2026-07-16	Live observation cycle and appearance detection	A dated drift series with known change boundaries annotated	Sections 10, 13, 18
Snapshot scaling	Snapshot primitive IMPL	Awaiting dataset	Single bounded capture/restore, 2026-07-18	Function under one bounded fixture	Multi-size fixtures recording capture duration and compressed size against tree size	Sections 10, 13, 18
Direct versus relayed transport latency	CaSTaP IMPL; peer path PARTIAL	Awaiting dataset	Functional sealed-envelope proof, 2026-07-17	Transport function only	Matched direct and relayed workloads with percentile latency and delivery outcomes	Sections 11, 13, 18
Transport controls under pressure	Peer primitives PARTIAL	Awaiting controls and dataset	Authenticated mesh exercise on or before 2026-05	Authenticated verbs under the bounded exercise	A controlled fixture producing accepted, rejected, replayed, rate-limited, and quarantined outcome classes after the named controls exist	Sections 11, 13, 18

EAppendix E · Subsystem and Evidence-Index References

Reader navigation and evidence discovery remain separate from capability status. A link identifies a reading or distribution surface; it does not promote CodeSentinel integration, operational status, deployment, or lifecycle authority.

TABLE E1 · Subsystem and publication crosswalk

Subsystem / context	CodeSentinel role	Owner section(s)	Dedicated reading path	Availability boundary
ORACL	Tiered memory, evidence lineage, advisory context, and governed-evolution scenarios	Section 7; Section 19; Appendix A	This report is the verified reading path; no independent public ORACL report is claimed.	SessionMemory appears across release surfaces; deeper governed-memory apparatus remains DEV.
CIDS	Embedded network-security decision and enforcement subsystem	Sections 8-13; Section 19; Appendix C; Appendix D	This report is the verified reading path; no independent public CIDS package, repository, or report is claimed.	Embedded DEV system; package extraction remains PLANNED.
Calamum Test	Independently owned adversarial validation and retained-evidence context	Section 14; Section 16	Calamum technical report; Calamum public source; Calamum package	Independent PyPI GH release; its availability does not transfer to CIDS.
ORACode / ORACall	Semantic retrieval and provenance-traversal context	Section 15; Section 16	ORACode / ORACall technical report; ORACode public source	Independent GH release; CodeSentinel integration remains DEV.
Brain knowledge artifacts	Reading artifacts for the planned Brain/ORACL evolution context	Section 19.9	Brain 2 Reference Manual; Brain 2 research-fair poster	Canonical site-tree artifacts resolve locally; the capabilities they describe remain PLANNED.

TABLE E2 · Evidence-index surface crosswalk

Surface	Authority role	Canonical or derived	Producer	Consumer/reading path	Status	Owner
Documentation manifests	Schema-bound inventory and discovery evidence; no source-document mutation	Derived manifest; source documents remain canonical	Documentation-manifest builder	Manifest registry and documentation readers	DEV · IMPL	Section 6.4; Appendix A
Domain indices	Human- and machine-readable navigation over owned documentation	Derived navigation surface	Domain-index builder	Documentation readers and discovery tooling	DEV · IMPL	Section 6.4; Section 17
Manifest-registry resolution	Resolves indexed documents by source, dataset, subject, and keyword	Canonical resolver record within discovery scope; never lifecycle SSOT	ManifestRegistry	ORACL context lookup and evidence discovery	DEV · IMPL	Section 7; Section 17
Confederated session/dataset links	Persists bidirectional discovery links without job, policy, or document authority	Canonical for recorded link associations; linked artifacts retain their own authority	ConfederatedLinkIndex	Session, dataset, and manifest readers	DEV · IMPL	Section 6.4; Section 7

FAppendix F · External References

External authorities appear only where a retained technical claim depends on a standard or protocol specification.

1. [1]National Institute of Standards and Technology. FIPS PUB 180-4: Secure Hash Standard (SHS). August 2015 update. Canonical publication record.
2. [2]National Institute of Standards and Technology. FIPS PUB 198-1: The Keyed-Hash Message Authentication Code (HMAC). July 2008. Canonical publication record.
3. [3]Dworkin, M. NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. National Institute of Standards and Technology, November 2007. Canonical publication record.
4. [4]Moriarty, K., Kaliski, B., Jonsson, J., and Rusch, A. RFC 8017: PKCS #1: RSA Cryptography Specifications Version 2.2. Internet Engineering Task Force, November 2016. Canonical RFC record.