Doug Dennis posted an update — Aug 20, 2026 05:57 PM EDT

author: Doug Dennis date: 2026-08-20 number: 5 series: Engineering Notes from Butler subtitle: Quarantine Is a State, Not a Verdict tags:

• Butler
• TrustGate
• Quarantine
• Human Judgment
• Automation
• Engineering
• Build Week title: "Engineering Notes from Butler #005" ---

Engineering Notes from Butler #005

Quarantine Is a State, Not a Verdict

Most email systems eventually have to make a decision. A message is spam or it isn't. A sender is allowed or blocked. A message belongs in the inbox or somewhere else. The problem is that some of those decisions are difficult to make when there simply isn't enough information available to make them well.

That is why Butler treats quarantine differently. Quarantine isn't a verdict or even necessarily a judgment about the sender. It is a temporary state that says something much simpler:

We don't know enough yet.

Consider what happens when a message arrives from an unknown sender. A conventional inbox generally allows the message through and leaves the recipient to figure it out. Read it, recognize the sender, decide whether it matters, delete it, ignore it, report it as spam, or perhaps create a rule so the same thing doesn't happen again. Multiply that by dozens or hundreds of messages, and the user effectively becomes the filtering system.

Butler changes the sequence. When an unknown sender is quarantined, Butler hasn't decided that the sender is bad. It has simply determined that there isn't enough evidence yet to justify consuming the recipient's attention.

TrustGate then creates an opportunity to acquire another piece of information. The sender is asked to take a secondary action to pursue the communication. If that happens, we now know something we didn't know when the original message arrived: someone on the sending side cared enough about reaching the recipient to engage again.

That doesn't prove the message is wanted, automatically make the sender trusted, or remove the recipient's judgment. It simply reduces uncertainty.

Once the message is released from quarantine, it can return to the inbox. The recipient may read it and move on without making any additional decision at all. Or the recipient can exercise deeper judgment and accept the relationship, ignore it, filter future messages, block the sender, or establish trust.

The important difference is that the recipient is no longer making those judgments against the original flood of unknown messages. Maybe 100 messages required some level of judgment before. Now only a few do, and those few arrive with an important additional data point: someone on the sending side actively pursued the communication after the initial message was quarantined.

That is a very different problem to solve.

Many automation systems are designed around the idea that the machine should eventually make the final decision. More data, better algorithms, and increasingly sophisticated classification are expected to progressively remove the human from the process.

But some decisions don't need to be removed. They need to be reduced.

The engineering objective then becomes less about achieving perfect classification and more about reducing uncertainty before asking a human to exercise judgment. Automation does the high-volume work where useful distinctions can be made efficiently. Human judgment remains available for the much smaller number of decisions where context, preference, and changing circumstances still matter.

And that judgment doesn't have to be permanent. Relationships change over time. A sender who was useful six months ago may no longer be useful today. A vendor relationship ends, a newsletter becomes noise, or a sender who originally respected the relationship begins abusing the access they were given.

Permission at one point in time does not necessarily create permission forever. The mailbox owner still owns that decision, including the ability to make a different decision later as the relationship changes.

That is an important distinction in Butler. Each stage improves the evidence available to the next stage, but none requires the user to permanently surrender authority over what happens afterward.

Quarantine isn't rejection. Validation isn't approval. Trust isn't necessarily permanent. They are different states in a system designed to progressively reduce uncertainty while preserving human judgment where it matters.

That may be the more useful role for automation.

Good automation doesn't eliminate human judgment. It reduces the number of decisions humans must make, improves the evidence available when they make them, and preserves their ability to change those decisions when circumstances change.

Doug Dennis posted an update — Aug 12, 2026 09:02 AM EDT

author: Doug Dennis date: 2026-08-12 number: 4 series: Engineering Notes from Butler subtitle: Building Institutional Memory tags:

• Butler
• Institutional Memory
• AI Development
• Engineering
• Build Week title: "Engineering Notes from Butler #004" ---

Engineering Notes from Butler #004

Building Institutional Memory

During our Build Week presentation, we briefly mentioned something we called institutional memory.

It played an important role in how Butler was built.

We never really explained what it was.

Anyone who has worked with AI over a long period of time eventually encounters the same problem. The conversation may be intelligent, productive, and surprisingly deep. But the project soon becomes larger than the conversation.

Decisions were made three weeks ago. An architectural constraint was established in another thread. A bug was fixed for a very specific reason. A design idea was considered and rejected. A source file was superseded. Somewhere in all of that history is the reason the system looks the way it does today.

Simply asking the AI to remember more is not enough.

So we stopped treating memory as something the AI should possess and started treating it as infrastructure the project should provide.

For Butler, that infrastructure lives outside the conversation.

