The problem is technically ambiguous.
The outcome matters, but the architecture, algorithm, research direction — or even the right framing — is unclear.
Fractional R&D · Technical consulting
For technical problems that don’t fit neatly into a job description.
Senior technical thinking for difficult, ambiguous and interdisciplinary problems. From feasibility and research to architecture and working prototypes.
Exploratory conversations are welcome.
The problem doesn’t need to be fully defined yet.
A brief introduction01 / Perspective
How I approach difficult technical problems1:48
Research, engineering, and a clear next step. Draft film
Read the video transcript +
Some valuable problems arrive without a clear playbook. I’m Brian Theory, an independent R&D consultant and fractional AI systems lead, helping ambitious teams turn unusual ideas into useful systems.
Through August 2025, I led software engineering work supporting NASA Ames Thermophysics Research. Before that, I worked in computational neuroscience and contributed to several publications, including a 2024 study I led using explainable machine learning to develop shorter psychometric measures.
I developed correspondence matrices, an original structural approach to Boolean computation, and actively maintain its public GitHub repository. It includes the implementation, reproducible comparisons with established algorithms, and detailed explorations of potential applications, from formal verification and rule systems to symbolic AI. If you’re technically curious, you can examine the code and evidence directly.
Codex and Claude Code are part of my development process, helping me explore alternatives and implement faster. I frame the problem, choose the approach, connect the pieces, and test whether the system behaves as intended.
That approach applies to multi-agent automation, evidence-grounded research tools, and scientific or creative software, especially where requirements evolve as the work reveals new information.
I take on focused consulting and fractional R&D engagements for technically difficult work. I’m drawn to learning new domains, investigating open problems, and adapting as research moves forward.
If you’re building something unusual, visit BrianTheory.com and tell me what you’re working on.
Transcript from the supplied draft video. Repository links and benchmark evidence are pending; narration retained as supplied.
Built across research,
engineering & hard problems
NASA AmesSoftware engineering supporting
Thermophysics Research · through Aug 2025
Thermophysics Research · through Aug 2025
Computational neuroscienceResearch spanning explainable ML
and psychometric measurement
and psychometric measurement
Correspondence matricesAn original structural approach
to Boolean computation
to Boolean computation
01 / The right kind of help
When the usual playbook
isn’t enough.
You don’t need another generic solution.
You need a useful way into the problem.
You need feasibility before commitment.
Find out which assumptions hold before committing substantial engineering time, capital or organizational attention.
Your team needs another level of thinking.
Bring senior technical depth into an important investigation, alongside the people who already know your systems.
The problem crosses disciplines.
Work that falls between software, AI, mathematical modeling, cognition and systems rarely fits a conventional brief.
An idea needs to become an experiment.
Turn an unfamiliar concept into a model, architecture, prototype or technical question that can actually be tested.
You’re stuck.
Get an independent technical perspective. Revisit the assumptions, change the representation and identify another way through.
02 / Fractional R&D, explained
Senior capability.
Without a permanent
role to fill.
Research and technical capability when you need it, without creating a permanent role before the problem justifies one.
Let’s find the right shape of engagement ↗An investigation with a decision at the end.
Several intensive sessions, a feasibility study, an independent technical review or due diligence. Start with the uncertainty that matters most.
From idea to something you can test.
Research synthesis, architecture, algorithm design or prototype development. Define the useful output together, then build toward it.
Embedded thinking, as the work develops.
Fractional R&D leadership, collaboration with your existing team, or temporary direction of an exploratory initiative.
A focused project or an ongoing role. The scope follows the problem — not a fixed package of hours.
03 / Capabilities
From an open question
to a working answer.
An engagement can move through several modes.
The question determines what the work needs.
Explore
Find the question worth answering.
- Problem framing & feasibility
- Research investigation
- Emerging-technology evaluation
- Technical due diligence
Design
Give the problem a useful structure.
- Algorithms & computational models
- Software & system architecture
- AI / ML approaches
- Experimental strategies
Build & test
Replace assumptions with evidence.
- Working prototypes
- Proofs of concept
- Simulations & experiments
- Technical validation
Advise & lead
Help the team make its next move.
- Fractional R&D leadership
- Technical strategy & research direction
- Independent technical review
- Embedded team collaboration
The cross-disciplinary advantage
More ways to represent
and attack a problem.
Some problems are difficult precisely because they sit between disciplines. Computer science, AI, computational neuroscience, mathematics and systems thinking offer different models of the same underlying challenge.
The value is knowing when to borrow an abstraction, question a familiar approach, or connect research to an implementation.
The point isn’t breadth for its own sake.
It’s having more ways into the problem.
ComputationMathematicsCognitionSystems
One shared focusThe problem that matters
Models & experiments → Evidence
Different perspectives. A concrete next step.
04 / Selected technical work
The thinking, made concrete.
A closer look at the question,
the approach and the work behind it.
01 / Algorithms & structural reasoningA different representation of Boolean computation.Correspondence matrices — an original structural approach, developed into an implementation and reproducible comparisons.
situation
Investigating alternative ways to represent and reason about Boolean computation.
thinking
The work explores a structural representation through correspondence matrices, with potential applications including formal verification, rule systems and symbolic AI.
work
Developed correspondence matrices and an implementation, with reproducible comparisons to established algorithms, as described in the supplied introduction.
result
An implemented approach that can be examined and tested. No comparative performance advantage is claimed here.
[REPOSITORY URL & BENCHMARK SOURCES TO ADD]
02 / Explainable ML & measurementUsing machine learning to investigate shorter measures.A 2024 research study applying explainable machine learning to psychometric measurement.
situation
Investigating shorter psychometric measures, at the intersection of computational methods and behavioral research.
thinking
Using explainable machine learning to examine measurement, rather than treating a predictive model as an uninterpreted endpoint.
work
Led a 2024 study using explainable machine learning to develop shorter psychometric measures, following work in computational neuroscience.
result
The study was published. Its exact title, citation, validation findings and limitations need to be added before this becomes a complete case narrative.
[PUBLICATION LINK & VALIDATED RESULTS TO ADD]
These draft summaries are grounded in the supplied introduction. Source links and detailed results are explicitly marked where still needed. Institutional references describe past work, not endorsements.
05 / How I work
Enough structure to make progress.
Enough flexibility to learn.
Understand
Define the real technical question, the constraints and the decisions that matter.
A shared problem frameInvestigate
Analyze the system, challenge assumptions and identify promising paths.
Evidence and alternativesMake it concrete
Develop the architecture, models, experiments or prototypes the question needs.
Something the team can useTransfer or continue
Hand over the work clearly, or stay involved fractionally as it develops.
A clear next step↳ Uncertain problems can enter before the final scope is known. The first task may be finding the right question.
06 / About Brian
A technical generalist
by background.
A problem specialist
by practice.
I work where the question doesn’t yet come with a method.
My background connects software engineering, computational neuroscience and original work in Boolean computation. Through August 2025, I led software engineering work supporting NASA Ames Thermophysics Research.
That breadth shapes how I work: decompose the unfamiliar, look for a useful representation, test the important assumptions, and move between research and implementation.
I’m interested in technically difficult work with people who are willing to investigate it carefully. Sometimes the useful contribution is a prototype. Sometimes it’s a different question.
[FULL CV · LINKEDIN · PUBLICATION LINKS TO ADD]
A useful addition to your side of the table
Founders & CEOs
Evaluate an ambitious idea, understand technical risk and find a credible path toward implementation.
CTOs & engineering leaders
Add senior bandwidth for investigations and architecture outside the team’s normal operating envelope.
R&D & innovation teams
Explore unconventional directions and connect research to experiments and implementation.
Investors & boards
Get independent analysis of feasibility, technical assumptions and the risks behind a proposal.
07 / Notes on the work
A window into the thinking.
Working notes on framing, experiments
and making technical decisions.
Problem framing · Editorial draft
A feasibility question is a decision in disguise.
Why “can we build it?” needs a constraint, a decision and a useful stopping point.
Read the note ↗Experimental R&D · Editorial draftPrototype the uncertainty, not the entire product.
The most useful prototype is the smallest experiment that can expose a consequential failure.
Read the note ↗Start a conversation
Have a difficult
technical problem?
You don’t need to know the solution — or even have the problem perfectly framed — before getting in touch.
Tell me what you’re trying to accomplish,
what’s uncertain, and where you’re stuck.
[PUBLIC CONTACT EMAIL TO ADD]