Enterprise AI should be useful, governed,
and honest.
Most enterprise AI doesn’t fail in the demo. It fails later — when people ask how it works,
who approved it, what data it touched, and whether anyone can trust the output.
That’s the gap I work in.
Applied AI for enterprise work — revenue, service businesses, SAP transformation, delivery
governance, decision support. Every build starts with one question: what’s
the safest, simplest mechanism that can do this job reliably?
An agent is the engine. The miniapp is the machine.
Agents are powerful. But an exposed agent is not a product. A product needs boundaries — an
interface, a workflow, permissions, approvals, exception handling, and a clear record of what happened.
Foundation models
the electricity
→
Agents
the motor
→
Miniapps
the machine
That is why I build miniapps. A miniapp gives AI a safe place to work: it defines the task, limits the
blast radius, captures the evidence, and shows the human where judgment is still required.
The AI handles variation. The miniapp provides structure. The business keeps
control. This is the pattern I trust for enterprise AI — not bigger demos, but smaller,
governed systems that do one important job well.
Agents aren’t the product. They’re a component inside it — and the miniapp is the
product the enterprise actually runs.
Who I am
I build enterprise AI that can survive the real questions.
More than two decades inside SAP programs, enterprise transformation, compliance-sensitive
environments, steering committees, delivery teams, and business operations. That experience shaped
how I think about AI.
Organizations don’t need more impressive demos. They need systems that can survive the
questions that come after the demo:
Where did this answer come from?
What system was checked?
What did the AI decide versus suggest?
Who approved it?
What happens if it’s wrong?
Can an auditor understand the trail?
I use AI where it’s justified, deterministic logic where it’s safer,
and human approval where consequences matter. The standard is simple: Deployable. Governed.
Honest.
Today, an Enterprise Solution Architect and SAP CX Capability Director. On my own time I run
RevTXM, a revenue-management SaaS in production, and I’m the founder of
TXM Institute, where I publish the method free. The prototypes that earned a no taught me as much
— a prototype that proves something shouldn’t be built is a cheap success, not an
expensive failure.
Six principles, one constellation: the cost ladder · provenance labels · deterministic core · approval gates · honest UI · fact discipline. Every product I ship is navigable by these stars.
Deployable
It runs in production, not in a slide deck. If it can’t survive a real deploy, it isn’t finished.
Governed
Approval gates, permission limits, audit trails. Autonomy is granted in inches and logged in full.
Honest
No claim ships unless it’s true. That rule governs my products, my resume, and this page.
Design & brand
Why the night sky.
The universe here isn’t decoration — it’s the argument, rendered. Enterprise AI is a
vast dark field where most things fail. You don’t cross it by guessing; you cross it by fixed
stars. So the brand is built from the same idea as the work: a few things that don’t move, and
careful motion around them.
A star is a principle.Fixed, and you steer by it — the cost ladder, provenance labels, deterministic core, approval gates, honest UI, fact discipline. The six in the constellation above. They don’t move; that’s the point of a deterministic core.
An orbit is a governed path.Bounded, predictable motion — autonomy with a boundary. The AI moves, but only along a track a human laid down and can stop.
The comet is the rare AI moment.One, not a storm. AI used sparingly and dramatically, exactly where it’s justified — economical, precise, policy-safe. A sky full of noise is the thing I’m against.
The field is the enterprise.Vast and dark, until you know the stars. The job is to make it navigable — not to add more lights.
The system, not the vibe
It’s a real design system: tokenized colors, system fonts, a monospace voice for labels, and
motion that always respects prefers-reduced-motion.
Every color is checked for WCAG AA contrast — the ratios live in the stylesheet, because honesty
extends to the pixels too.
Night
#070b14the field
Ink
#e9eef7AA 16.9:1
Body
#c3cdddAA 12.3:1
Muted
#93a1baAA 7.5:1
Gold
#e7b35cthe comet · 10.3:1
Blue
#8fc6e8orbits · 10.7:1
This galaxy language recurs wherever I design — a visual second-brain rendered as a galaxy,
product surfaces built on the same dark, navigable field. It’s my signature because it’s my
thesis: vast and dark on the outside, fixed and navigable once you know the stars. Drama from restraint,
never from neon — the same discipline I hold in the products.
Public diary
What I’m learning, while the work is still fresh.
I keep a public diary because the lessons are more useful when they’re honest. Some entries are
about shipping, some about mistakes, some about the uncomfortable gap between the standards I set for
products and the standards I still need to apply to myself. Trust doesn’t come from pretending the
evidence chain is perfect — it comes from building it in public.
The auditor, audited
I ran a five-persona adversarial panel against my own resume today — AI reviewers,
the same hostile-review harness I run against my products before they ship. They found
weak verbs and vague scope, but the finding that stung was structural: I built audit
trails for my agents and none for myself. Two decades of work, and I couldn’t produce
a clean evidence chain for half of it. To be precise about what that means: the work
happened, and the people who were there can vouch for it — what was missing was the
assembled record. Unassembled is not untrue. Closing that gap is what this diary is for.
LessonApply your own standards to yourself first, not last.
Four organizations, one map
LessonStructure is not overhead. It’s the kindness you owe the next person who has to understand your work — including the future you who has forgotten it.
Read the entry
I consolidated the whole portfolio into four GitHub organizations and wrote a single
portfolio map — one document that lets any fresh collaborator, human or AI, orient
in one read. It felt like administrative work until I watched it function: a new session
with no memory of anything I’d built found the right repository, the right doctrine,
and the right next step, unaided.
Even the architect drifts
LessonDiscipline is not a personality trait; it’s an architecture. If the gate isn’t in the path, assume it gets skipped — even by the person who built the gate.
Read the entry
Uncomfortable discovery: two recent designs were built without loading my own canonical
rules. I wrote those rules. I enforce them on everything else. And I still drifted the
moment no gate stood in my path. I spent today retrofitting both into the portfolio
governance, and it cost more than building them right would have.
A second brain, rendered as a galaxy
LessonWhen a structure gets too large to hold in your head, change the medium before you change the structure.
Read the entry
I scaffolded Cortex today — a visual second brain that renders my portfolio
doctrine as a galaxy. Products as systems, principles as stars, dependencies as orbits.
I built it because text files were failing me: I could no longer see how thirteen
products related, only read about it. The first render showed me what the documents never
did — which parts of the portfolio are dense, and which are drifting alone at the edge.
The deploy that fought back
LessonThe runbook cost twenty extra minutes. The next deploy will cost an evening less.
Read the entry
First production deploy of Rapid Impact Analyzer to SAP BTP Cloud Foundry, migrated off
Render. The deploy fought back the whole way: certificate chains that wouldn’t
verify, a buildpack stuck in a rebuild loop, database permissions that failed only in
production. I fixed each one and wrote each fix down as I went, and by the end the notes
had become a reusable runbook — the same one I now publish, in full, in the library below.
These are quick notes. The longer write-ups — lessons turned into something you can use —
live in Field Notes →
The library · All of it free
Methods you can use without asking permission.
The library is free because the method is more useful when more people use it. Practical tools for
deciding when AI is justified, how to label outputs, how to design approval gates, how to write with
fact discipline, and how to keep interfaces honest. No email wall, no teaser version, no artificial
scarcity. Use what helps, share what helps — if it saves you a bad decision, pass it on.
Framework
The Cost Ladder — when AI is and isn’t justified
Before reaching for AI, walk the ladder: rule → router → template →
calculator → validator → AI → AI agent → human. Each step up costs more and runs
slower than the one below it, and from validator through agent each step is harder to predict and to
audit. The human sits at the top not because people are unpredictable, but because someone must own the
consequences. Use the cheapest mechanism that is reliably correct; escalate only when the rung below
demonstrably can’t do the job — and “demonstrably” means a failing test set, not a
hunch: a feature doesn’t move up the ladder until the rung below fails written cases, and the AI rung
doesn’t ship until it passes them. In my own products, most “AI features” turned out to be
rules, templates, or calculators wearing a costume — and they got faster, cheaper, and more
auditable the day I demoted them.
rule
router
template
calculator
validator — deterministic: prefer these
AI
AI agent — only when justified
human — final authority
Apply todayPick one “AI feature” you own and ask which rung it actually needs. If a rule or a calculator can do it reliably, demote it — you’ll gain speed, money, and auditability in one move.
Standard
The Four Provenance Labels
VerifiedCalculatedAI-SuggestedApproved
Every AI-touched output in my products carries exactly one of four labels:
Verified (traced to a source system),
Calculated (deterministic math you can recompute),
AI-Suggested (a model produced it; no human has accepted it), or
Approved (a named human accepted it).
There is never a fifth label and never an unlabeled value. Users always know what they can
trust; auditors always know what to check.
// not a guideline — a type. The renderer refuses// any figure without a provenance; there is no default.
type Provenance =
"verified" | "calculated" | "ai_suggested" | "approved";
interface Figure {
value: number;
provenance: Provenance; // required
sourceRef: string; // where an auditor goes to check
}
Apply todayTake one dashboard you ship and label every number. The values you can’t label are the ones to worry about.
Doctrine
The Honesty Doctrine for product UI
A button that lies is a bug — same severity as a crash. If a control says
“Export,” it exports. If a feature is a preview, the screen says so. If the data is
sample data, it’s labeled “sample — not your result.” No disabled buttons
posing as features, no progress bars animating over nothing, no “AI-powered” badge on a
rule engine. Users forgive missing features. They don’t forgive being deceived —
and in regulated industries, neither do auditors.
Apply todayClick every control on your main screen and ask whether it does exactly what its label promises. Fix or relabel the ones that don’t.
Runbook
The SAP BTP deploy runbook
The pipeline that finally worked for shipping a Node.js app to SAP BTP Cloud Foundry:
GitHub Actions builds a multi-stage Docker image on every push to main, publishes it
to GitHub Container Registry, and cf push pulls the image — no local Docker, ever.
The gotchas that cost me hours: self-signed certificates in the database TLS chain (trust them
explicitly; don’t disable verification), a buildpack rebuild loop (push the image, not the
source), and a production database user that can’t create extensions (split schema setup
from seeding). Every fix came out of the May 27 deploy in the diary above.
The full runbook — published here, in full
Build in CI, never locally. GitHub Actions builds a multi-stage Docker image on every push to main and publishes it to GitHub Container Registry. Your laptop never needs Docker installed.
Deploy the image, not the source.cf push --docker-image ghcr.io/<org>/<app>:<tag>. Pushing source invites the buildpack to rebuild your app its own way — that’s the rebuild loop. The image you tested is the image that runs.
Monorepo gotcha: if you use pnpm workspaces, workspace:* references break inside the container build. Resolve them at image-build time in the Dockerfile (multi-stage: install, build, prune) rather than expecting the registry to understand them.
Database TLS: BTP PostgreSQL presents self-signed certificates in the chain. When Node throws SELF_SIGNED_CERT_IN_CHAIN, trust the service’s CA certificate explicitly in your client config. Never set rejectUnauthorized:false — that passes the demo and fails the audit.
Split schema from seed. The production database user typically cannot CREATE EXTENSION. Run extension and schema setup as a separate provisioning step with the elevated user; let the app’s boot path only create tables and seed data it owns.
Container permissions: if the app writes anything at runtime, chown the app directory to the runtime user in the Dockerfile — Cloud Foundry won’t run your container as root, and the failure only shows up in production.
Health checks: give manifest.yml a real HTTP health endpoint and make sure it answers before the DB is warm, or CF will kill a healthy app mid-boot.
Write down every error the moment you fix it. This list exists because I did. The runbook cost twenty extra minutes; the next deploy cost an evening less.
Apply todayBuild in CI, deploy an image, and keep your own error log from the first failure on. Stuck on a step anyway? Email me — I answer these personally.
Framework
The 90-minute revenue diagnostic
In my experience, ninety minutes of evidence-scored review is enough to find the two
constraints that matter. Score your revenue engine across six
dimensions on a 1–5 scale, with one non-negotiable rule:
no score without evidence. A 4 you can’t substantiate is a 2.
Then let the two lowest scores define your next ninety days, and deliberately ignore the rest until
then — spreading effort across all six is how diagnostics turn into wallpaper. The gap between
the score you wanted to give and the score the evidence supports is itself the diagnostic.
Apply todayPull last quarter’s pipeline data and score honestly, evidence beside each number. The method above is the whole method; the scoring worksheet is a document, not a page — email me and I’ll send it complete and free.
Writing method
Fact discipline for documents
OBSERVEDINFERREDASSUMPTIONUNKNOWN
Every claim in a serious document gets one of four tags: OBSERVED
(you saw it or measured it), INFERRED (it follows from things you
observed), ASSUMPTION (you’re treating it as true in order to
proceed), UNKNOWN (you don’t know, and you’re saying so
out loud). The tags do their best work before anyone else reads the document: the moment you must choose
one, you discover how much of what you “know” is actually assumption. I use this on architecture
decisions, status reports, and on this website.
Apply todayTag every claim in the next status report you write. Expect to be humbled. Ship it with the tags left in — readers trust documents that admit their own uncertainty.
Do it yourself · Free
Place your own AI decision.
This free tool helps you decide where a task belongs on the cost ladder. It doesn’t use AI, it
doesn’t send your data anywhere, and it runs entirely in your browser. Pick one task you’re
thinking of putting AI on — it helps you decide whether it belongs as a rule, router, template,
calculator, validator, AI assist, agent, or human decision. It’s the first question I ask on
almost every engagement.
Work with me
When the AI idea needs to become a trusted system.
I work best with teams that already feel the gap between AI excitement and enterprise reality. You may
have a promising use case, but the hard questions are starting: is this actually a model problem? What
stays deterministic? Where do approvals belong? What should be a miniapp instead of an open-ended agent?
What can you safely ship? That’s the work I help with.
Advisory · For planning or reviewing an AI initiative
Business AI Architecture Review
I assess whether the work should be deterministic, AI-assisted, agentic, or human-owned. You get a
clear written assessment showing what belongs on each rung of the cost ladder, where approval gates
should sit, and what the audit trail needs to prove. If the honest answer is “you don’t
need AI here,” I’ll say that.
Run the free tool above first — then tell me what it surfaced.
For revenue leaders who need a clear view of what’s blocking growth. We review the revenue
engine across a small set of evidence-based dimensions — no score without evidence. The output
is a focused readout: the two constraints that should own the next 90 days, and the rationale behind
them. The point isn’t a beautiful diagnostic. The point is choosing what to fix next.
Run with me, on your real numbers, with the evidence rule enforced.
RevTXM is my revenue-management SaaS, built with the same principles I advise on: deterministic
core, provenance labels, approval gates, and subscription billing. It’s in production and
early — I’ll be clear about what’s finished, what’s evolving, and what I
wouldn’t claim yet. A walkthrough is the best way to understand it.
No self-serve checkout on purpose — a demo first is fairer to you.
Engagement · For when the blueprint becomes a system
Hands-on Build
For teams that need the blueprint to become a working system. I design and build governed miniapps
with deterministic cores, AI-assisted workflows, scoped permissions, approval gates, and audit
trails. Best fit: enterprise teams with a real problem, real users, real data, and real governance
expectations.
For when the blueprint needs to become a running system.
A note on how this store works: every button above opens an email to me, because that’s the
truth of how an engagement starts. There’s no checkout, no “only 2 spots left,”
and no price I made up to look confident. You write, I answer personally, and we find out together
whether the fit is real. If it isn’t, I’ll say so and point you somewhere better.
One more thing you’d find out anyway: I hold a full-time enterprise role alongside this
practice. Conflicts and boundaries are the first thing we cover in that first email —
I’d rather lose an engagement than blur that line.
Hiring instead of buying? Some teams engage me through this store; some hire me into the
building — forward-deployed AI engineering and SAP AI architecture roles. Same person,
same doctrine. Email me the role and I’ll answer with specifics.
The TL;DR
The deterministic-first read.
A short weekly note on where business, AI, and enterprise technology are actually colliding. Not a link
dump, not hype — just a few things worth understanding, with a practical read on what they change.
Everything in it is free on this site too. Subscribing only changes when you receive it.
No spam, no selling your address, unsubscribe whenever.
— between the AI demo everyone liked and the deployment nobody wants to sign off on, write to me.
I read everything personally. Sometimes the answer is a deep dive, sometimes a build, sometimes a role
conversation — and sometimes it’s simply “you don’t need me for this.”
That answer is part of the standard too.