We created a governed project repository containing startup instructions, project indexes, current source authority, architectural decisions, carry-forward documents, historical conversations, and retrieval instructions. When a new Butler session begins, the AI does not simply resume from whatever it happens to remember.

It boots into the project.

The startup process establishes which instructions are active. The Butler project loader establishes the rules for working inside Butler. Current project files establish authority. A separate retrieval layer provides access to prior conversations and design history when that history becomes relevant.

That distinction turned out to be important.

Historical conversations are evidence.

They are not authority.

A six-month-old discussion may explain why a decision was made, but it cannot override the source code that is running today. A carry-forward may describe where we thought the project was headed, but it does not automatically supersede a later architectural decision. A remembered filename does not become current simply because the AI recognizes it.

The system has to resolve those differences.

In practice, our institutional memory operates on a simple principle:

Retrieve first. Resolve authority second. Then reason.

That changed the nature of the collaboration.

Instead of repeatedly reconstructing Butler from fragments of conversation, we could preserve the reasoning behind the system and make it available when needed. New sessions became less about reminding the AI what we had done and more about reestablishing the current state of the project.

It also reduced a subtle but dangerous form of AI drift.

An AI can produce a perfectly reasonable answer based on an outdated assumption. The answer may even sound convincing. But if the underlying condition changed two months ago, good reasoning applied to stale information still produces the wrong result.

Institutional memory does not eliminate that risk.

It gives us a way to govern it.

And during Build Week, that mattered. We were working quickly, moving between implementation, testing, documentation, presentation development, and earlier Butler design decisions. The value of the memory system was not that the AI remembered every conversation.

It was that the project could tell the AI where to look, what had happened before, and which version of reality controlled now.

There is an interesting symmetry here.

Butler itself is built around the idea that evidence and authority are not the same thing. A history of correspondence may provide evidence of a relationship, but it does not automatically create permanent permission to reach an inbox.

We eventually discovered that AI-assisted development needs the same discipline.

Memory provides evidence.

Governance establishes authority.

That may be the more useful definition of institutional memory in an AI project.

Institutional memory is not remembering everything. It is knowing what to retrieve, where to retrieve it, and which version of the truth governs when memories disagree.

Doug Dennis posted an update — Jul 27, 2026 03:14 PM EDT

title: "Engineering Notes from Butler #003" subtitle: "TrustGate: The Contract to Contact" series: "Engineering Notes from Butler" number: 003 date: 2026-07-25 author: Doug Dennis tags:

• Butler
• TrustGate
• Email Security
• Governance

- Engineering

Engineering Notes from Butler #003

TrustGate: The Contract to Contact

Every permission-based system develops the same weakness over time: access outlives the reason it was granted.

An employee receives spending authority for a legitimate business purpose. A network user is given access to systems needed for a particular role. A sender is allowed into an inbox because a relationship once existed.

The original decision may have been entirely reasonable.

The problem comes later, when the permission remains in place long after the circumstances have changed.

Roles evolve. Relationships fade. Responsibilities shift. Yet access often continues because reviewing and rebuilding the rules seems more difficult than leaving them alone.

That is how access becomes stale.

And when stale access accumulates across an organization, isolated misuse can grow into systemic abuse.

Experienced leaders have encountered this problem in other domains and responded with a remarkably consistent method: remove inherited access, require legitimate need to be demonstrated, and restore only what remains justified.

One newly appointed financial executive discovered that employee purchasing privileges had become loosely governed over time. Company-issued cards were being used for expenses that had little or nothing to do with the business. Rather than attempting to untangle years of exceptions one transaction at a time, the executive suspended the cards and required employees to establish why purchasing authority was necessary for their work.

The result was not the elimination of spending access. It was the reconstruction of appropriate spending access.

Legitimate needs were restored. Unnecessary privileges disappeared. Opportunities for abuse were reduced.

A senior network engineer took a similar approach after joining an organization whose employees had accumulated broad access to digital assets. Rather than assuming that every existing permission remained valid, he temporarily removed access and personally handled requests as employees encountered systems they genuinely needed.

Over the next several days, access was rebuilt around demonstrated operational requirements.

Again, the objective was not to prevent people from working. It was to replace inherited permission with justified permission.

These examples establish two important points.

First, stale access is not unique to email. It is a natural condition in any permission-based system that is allowed to operate without active governance.

Second, resetting inherited access and restoring only what remains necessary is a proven and highly effective way to reduce risk.

TrustGate applies that same principle to the inbox.

Traditional email assumes that possession of an address creates ongoing permission to use it. Once a sender reaches an inbox, that access can continue indefinitely, even when the original relationship has weakened, ended, or never truly existed.

