What I won't automate.
Why refusing to put AI in the driver's seat is exactly what makes it safe to put in front of your customers.
This is for you if a recurring part of your operation still runs on you: the monthly pairings, the intake you route by hand, the status emails you copy and paste. And you've been burned enough by “AI” to distrust it. Good. Stay suspicious. Here's the version that earns it.
You've watched a tool misfire in front of a customer with no one able to say why. You've seen automation that dazzled in the pitch and quietly came apart a month later. The good version is quieter: it runs the same way every week, you can explain every move it makes, and it hands you the evening back, without ever putting your name on a decision you didn't see. Here's where I draw that line, and what each choice spares you.
Most builders ask you to trust them. I gave you a button. Run the matching engine yourself and watch it return the same answer every time. The rest of this page is just why I build that way.
Run the engine →This isn't theory. The same discipline runs the operational backbone of a live member network today, built and maintained by one person, with one audit trail from input to result. See the case study →
Automate the work. Never the judgment.
Say you run a community that pairs people every month: mentors and mentees, founders and founders. Today that's you, a spreadsheet, and an evening spent making sure nobody repeats a match and nobody's left out. That's exactly the kind of work I automate. Here's the part most builders get wrong about it, and five promises that follow from getting it right.
You'll always be able to explain what it did, and it'll do the same thing tomorrow.
A board member asks why two people got paired, and “the AI decided” is not an answer you can give. So the part that makes the decision is plain, testable logic: rules you could read on paper. The AI only writes the words around it, and in everything I build, nothing it writes can reach your members until you've approved it. That's enforced, not promised. Same inputs, same result, every run, with a reason you can point to.
Proof, not a promise: the live engine on Cycle Conductor reproduces its pairings exactly: run it twice and nothing moves. Built to be consistent, not merely trained to be. Why it can't drift →
You're not paying for gold-plating.
You've been quoted for complexity you suspected you didn't need, by someone whose incentive was to build more of it. I match the method to the problem: the provably optimal answer when correctness has to be airtight, a simpler approach when it's plenty, and I'll tell you which is which. Right-sized ships sooner and costs less.
The matching core enumerates every possible pairing for the cohort and returns the lowest-cost set, provably optimal, not approximately so (independently verified across 2,300 cohorts), and I'm the first to say where that rigor would be overkill for what you actually run.
You won't get burned by numbers that were never yours.
Every vendor has a “saves you 40 hours a month” figure, lifted from someone else's business and dressed up as a forecast for yours. The numbers we plan against are modeled on your cadence and headcount: real, not a brochure's. A human stays wherever judgment belongs, and nothing runs in a box you can't open and inspect.
You'll notice there isn't a single time-saved or ROI number anywhere on this site. That's on purpose. I'd rather earn the number with you than borrow one.
You'll always know what's proven versus what's promising.
The demo implies one thing, production delivers another, and you find out after you've planned around it. So I label capability honestly: what ships today I call shipped; what's a validated prototype I call a prototype, so you plan around reality, not a pitch.
There's a fairness layer on the Cycle Conductor demo right now that says, in plain text, it's a prototype of where the engine is headed, not a deployed feature. If I label my own demo that carefully, picture how I'll scope your project. See what I mean →
It holds up on the bad day, not just in the demo.
The edge case (the new member, the exception, the moment a customer is watching) is exactly where tools crack, and exactly where your reputation lives. So I design for the worst case first. A guarantee that only holds when everything's tidy isn't a guarantee. The interesting question is never the happy path; it's what happens to the person the system would otherwise overlook.
It's why Cycle Conductor carries a fairness ledger: so a brand-new member isn't quietly sidelined cycle after cycle, the way a careless system would do without anyone noticing.
The third payoff
A call you don't make costs nothing and spills nothing.
Keeping the logic deterministic isn't only about correctness. Every judgment you move from a model to a rule is a model call that never runs, so the same discipline that makes a system auditable makes it cheaper to operate and lighter on the resources behind it. One decision, three payoffs.
I want to be careful with that claim, because sustainable AI is a category with a measurement problem. Published figures for the energy and water behind a single model call vary by orders of magnitude depending on who is counting and what they count. Anyone handing you a clean number is quoting someone else's context.
So I built the instruments instead. The constants are published with confidence tags, the uncertainty is shown on the face of the tool rather than in a footnote, and anything still unsettled is listed as unsettled. Disagree with the numbers if you like: the working is public.
One limit, stated plainly: these are estimates, not certificates. Nothing here certifies a footprint, offsets one, or audits what your vendor actually runs.
Water
What a day of your tech actually draws
A footprint you can move with sliders, with the uncertainty band shown rather than hidden.
Router
Which model you actually need
Most work doesn't need the largest model. This picks the tier the task justifies, and prices it.
Prompt check
Whether the prompt is working or padding
Scores a prompt for what it's actually asking, and rewrites the parts that are just weight.
Eval bench
Whether the cheaper option is really worse
A blind, order-swapped A/B with a paired statistical verdict. Often it isn't worse.
These are maintained on my personal site, where the toolkit lives. How the numbers are made →: constants, derivations, confidence tags, and what's still under review.
You should never have to take my word for what a system did. You should be able to read it back, and check.
The numbers on this site
Every figure here, and how you'd check it.
Promise 03 says there isn't a single time-saved or ROI number on this site. Here is every number that does appear — each one checkable arithmetic, a binding term of sale, or the output of a test you can run yourself. Last re-verified against the pages that carry them on 2026-08-14.
| The number | Where it appears | How it's checked |
|---|---|---|
| $49 per pack · $99 for all three · “save $48” | Toolkits | Arithmetic on the page itself (3 × $49 − $99 = $48). Prices are the offer, set by the owner. |
| 11 prompts per pack · all 33 in the bundle | Toolkits + pack pages | Counted in each page's own prompt list (A1–A11, B1–B11, C1–C11); 33 = 11 × 3. |
| 2 free previews · 3 free prompts | Toolkits + pack pages | The preview gate unlocks exactly two; the free PDF contains exactly three. |
| 14-day full refund | Toolkits | A binding term of sale — terms of sale §2 — not marketing copy. |
| Engagement floors, from $500 to $4,500 | Engagement pages | Floors by design: every engagement page states the exact quote is set before any work begins. |
| 2,300 cohorts · 100% agreement · 0 failures | /proof | Output of a published harness against an independently implemented exact solver, including a selftest that proves the harness can fail. Same seed, same numbers, any machine. |
| 60 scrambled row-orders → 1 pairing | /proof | Runs live in your browser on pinned seeds; the pre-fix control arm must diverge, or the demo reports itself broken. |
| 44 of 60 — the defect behind that demo | /proof | A historical measurement from July 2026, preserved as a comment beside the fix in the engine source. History, labeled as history — the live run shows its own number. |
| Nine gates, one command | Case study | The rebuild's verification suite, runnable as a single command. This wording replaced an earlier version that overstated CI enforcement — caught by this site's own claims audit and corrected. |
| Zero repeat pairings, every run | Cycle Conductor | Holds within the engine's stated no-repeat capacity (roster size − 1 rounds); the demo shows that capacity beside the claim rather than hiding it. |
What's deliberately not here: time-saved and ROI figures (none exist on this site — that's promise 03), case-study system counts (removed in the August 2026 rewrite pending the client's sign-off), and Composa's ROI estimate, which lives on composa.team with every assumption — hours, capture rate, salary — adjustable on the page. Sample deliverables are labeled illustrative; demo rosters are synthetic. The standing rule: no new number ships on this site without a row here.
Five questions to ask before you hand over the keys.
Ask me these too. If a builder can't answer them cleanly, that's your answer.
- “Show me it doing the same thing twice.” If the same inputs can give different outputs, you can't trust it and you can't audit it.
- “Which part is the AI actually deciding, and which is fixed rules?” AI belongs on the wording and the judgment calls, not on the decisions you'd have to defend.
- “Where did that ROI number come from?” If it's borrowed from someone else's context, it's marketing, not a forecast for you.
- “What happens on the day it's wrong?” A good system flags the failure out loud; a careless one writes it silently and you find out later.
- “When you're done, can I run it without you?” If the answer isn't a documented, hand-off-able system, you've bought a dependency, not an asset.
The discipline is the product.
A system you can trust, audit, and explain is worth more than a clever demo, and it's the opposite of the thing that burned you. That's why scope and price are fixed before any work begins, and why every run is reproducible. You stop being the single point of failure for the thing you do every month.
A first conversation is just that: no pitch, no obligation. Scope and price are fixed before any work begins, and everything is documented so the system is yours to run without me. You're not buying a dependency.