← Back to the log

Week 20: I Rebuilt a Polished Tax Packet Because the Facts Were Wrong

I produced several polished tax documents for a professional relationship. The problem was that the first version described the underlying WIMPER mechanics incorrectly.

Nothing had been sent yet. I withdrew the packet, corrected the facts, and eventually replaced the whole thing with a simpler source-first email that I reviewed and sent manually.

What Got Built

  • I recast Business Brain as a relationship study instead of a disguised prospecting system. The project now uses three explicit cohorts, keeps research separate from permission, and treats an honest professional conversation as different from an outreach campaign.
  • I rebuilt the Alex Jankowski material around the actual WIMPER mechanics. The corrected version starts with fixed deduction and fixed reimbursement mechanics. It separates the factual program description from the legal and tax questions a professional would need to evaluate.
  • I reduced the final delivery from a polished packet to a source-first email. The larger drafts remain superseded and unsent. I manually sent only the reviewed email after the facts and relationship intent were clear.
  • I completed a revenue and pipeline review without opening the send gate. The system revalidated a partner packet, prepared a retirement queue for old approved drafts, and found 44 contacted prospects whose last logged outbound is more than 48 hours old with no inbound reply.
  • I deployed the July 30 build chronicle with authenticated screenshots. The article and both images work on the immutable Cloudflare deployment address, which gives me a direct receipt for the exact version that was deployed.

Matt’s Build Timeline: 2026-07-31

What Broke (And How I Fixed It)

The biggest failure was a professional-looking document built on a wrong description of the program.

The first Alex Jankowski packet misstated how WIMPER’s deduction and reimbursement mechanics work. That matters because the packet was intended for a tax professional. A neat layout, careful headings, and citations cannot rescue a document if its starting facts are wrong.

This is a dangerous failure mode when building with agents. The system can turn an unverified premise into a convincing artifact faster than I can notice the premise was weak. More polish can actually make the error harder to challenge because the document looks finished.

I caught the problem before delivery.

The inaccurate packet was marked as superseded and kept unsent. I rebuilt the material around the fixed deduction and fixed reimbursement mechanics, narrowed the open questions, and checked the relevant sources before deciding what Alex should actually receive.

Then I made another correction. Even an accurate technical packet was too much for the relationship at that moment. It risked turning a professional conversation into an assignment or asking someone for unpaid review work.

The final email was shorter and more honest. It gave Alex the source material and invited a conversation or questions. It did not pretend that a relationship was a sales sequence, and it did not attach authority to drafts that had already been replaced.

A second break remains unresolved in the outreach system.

The direct email log and the event bus still disagree by one send. The event bus is the system’s stream of activity receipts. The email log is the direct record of sending. A one-record disagreement sounds small, but it means an automatic follow-up could act on uncertain history.

The audit also found 44 contacted prospects whose last recorded outbound is more than 48 hours old with no inbound response. I did not interpret that as a queue to clear. I treated it as a reconciliation problem and kept sending closed.

The third break is at the edge of the website.

The July 30 work-log screenshot returns the correct PNG on the immutable Cloudflare deployment URL. The custom-domain path, however, serves the site’s HTML fallback instead of the image. In plain English, the deployment contains the right file, but the address readers normally use is still returning the wrong type of page.

A targeted cache purge is blocked because the current Cloudflare token does not have purge permission. I recorded that as an open blocker. I did not claim that one working deployment URL proved the public path was fixed.

Finally, GitHub’s commits API returned HTTP 401 again. That means the remote credential was rejected. Verified local git history supplied the 14-commit count instead, so the record uses a named fallback rather than an estimate.

The Lesson

Validate the operating mechanic before creating the artifact.

Here is what I would tell someone using an agent to prepare professional material: write the factual mechanism in plain language first. Confirm that description against primary sources and the people who understand the operation. Only then ask the agent to build the memo, packet, presentation, or email.

Treat polish as a risk multiplier when the premise is uncertain.

A rough note invites correction. A five-page packet can make an unverified assumption feel settled. Add a factual gate before formatting, and make every review-stage artifact easy to supersede without creating pressure to defend work that should be discarded.

Separate research, permission, and delivery.

Finding a useful source does not authorize an email. Preparing a packet does not mean the recipient should receive it. Keep those steps distinct so a person can stop the process after new evidence changes either the facts or the relationship fit.

Let zero be a successful production result.

Several checks ran today and correctly produced no sends, no prospects, no social posts, and no duplicate topics. A gated system is doing useful work when it prevents weak or uncertain output from becoming public activity.

Work Log: 2026-07-31

The Numbers

  • Commits: 14 total (0 agent, 14 Matt)
  • Agent jobs run: 22
  • Prospects added: 0
  • Emails sent: 0 tracked by the build-log window
  • Social posts: 0
  • Content publication and deployment receipts: 3
  • Stale contacted records needing reconciliation: 44
  • Unresolved send-ledger difference: 1
  • Superseded inaccurate packets sent: 0

The most important number is 0.

Zero inaccurate packets went out. Zero held outreach was released while the ledgers disagreed. Zero duplicate content was created just because a scheduled job expected something to do.

The 14 commits and 22 agent-job proxies show that the system was active. The zeros show that activity did not automatically become external action. That distinction is one of the main controls I want in a system that can produce polished work faster than I can review it.

What’s Next

Reconcile the one-send ledger difference and the 44 stale contacted records, then repair the custom-domain image path before treating the July 30 screenshot delivery as complete.