But knowing an email address does not create a right to contact its owner.

A past interaction does not automatically justify future access.

TrustGate introduces the missing governance layer by creating what amounts to a contract to contact.

The sender’s access is based on an identifiable relationship. The recipient recognizes or approves that relationship. Trust is granted deliberately rather than assumed permanently.

Butler also has an advantage over the earlier examples.

The financial executive had to wait for employees to request restored purchasing authority. The network engineer had to rebuild permissions as calls arrived.

TrustGate can examine mailbox history before activation. It can identify likely legitimate correspondents and help establish an initial trust boundary using evidence that already exists.

That makes the transition less disruptive without changing the underlying principle.

History does not create permanent permission.

History provides evidence from which permission can be evaluated.

TrustGate did not invent the idea of replacing inherited access with justified access. Finance leaders have used it. Network architects have used it. Mature permission systems depend on it.

Butler simply brings that proven governance discipline to email.

Access is not a right created by possession of an address. It is permission created by a relationship.

Doug Dennis posted an update — Jul 24, 2026 01:57 PM EDT

title: "Engineering Notes from Butler #002 — Why “Known Before Allowed” Came First" series: "Engineering Notes from Butler" part: 2 subtitle: "Why trust had to precede intelligence" date: 2026-07-24 author: "Doug Dennis"

tags:

• Butler
• TrustGate
• Known Before Allowed
• AI Engineering
• Governed AI
• Email Trust
• Engineering
• Institutional Continuity

status: revised

Engineering Notes from Butler #002

Why “Known Before Allowed” Came First

Welcome to the New Old World

This principle did not emerge from a whiteboard exercise. It came after more than forty years of observing, using, building around, and living with email—and repeatedly experiencing the same fundamental problem.

The problem has not disappeared. It has intensified.

Email abuse has become more automated, the language more calculated, and the targeting more precise. Artificial intelligence now allows unwanted messages to sound more natural, more personal, and more credible than ever before. The line between ordinary spam and an intentional scam has become increasingly difficult to see.

The technology is new, but the underlying problem is not.

Welcome to the new old world.

For Butler, that history eventually produced a simple architectural principle: Known Before Allowed. It was not created as a slogan after the system was built. It came first because every attempt to automate email eventually returned to the same question:

Who gets to decide whether this communication is wanted?

The Problem with Traditional Email Automation

Traditional spam filtering works for the same reason it fails: it is built on aggregate behavior.

Spam systems examine patterns across enormous populations. They observe what people delete, report, ignore, block, or treat as suspicious, then use those trends to predict what an individual recipient probably does not want.

That approach can be effective. It is often described as the wisdom of the crowd, and the wisdom of the crowd works when the crowd is actively and knowingly expressing a preference.

The weakness appears when a system converts aggregate behavior into an assumed individual decision. The system effectively says, “Most people do not want this, so you probably do not want it either.”

Email, however, is personal. Context is personal. Relationships are personal.

A message that is meaningless to ten thousand people may be critically important to one. One person’s solicitation may be another person’s opportunity. One person’s interruption may be another person’s long-awaited introduction.

As the old saying reminds us, one man’s junk is another man’s treasure.

Traditional filtering tries to infer what the recipient does not want. Butler begins by establishing what the participants themselves do want.

Why Automation Without Trust Creates Risk

Automation amplifies assumptions. When those assumptions are correct, automation becomes useful and efficient. When they are wrong, automation makes the wrong decision faster and more consistently.

A system that routes, classifies, prioritizes, summarizes, or acts upon an email before establishing the legitimacy of the relationship is operating on an unverified premise. That becomes more dangerous as automation grows more capable.

AI can generate convincing language, imitate tone, personalize outreach, and manufacture the appearance of familiarity. The result is not merely more spam. It is a growing category of increasingly sophisticated spam-scams designed to persuade the recipient that a relationship, obligation, opportunity, or urgency already exists.

That led to one of Butler’s earliest architectural conclusions:

Intelligence should never outrun trust.

Before automation becomes useful, it must first become governable.

The Origin of “Known Before Allowed”

Every proposed Butler feature eventually produced the same question: What happens if we have never seen this sender before?

Every answer that skipped that question felt incomplete. The first decision Butler needed to make was not where to route a message, whether the message appeared important, or whether an AI model considered it legitimate.

The first decision was whether a trusted communication relationship actually existed.

That realization changed the architecture. Instead of beginning with classification, Butler begins with permission. Instead of assuming a relationship, Butler establishes one. Instead of allowing an algorithm, a crowd, or an AI system to infer consent, Butler asks the parties involved.

Known Before Allowed means no system should presume a relationship that the participants themselves have not established.

TrustGate Flips the Model

