Neural Engine Kernel · kernel-neural-engine

Owner directive (2026-07-10), canonical. "Create a Dispatch, Wake you up every 10 minutes, check if all capability is allocated, check the conclusion of particles and atoms and if the run is moving." [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:646] — combined with the D12 ruling that the Neural Engine is the kernel-level workflow engine Sapiens3 uses to actually execute. [src: HOS-Webdoc/web/src/data/hos-specification.ts:589]

Content

The Neural Engine Kernel is the orchestration kernel of an HOS instance — the "environments + keys" sense of kernel established for sapiens3 ("Kernel: the environments and keys for each Datan" [src: wiki/engines/cognis-and-kernels.md:30]) applied to the neural-engine itself. Where cogni-neural-engine is the understanding of how a run is reasoned, this card is the code contract: the state machine, the tick, and the gates that a datan or looper runtime must implement to run a dispatch. It is executed under the one rule of the system, the cognitive-loop ("Cognis → Kernels → Neuralwares" on every loop [src: wiki/engines/cognitive-loop.md:3]).

1. The dispatch.json state machine

One dispatch file per run is the single mutable coordination surface (full field schema in schema-dispatch-json; procedure in sop-003-run-dispatch):

type RunState = 'planned' | 'running' | 'blocked' | 'verifying' | 'closed';

interface Dispatch {
  run_id: string;                    // e.g. "RUN-016"
  state: RunState;
  objective: string;                 // one sentence, cites library cards by id
  particles: Particle[];            // the work units of the run
  squads: SquadAllocation[];        // fan-out map (see §3)
  gates: GateResult[];              // see §4
  heartbeat: Heartbeat;             // see §2
  commits: string[];                // one commit hash per closed loop (§5)
}

interface Particle {
  id: string;                        // "p-<seq>"
  state: 'backlog' | 'prepare' | 'method' | 'execute' | 'deliver'
       | 'awaiting-approval' | 'done';   // the 7 stages, per D14/C-04
  squad: string;                     // [[squad]] id, e.g. "squad-instance"
  gear: string;                      // [[gear-sets]] entry chosen by the Cogni
  neuralware: string[];              // [[neuralware]] ids equipped for this particle
  evidence: string[];                // file paths / URLs proving delivery
}

Particle states are the seven canonical node stages (backlog → prepare → method → execute → deliver → awaiting-approval → done) ruled in D14 and C-04 [src: HOS-Webdoc/web/src/data/hos-specification.ts:605] [src: wiki/development/HANDOFF.md:136].

2. Run / tick / heartbeat contracts

interface Heartbeat {
  every_minutes: 10;                 // owner-fixed cadence
  last_beat: string;                 // ISO timestamp
  checks: [
    'capability-allocated',          // is every particle staffed with squad + gear?
    'particles-concluding',          // are particles and atoms concluding?
    'run-moving'                     // did state advance since last beat?
  ];
  on_stall: 'escalate-to-companion'; // DSync failure path, per D7
}

interface NeuralEngineRun {
  start(dispatch: Dispatch): void;              // planned → running
  tick(): void;                                 // advance every ready particle one stage
  heartbeat(): HeartbeatReport;                 // every 10 minutes, the 3 checks above
  verify(): GateResult[];                       // run all gates (§4)
  close(): void;                                // verifying → closed, only if all gates pass
}

The 10-minute boundary timer and its three checks are verbatim owner law [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:646]. A stalled run does not retry blindly — it escalates on the DSync failure path (ASSISTANT detects stuck → COMPANION develops solution → ADVISOR validates), which D7 keeps strictly separate from the approval chain [src: HOS-Webdoc/web/src/data/hos-specification.ts:549].

3. Workflow / agent fan-out primitives

• fanOut(particles, squads) — allocate particles to squads; the reference allocation for this district is the owner's three squads squad-eggtech, squad-schematic, squad-instance [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:526].
• gearUp(particle) — the cogni-neural-engine selects the gear-sets entry (context, rules, models, resources) and neuralware per particle; a failed particle returns to the Academy and re-equips a new neuralware before retrying [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:612].
• spark(loop) — a closed loop emits sparks that initiate the next loops, per the write-back stage of the cognitive-loop [src: wiki/engines/cognitive-loop.md:57].
• Role mapping inside a run is fixed: "RUN Leadership - ASSITANT / RUN MANAGEMENT - COMPANION / RUN MAINTAINER - ADVISOR/Executive" [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:563] — see assistant, companion, advisor, squad-roles.

4. Gates

A run may not close until every gate passes (refusing/accepts is the Cogni's job; the kernel only executes the checks):

5. Commit-per-loop rule

"every loop should have a commit, until the atom and the nodes, and etc with PR following the interactions of the systems" [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:586]. The kernel therefore requires: one commit per closed loop, one PR per systems-level interaction, and the commits[] array in the dispatch as the audit trail. Peer review stays visible at the remotica portals [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:632].

Variants

Composition

• uses: schema-dispatch-json (field contract), sop-003-run-dispatch (procedure), squad / squad-roles (fan-out targets), gear-sets (per-particle equipment), neuralware (plug-in capability), bm-001-web-perf + bm-002-splat-budget (benchmark gates), cognitive-loop (the rule it executes under)
• used-by: cogni-neural-engine (the understanding that drives it), bpmn-neural-engine-run (the process diagram of one run), sc-002-neural-engine-run (schematic), district-spatial-site (first consumer district), pb-003-run-dispatch (playbook)

See also

• kernel-spatial-site — the sibling kernel this one orchestrates runs for
• neural-engine — the concept card
• infograph — where this kernel appears in the one-page model
• [Cognitive Loop](../../../wiki/engines/cognitive-loop.md)