HCM · Payroll implementation

A decade of implementation judgment, made consultable.

A knowledge system built on Ryan's own ten years of HCM and payroll implementation records. It captures the decisions, failure modes, gates and plays a senior consultant carries between projects, so the next project starts from that judgment instead of from scratch.

Private system · not offered to clients

DomainHCM and payroll implementation

CorpusRyan's own implementation records

StackPython · Supabase pgvector · Claude

AccessPrivate, single user

10Of implementation practice

4Record types: decisions, failure modes, gates, plays

9Views, from Ask to Slip causes

PrivateKept private because the records include client work

The problem

Every implementation re-derives the same judgment from scratch.

A senior implementation consultant carries hundreds of hard-won calls between projects: which configuration choices can be undone, which cutover risks compound, which client signals predict trouble. All of it in one head, none of it searchable.

That judgment is earned one failure at a time, and it evaporates the same way. Lessons-learned documents capture stories, and stories cannot be consulted at the moment a decision fires.

Pain pointWhat it costWhat the build does

Judgment in one head

The real asset travels only where the consultant does.

Decisions captured as records: trigger, call, reasoning, the gate it protects.

Failures repeat

Avoidable crises recur because their early signs were never written down.

A failure-mode library keyed to the early warning signs.

Lessons are not consultable

Narrative documents answer nothing mid-project.

Records retrieved by situation, not by re-reading retrospectives.

The approach

Capture decisions, not documentation.

The unit of capture is the decision record: the trigger that fires it, the call made, the reasoning, and the gate it protects (the downstream failure that getting this call right prevents). Around the decisions sit failure modes with their early signs, gates where mistakes become expensive, and plays: proven responses to situations that recur.

The system does not store what a consultant read. It stores what a consultant decided, and why.

The corpus is Ryan's own implementation records from a decade of projects. Because those records include client work, the system is private. It is not shared and not offered to clients; what is offered is the method.

How it works

Four record types. One consultable practice.

Each structure answers a different question a live implementation asks. Click a stage.

What it shows

What this work shows.

Expertise worth capturing is expertise that decides things, so the format has to match the shape of a decision.

The decision record is the unit

Trigger, call, reasoning, gate. That is why it answers questions documents cannot.

Failure modes are worth the most

Wins get remembered. The early signs of avoidable crises are forgotten first and cost the most.

Privacy is a design input

Records that include client work stay private. The method travels; the data does not.

The template generalises

Every firm has someone whose exit would take a decade of judgment with them.

See it working

Try something like it.

The Company Brain, for your firmThe same pattern, built on your own documents, with permission walls on the server.See the Company Brain →Knowledge systems from course materialThe same structuring method on three professional curricula.Read the case →

Python harvesters (Office, PDF, email, schedules, OneNote)Supabase Postgres + pgvectorOpenAI embeddingsClaude

Whose retirement would erase a decade of your firm's judgment?

The same build fits senior estimators, underwriters, controllers and implementation leads. Start with a conversation about the expertise you can least afford to lose.

📅 Book a call