Spam filters ask the crowd whether a message is probably unwanted. TrustGate asks the two people involved whether they both want the conversation to occur.

The sender must demonstrate a genuine intent to communicate. The recipient must grant permission to receive that communication. Together, those actions create a double opt-in.

Trust does not originate from an algorithmic score, a mass preference, a reputation database, or the confidence of an AI model. It emanates from both sides of the desired conversation.

The sender confirms intent. The recipient confirms acceptance. Only then is the relationship allowed to move into Butler’s trusted environment.

This is the essential difference:

• Filtering estimates; TrustGate verifies.
• Filtering assumes preference; TrustGate establishes permission.
• Filtering predicts what the recipient may reject; TrustGate confirms what both parties accept.

That is not simply a better spam filter. It is a different communications architecture.

The Runtime Boundary

In Butler’s runtime model, TrustGate operates before ordinary classification, routing, summarization, and other downstream automation.

The practical sequence is straightforward:

unknown sender → controlled pending state → sender validation → recipient approval → trusted relationship → automation allowed

A message from an unknown sender is not passed directly into normal routing. It enters a controlled state where uncertainty is contained while the relationship is evaluated.

Sender validation establishes intent. Recipient approval establishes permission. Only after both conditions are satisfied is the relationship promoted to trusted status and made eligible for downstream processing.

That boundary creates several concrete engineering rules:

• Unknown senders do not enter ordinary automated routing.
• Trust is maintained as governed relationship state.
• Downstream rules operate only after that state exists.
• AI confidence cannot override trust policy.
• Exceptions remain visible, reviewable, and auditable.

The important architectural move was not making every downstream rule more intelligent. It was making the entrance more trustworthy.

Governed AI Versus Autonomous AI

Artificial intelligence naturally encourages the question, “What else can the system do automatically?” Butler asks a different question first: “What authority should the system have?”

That distinction separates autonomous AI from governed AI.

Autonomous AI emphasizes capability. Governed AI combines capability with permission, boundaries, evidence, and accountability. Within Butler, AI may help recognize patterns, classify messages, summarize content, recommend actions, or improve a user’s judgment.

But AI does not create trust merely by declaring confidence.

Capability is not permission. Prediction is not consent. Confidence is not authority.

TrustGate embodies that distinction by requiring the communication relationship to be established before intelligence is permitted to act upon it.

Looking Ahead

Known Before Allowed became Butler’s first architectural principle because every later capability depends upon it. Routing, classification, AI assistance, learning, and policy enforcement all depend upon knowing where trust exists and where authority begins.

After more than forty years of email, the industry has become remarkably sophisticated at estimating what people probably want. Butler begins with a simpler and more durable idea:

Ask them.

Ask the sender. Ask the recipient. Let trust arise from both sides of the conversation.

No matter how intelligent automation becomes, it should never presume a relationship the people involved have not chosen.

That is why Known Before Allowed came first.

Doug Dennis posted an update — Jul 22, 2026 11:47 AM EDT

title: "Engineering Notes from Butler #001 — The Build Week Experiment" series: "Engineering Notes from Butler" part: 1 subtitle: "What a three-day sprint taught me about AI-assisted engineering" date: 2026-07-22 author: "Doug Dennis"

tags:

• Butler
• TrustGate
• OpenAI Codex
• Build Week
• AI Engineering
• Engineering
• Institutional Continuity

status: published

Engineering Notes from Butler #001

The Build Week Experiment

With the Build Week deadline behind us, I can finally share what made this sprint so interesting.

Yes, we prepared Butler for Build Week in just a few days. But the real story is that this was the first time I intentionally brought OpenAI Codex into an existing, production-oriented project.

Butler wasn't a blank slate. It already had months of engineering, architectural decisions, operational experience, and governance behind it. The challenge wasn't simply to generate code. It was to determine whether Codex could become a productive engineering partner without disrupting the discipline that had made Butler reliable.

The experiment exceeded my expectations—but not for the reasons I expected.

Codex accelerated implementation because it operated within clearly defined engineering boundaries. It worked from preserved context, current authoritative files, documented decisions, and explicit instructions about what it could—and could not—change.

We weren't asking AI to invent the architecture.

We were asking it to help extend that architecture responsibly.

That experience reinforced something I have come to believe deeply:

AI is most powerful when it amplifies human judgment, not when it replaces it.

Over the next few days, I'll share more about that sprint, what we learned, and why Butler's guiding principle remains:

TrustGate

Known Before Allowed

Engineering Notes from Butler is an ongoing series documenting the design decisions, experiments, and lessons learned while building Butler—a governed AI-assisted email trust and automation platform.

Doug Dennis started this project — Jul 21, 2026 07:21 PM EDT

Leave feedback in the comments!