Matt Boone
Building

I design decision systems and put them to work.

A decision system sets who decides what, on which evidence, and what software may do without asking. Each of these started from a decision that was not getting made. Together they test the whole claim: the design holds, it carries to other problems, and it survives a live business with real people in it.
What each one proves
01 · The design holds
Alice
One operator, one decision loop, every rule visible. It proves the core pattern on a problem small enough to see whole: the model classifies, arithmetic decides, a person approves.
02 · It carries to other problems
PolarAIs
The same pattern pointed at a problem many companies share, where several functions have to work from one plan. It proves the design is not personal to my own work. Discovery with finance and integration leaders is paused, and the evidence stays on file.
03 · It holds in a live business
Throughline
The pattern inside an operating company, across seven systems and a team with its own habits. It is the test of adoption. The hard part has been the order of the argument and the order of the team's morning, not the data, and the gates that show the team runs it without me are written down and not yet passed.
01 · The design holds

Alice

My network lived in three places and none of them could tell me who I was letting go cold. Alice is a second brain: it reads what I already have, remembers every conversation, and each morning tells me where the next hour is best spent and why it thinks so. The hard part was never building it. It was deciding what the AI was allowed to decide.

The scoring is arithmetic I can audit, run nightly inside the database. The model only sorts information into fixed categories. Nothing reaches the record until I approve the specific change on a card showing before, after and the evidence.
Eight days from empty file to running · built and run by one person · replaced the spreadsheet instead of sitting beside it
Read the case study →
Alice morning view: ranked contacts with status, last touch and the next action owed
The ranked list: who is overdue, why, and what is owed next.
02 · It carries to other problems

PolarAIs

I have worked 48+ transactions over the last decade and never had a tool that could tell the CFO what the end-state entity structure should be or what it costs to get there. That answer shows up in month six. It is needed on day one.
Scoring is deterministic and auditable back to the data that produced the number. The generative layer drafts and surfaces. It never writes to the record on its own.
Five working prototypes · twenty scored discovery interviews · discovery paused
Read the case study →
PolarAIs portfolio overview: entity counts, blockers by type and a value by complexity quadrant
Entity readiness scored the same way every run.
03 · It holds in a live business

Throughline

A multi-segment retail and recurring-revenue business had seven systems that each told a different truth, with nothing to say which one to believe for which question. The work started from the decisions the team makes every day and worked back to the data. The hard part is the people: sequencing an argument a long-tenured operator can hear, and changing the order of the team's morning.
One warehouse sits under the point of sale, CRM, ad account, books and payroll. Every recurring decision gets one page, stamped with its source and pull time. The software proposes each next step and a person commits it. Only people write back to the CRM and the books.
Seven source systems · one page per recurring decision · adoption gates set, not yet passed
Read the case study →
Sources→Warehouse→Pages→People
Software reads, builds and proposes. Only people commit.
Four layers, one direction of trust.
Contact

If a decision in your company is being made badly, tell me which one and what it costs.

msandfordboone@gmail.com