Operator proof 01 / Leads
The useful part was knowing when not to send.
Generating a friendly text is easy. The real job is deciding whether the system has the right to send one - and proving what happened afterward.
The test
I built a fictional HVAC intake fixture with six cases: one valid urgent request and five conditions that should stop or escalate the workflow. The operator could normalize, deduplicate, check consent, and classify automatically. It could not contact anyone without approval.
One eligible lead
Matched service, territory, consent, urgency, and deduplication rules. The system prepared an approval packet instead of sending.
A bounded approval
The packet included consent provenance, exact message, reason, payload hash, expiry, remaining cap, and the stop rule.
Five correct non-actions
Duplicate lead
Blocked before contact.
Suppressed contact
Blocked by the contact policy.
Out of territory
Escalated without contact.
Malformed record
Quarantined for review.
Emergency phrase
Escalated without an automated response.
"Done" required an outside receipt
After a fictional owner approved one dry-run message, the simulated executor returned a provider-style ID. A separate fixture reader then checked the destination disposition. Only after both matched did the receipt become verified.
What this proves
A bounded mechanism can observe, decide, ask, act inside a cap, verify, and report. It also shows why an unknown send must freeze instead of retrying blindly.
It does not prove production delivery, conversion lift, response speed, revenue, or reliability. KaiCalls contains real intake and follow-up infrastructure, but production behavior depends on each business's configuration and active workers.
Custom workflow
Score your workflow
Take the readiness scoreReady-made lead operator