New: combined R640 and HP project overview →
Includes source-reported pilots, negative results, and applied studies from the October 19 master portfolio. Explore the full software, creative, and professional portfolio.
The research portfolio
Twenty stories.
The method and the limits.
Explore the work, the research agenda, and the evidence behind each account. A negative result and an unfinished question belong in the record, too.
From the research blog.
Search all research →What we’re building—and the question connecting it all
The projects share one question: how can we turn available local compute, good tools, and retained evidence into dependable help with real work?
Reading CPU inference claims carefully
A token-per-second claim is only useful when we know what was counted, on which machine, and under which workload.
Designing headless assistants around clear boundaries
A headless assistant needs clear entry points, account boundaries, and review points before it becomes an operating workflow.
Sixty-nine questions for dependable local AI
The research catalog covers model efficiency, CPU systems, memory, tools, and evaluation. A question belongs in the portfolio before it earns a result.
Applying the R640 to reproducible computational studies
The R640 research record extends to public-data analysis, finite mathematics, and simulations. The useful result is the one whose scope can be stated precisely.
Designing a CPU-first AI research portfolio
CPU-first AI research needs questions that fit real memory, runtime, and evaluation constraints.
From research ideas to checkable experiments
The useful output of a planning inquiry is a testable protocol, not a claimed discovery. This collection separated those stages.
A successful request is not a correct answer
Seven successful requests did not mean seven correct answers. Repairing the evaluator changed what the benchmark could honestly claim.
A local coding assistant with evidence and protected tests
A small R640 demonstration joined local retrieval, a generated Python fix, protected tests, and a reviewed apply step into one traceable workflow.
Choosing practical tools for bounded AI work
A useful agent workflow starts with a bounded job, a suitable tool, and a checkable result.
Making a large library searchable, one evidence layer at a time
A substantial keyword index is useful before a vector phase is finished. The Wisdom Library records make that distinction explicit.
Building a model benchmark that keeps its context
Model selection needs frozen tasks, runtime identity, request failures, and confirmation runs—not a single leaderboard number.
Rebuilding the R640 into a local AI workstation
Building a local AI environment included patient hardware fault isolation, storage correction, and operating-system recovery.
Giving private AI memory a source of authority
Private memory needs more than search. A retrieved statement must carry its source, date, authority, and conflict status.
When more concurrency makes a local model less responsive
More concurrency can improve a queue while making each answer slower. This small CPU-only comparison made that tradeoff visible.
A smaller GPT-OSS artifact: the 28-expert prototype
A smaller model file is a useful engineering result. Preserving answer quality is a separate question.
Pruning LFM2: smaller weights, measured limits
Reducing an MoE model’s expert count produced a smaller runtime artifact and a modest latency difference in two small historical runs.
Keeping the slow result in the record
A configuration that technically answers can still be too slow for everyday use. This test kept the unsuitable result in the record.
The model loaded. The answers did not arrive.
Loading a model successfully is only the beginning of a usability test. The saved notes preserve a case where the next step failed.
Preserve the master. Test the derived model.
Preserve the source model, create derived runtime artifacts, and make every transformation traceable. That was the architecture question behind this study.