Local AI · Working infrastructure

Local AI with work to do.

I use the lab to turn intent into experiments and better decisions. HEARTH connects the models and tools; CommandCenter keeps the work and its records together. The useful result is something I can inspect, learn from, and put to work.

HEARTH's published aggregate charts and coverage statement in the systems evidence lab
A view of the released HEARTH aggregate through September 7, 2026. Gateway observations include polling and health automation; they are not a count of completed customer tasks. Inspect the aggregate and its coverage →

The hardware experiments have somewhere to go.

The earlier field reports asked what consumer hardware could actually serve. Those measurements now inform a practical system: which model to load, where it fits, when it can run, and how to preserve the result if a worker or connection disappears.

This infrastructure also gives new projects a useful starting point. DMos could request atmosphere images through an existing boundary instead of inventing its own local AI stack.

My work is the integration and operating design around existing models and runtimes: the contracts, routing, recovery, and instruments that make them usable together.

What the Linux experiments changed.

Experiments: September 24–25 and October 3–4, 2026 · Account reviewed October 7

I want the system to help me reason about the work and make better choices. That means keeping the request, the setup, the result, and the review together. Two recent Linux investigations show how the evidence changed what we did next.

JEPA: the perfect score needed a better test.

  1. Intent

    My JEPA research asks whether a system can connect engineering artifacts by their relationship: an incident to the decision that addresses it, or a plan to its verification, even when their wording differs. The record needs the state and the request that existed before the work.

  2. Experiment

    The Linux audit revisited an earlier retrieval result that ranked the expected artifact first in all 44 cases. The choices mixed artifact excerpts with short synthetic alternatives. The audit tested simple shortcuts, then made the same frozen predictor choose among excerpts from real competing artifacts.

  3. Result

    Choosing the longest candidate also scored 44 of 44. One fixed question used across all cases did too. Against excerpts from 42 real target artifacts, the predictor ranked the expected target first in only 1 of 44 cases; a lexical search baseline found 5. The earlier score had not established the relationship-learning capability I wanted.

  4. Decision

    The agents' analysis redirected the next work toward the data and the test: realistic competing artifacts, checks for shortcuts, and requests recorded before their outcomes. Requests reconstructed after seeing an answer needed a separate label.

  5. Improvement

    The follow-up built 61 historical transition records, including 51 with an earlier recorded user message. Those message-to-commit matches still needed review. The practical lesson for my workflow is to record intent before building, so the next experiment can distinguish what we knew then from what we learned later.

What this established: a misleading result was exposed, and an evaluation dataset with real recorded messages was built. The follow-up re-scored known historical cases using excerpts of up to 400 characters. Message alignment was based on time and remained pending curation. This work did not establish a trained JEPA model that generalizes, or measure a reduction in my rework or review time.

Thinking: preserve the useful work through delivery.

  1. Intent

    On October 3, I asked that the local 27B model be given room for sustained thinking and multi-step work. The existing delivery setup used one call with thinking disabled. I wanted to learn what the model could do with a setup suited to the task.

  2. Experiment

    The agents tested a longer thinking turn on two report briefs, followed by a separate delivery step. They inspected the working drafts as well as the final reports.

  3. Result

    One draft made a correct comparison that earlier reports had missed. The final rewrite, with thinking disabled, dropped it. Another report lost a useful detail in the same handoff. Part of the problem was in how the workflow delivered the answer.

  4. Decision

    The agents changed the workflow so code preserved the draft while a model attached source quotations. A later checking step compared the draft with the source before delivery. These implementation and review decisions are attributed to the agents; my direction was to investigate the model under a more suitable setup.

  5. Improvement

    The comparison survived in the retained-draft experiment. The revised workflow was then exercised on twelve new report briefs, with acceptance criteria written before the runs. More reports met those criteria, while the remaining omissions and the extra processing time stayed on the record.

October 4: the same twelve report briefs, graded by Opus agents against prewritten criteria
ProcedureAccepted reportsFalse statements recorded by graders
One call, thinking disabled0 of 1210
Thinking draft preserved through delivery8 of 121
Preserved draft plus source-checking turn9 of 120

Six briefs were open to inspection while improving the procedure; six were sealed from that tuning. Under the checked procedure, five of the sealed six met the acceptance criteria according to Opus graders. Three of the twelve reports still had omissions. Across all 17 carried reports in that run, including five previously used briefs, the median time from dispatch to review was 7.9 minutes. The checking step roughly doubled the model's processing time for a report.

