Do more internally
Test whether some visible reasoning steps can be replaced without making the result worse for the user.
Local model research · controlled comparisons
Active research · controlled experiments completeCan a model do less work without giving worse answers?
I run controlled local experiments on an NVIDIA DGX Spark to test ideas from recent AI research. The goal is simple: find out whether a model can reason more efficiently while keeping its answers accurate, useful, and understandable. A faster or shorter result is rejected when the quality does not hold.
The research question
Shorter reasoning matters only if the answer stays good.
The question is not simply whether the model can produce less text. It is whether it can use less work while preserving correct answers, clear explanations, natural stopping, and usefulness on more than one narrow task.
Teach the task it must perform
Make sure the training examples, questions, expected answers, and stopping behavior match what the model will be asked to do later.
Quality before speed
Compare answer quality, explanation, stopping, amount of work, speed, integrity, and cleanup before approving a larger run.
My role
I set the question, direct the experiments, examine the failures, and decide what is worth continuing.
Question and scopeI define what we are trying to learn, what a useful result would be, which hardware and model are in scope, and when to stop.
Experiment directionI require fair comparisons, fresh questions, answer and explanation review, integrity checks, and clear rules for moving forward.
Failure analysisI challenge plausible explanations, separate cleaner output from better answers, and redirect the work when the training does not match the intended use.
Final decisionAI agents assist with implementation, test construction, analysis, and documentation. I retain the decision to continue, hold, redesign, or stop.
Research chronology
The surviving record separates the research work from when it became public.
The geometric and latent-reasoning direction, bounded implementation work, and controlled evaluation are documented by this date. It is an evidence milestone, not a claim about when the underlying idea was first conceived.
The dedicated research case study was publicly presented in the portfolio by this date.
How the experiments work
Turn a paper’s idea into a local test that can prove it wrong.
Define the question
Reduce the paper’s idea to one clear question with a result that can be accepted or rejected.
Build a fair comparison
Keep the model, training budget, evaluation method, and comparison conditions stable enough to isolate the change.
Train and evaluate locally
Run controlled adaptations and fresh evaluations on the DGX Spark while keeping each model and result clearly identified.
Continue or stop
Compare correctness, explanation quality, stopping, amount of work, speed, and cleanup before deciding whether to scale.
Completed evidence
Multiple controlled runs now define the strongest and weakest approaches.
Pilot evaluationTested the initial paper-derived training approach against a pristine baseline.
Matched comparisonCompared trained and baseline behavior under controlled generation conditions.
Prompt diagnosticsSeparated stopping behavior from actual reasoning and answer quality.
Direct-answer controlTested whether cleaner formatting represented better task performance.
Task-mix auditExamined what the training data actually taught the model to do.
Each run used a predeclared evidence boundary. Training stability, checkpoint identity, evaluation coverage, output scoring, substantive review, and GPU cleanup were evaluated separately to preserve a complete view of model quality.
What the experiments established
Efficiency signals appeared, but they did not preserve quality.
Less work did not mean better reasoningThe tested latent condition reduced generated work but lost answers the comparison checkpoint had handled correctly.
Cleaner formatting was a false positiveMore consistent answer formatting looked better while substantive correctness declined.
Stopping behavior and reasoning were separatePrompt changes improved output closure but did not repair the underlying answer-quality problem.
Training coverage was too narrowThe data audit showed that the training mix and targets did not represent the broader tasks the model was expected to retain.
These negative promotion results had positive engineering value: they stopped a longer run on a recipe that was shorter or cleaner without being reliably better.
Current direction
Fix what the training teaches before using more compute.
The next proposal restarts from a clean baseline and uses training examples that better match the tasks the model must perform. It also broadens the checks for retained capability and uses fresh evaluation questions. The goal is to learn whether concise reasoning can preserve useful capability—not merely produce shorter text.
Pegasus Cortex supplies a real local use case for that work: retrieve only the context a task needs, preserve where information came from, and keep stored knowledge from authorizing actions. Future experiments can therefore be judged against a practical system need rather than an isolated benchmark alone.