Scope: these are local observations from one sample per brief and procedure, with agent grades. The procedures changed several parts of the workflow; the comparison does not isolate the effect of thinking alone. Drafts varied even at temperature zero. Grading arrangements also differed: the single-call arm used two graders handling six reports each, while each carried report had a fresh grader. The counts describe these reports, rather than a general reliability rate or measured human time savings.

Source records and what remains private

This account summarizes retained Linux records: JEPA strategy: operational transition learning from artifact-driven development, the real-competitor probe and recorded-intent dataset reports from September 25, The 27B as a multi-step worker from October 3, and Held-out rates per procedure with its wave-five report from October 4.

The source records, raw requests and individual model outputs are retained privately. This is a documentary account of my direction and the agents' experiments and reviews. It does not independently verify each model's answer or count my interventions. The published activity feed has a separate scope and observation window.

Change the model and preserve useful context.

September's rotation work puts model lifecycle management under llama-swap and adds HEARTH's checks around it. A successful load needs evidence of where the model landed, alongside a real inference check.

A retained live proof saved a model's prompt cache, unloaded that model, loaded another, then reloaded the first and restored its saved context. A later proof placed two side models on separate Intel Arc Pro B70 cards beside the primary serving model.

These are bounded placement and recovery demonstrations. They help establish what the scheduler can safely plan around. Work competing for the same GPU pool still needs explicit coordination.

A retry should still belong to the same piece of work.

HEARTH distinguishes a request, the durable job it creates, and the attempts made to execute it. Results and artifacts have a history that can be inspected after the worker is gone.

The September audit found a concrete failure in that machinery: an in-process lock did not protect a ledger opened by two processes. It also found that execution still worked after a refactor while some observations stopped crossing the worker boundary.

Both paths were repaired. The work mattered because a healthy-looking dashboard could otherwise conceal missing evidence or a ledger that would fail to rebuild.

The lab's guided recovery replay lets you explore ordered delivery, duplicate suppression, and retries. Its identifiers and events are explicitly fabricated; it illustrates the released contract without exposing operating content.

There are finished media artifacts, too.

The audio workflow turns structured scripts into locally synthesized narration, with voice profiles, pacing controls, and receipts tied to the resulting files. The September work produced a five-episode technical series in multiple voice profiles.

The later master receipts record synthesis on a single Intel Arc Pro B70. Earlier dual-card speed and memory figures were marked unverified and are excluded here. The completed audio files and their checksums provide a narrower, useful result: the local workflow produced the artifacts it recorded.

Audio and image work make the infrastructure tangible. A model becomes one part of a workflow with an input, a result, and a way to check what happened between them.

The public lab keeps the context attached.

The hardware field report retains its measured operating points and corrected conclusions. The lab adds a released aggregate of gateway and execution activity.

The aggregate is a dated snapshot with a limited view of the system. It leaves out raw prompts, task content, identities, and calls with no retained instrumentation or harvested record. Recorded research outside the gateway is shown separately. It is useful evidence of system behavior within that boundary.

These systems run in my studio environment. A client deployment starts with its own hardware, workload, and ownership requirements; the first useful step is a bounded proof against those conditions.

Direction and review stay on the record.

October 7, 2026 · Linux workflow update

Much of my local-model activity is research: testing which configurations fit, adapting the harness, and learning what context, tools, and review help a model succeed. I change the setup and test again to understand what enables a useful result. Those experiments use local inference, and they happen both through HEARTH and outside it. The pulse labels these calls “Local inference · tuning + use,” with tuning referring to configuration and harness work; its separate hollow research row covers only attempts recorded outside the gateway.

The Linux workflow retains the source supplied to a local model, the result it produced, and the review that follows. A completed call is evidence of execution. Acceptance requires a separate decision about the output.

I set the scope and authority for a prepared model-evaluation campaign. On October 5, I delegated bounded review decisions to Codex. Codex recorded its own decisions and rationale for my review, with agent decisions attributed to Codex. Permission to submit a brief does not pre-accept the model's answer; routing, admission, and output review remain separate steps.

Documentary summary: This section summarizes the retained October 5 decision record, Codex decisions under scoped delegation. The source record is retained privately and is not itself published here. The released feed does not provide verified counts of my interventions or time. Agent decisions remain agent actions.

The published review outcomes keep accepted, rejected, superseded, and pending work visible alongside execution failures. Small counts are suppressed. The values describe retained work states, not independent trials or the quality of a model in every setting.

That makes the goal in What it's actually for concrete: reduce the operator's cognitive load while keeping the direction of the work and its review explicit.