DEV Community: MATT ROSE

The Recovery Industry Has a Decisioning Problem Every recovery team I've talked to has the same complaint in a different outfit.

MATT ROSE — Tue, 07 Jul 2026 22:16:54 +0000

"Our skip data is good but our contact rate is terrible." "We're calling the right number but it's the wrong person." "We can't tell which accounts are worth working until we've already worked them."

These aren't data problems. The data is often fine. The problem is that nobody turns the data into a decision before treatment begins.

What Actually Happens Today
An account lands in a queue. Someone appended a phone. Someone else checked an address. A third system returned a name match. The collector picks it up and dials.

Nobody asked: Is this definitively the right person? Is contact legally permitted right now? Is there an attorney on record? Is the debtor deceased and an estate path required instead?

Those questions get answered during the call — or they don't get answered at all. That's where wrong-party contact happens. That's where suppression violations happen. That's where compliance risk accumulates invisibly until it isn't invisible anymore.

A Decision Is Not a Score
The industry defaulted to scores because scores are easy to produce. A number comes back, you set a threshold, accounts above it go to the dialer.

But a score doesn't tell you why. It doesn't tell you the contact is blocked because there's an attorney of record. It doesn't tell you the phone is unverified. It doesn't tell you the account subject is deceased and the path forward is through a probate representative.

A score compresses the reason out of the answer. That compression is exactly where the compliance risk lives.

Gallus Resolve returns a decision — not a score. Every account gets a documented routing outcome:

Clear to work — identity and contact path confirmed, policy cleared, proceed
Suppress — hard block; do not contact
Enrich — identity exists but contact path needs additional verification
Manual review — meaningful evidence with an ambiguity a human must resolve
Insufficient confidence — file is too thin to route safely
Each outcome comes with the reason, the contact paths that are open, the contact paths that are blocked, and the specific next allowed step.

The Next Allowed Step
This is the part most decisioning systems skip entirely.

Knowing an account is not clear to work is useful. Knowing why and what to do next is what actually moves the file forward.

For a deceased debtor, the next allowed step is not "skip trace harder." It is "identify the estate representative and route through probate policy."

For an account with attorney representation detected, the next allowed step is not "try a different phone." It is "route to the attorney contact script and cease direct debtor contact."

For an account where identity is confirmed but the direct phone is unverified, the next allowed step is "verify ownership through a second independent source before dialing."

Gallus Resolve specifies the next allowed step for every account, every time.

Who This Is For
Healthcare RCM — stale patient accounts, estate and deceased routing, compliance-aware signal handling across fragmented placement histories.

Collection agencies — wrong-party risk reduction, attorney routing, spouse and place-of-employment path evaluation before treatment.

Probate recovery — estate representative identification, executor detection, probate court routing.

Collection law firms — recovery capacity indicators, litigation-aware suppression, legal workflow routing.

Controlled Trial
Gallus Resolve is accepting controlled trial requests. Trials run on a file of up to 500 accounts, return documented routing decisions for each account, and operate in audit-only mode — no consumer contact during the trial.

Account data is accepted only through a secure intake path — never via email.

→ https://gallusresolve.com/trial/gallus-resolve

→ View a sample decision packet: https://gallusresolve.com/trial/gallus-resolve/sample

Gallus Resolve is a decision-support and audit system. It does not provide legal advice. Clients remain responsible for their own contact policies, permissible-use determinations, and compliance review.

When the Output Is Judgment: Designing Decision Layers for Fragmented Identity Signals

MATT ROSE — Mon, 06 Jul 2026 00:13:02 +0000

ORIGINALLY PUBLISHED:

www.gallusresolve.com/articles/when-the-output-is-judgment/index.html

GALLUS Resolve is built around a simple architectural belief: high-volume identity work does not need more raw records. It needs controlled decisions.

A file may contain thousands of people, incomplete fields, stale attributes, conflicting signals, and operational risk hidden inside rows that look ordinary. The buyer does not need another pile of possible answers. The buyer needs to know which records can move forward, which records should stop, which records require review, and why each record was routed that way.

That distinction changes the architecture.

A raw-data system optimizes for retrieval. A decision-layer system optimizes for controlled commitment.

Retrieval asks, “What can we find?”

Decisioning asks, “What are we willing to stand behind?”

Gallus Resolve is designed for the second question.

The decision is the product

In many systems, the output is treated as data: a phone number, an email, an address, a score, a profile, a match, or a list of candidates.

In Gallus Resolve, the output is an operator decision.

That may sound like a wording choice, but architecturally it changes the whole system. A record is not finished because something was found. A record is finished when it can be placed into an operational state:

Safe-contact eligible
Manual review
No match
Do not contact

Those outcomes are intentionally plain. They are designed for operations, not curiosity. The operator should not need to inspect a hundred raw fields to understand what the system is recommending.

The internal system can be complex. The external contract must stay simple.

That is one of the core design principles: complexity may exist inside the decision layer, but the output must reduce complexity for the user.

A file should collapse into queues

High-volume review breaks down when every row receives equal attention.

If a team uploads 10,000 records, the operator should not be asked to read 10,000 stories.

The right interface is a compression layer.

A batch should become something like:

6,840 ready outcomes
1,920 no match
940 blocked
260 manual review
40 urgent exceptions

The operator starts with the 40.

That is the important shift. Gallus is not designed to make every record interesting. It is designed to make most records boring, then isolate the cases that deserve human judgment.

The architecture should make this visible. The dashboard should not be a row viewer first. It should be a command center:

What happened to the file?
How many records resolved cleanly?
How many were blocked?
How many need review?
Which exception queues matter first?
What is the next operator action?

The batch view is not a convenience feature. It is the product surface that makes the system usable at scale.

Ambiguity is a result, not a failure

A good decision system must treat ambiguity as a valid output.

In many products, unresolved records feel like failures. They get buried, retried endlessly, or pushed forward with a weak warning because the product wants to appear useful.

That is dangerous in a domain where the cost of acting on a bad record can be higher than the cost of pausing.

Gallus Resolve treats ambiguity as something to route, not something to hide.

A record that cannot be safely advanced should become a review item, a blocked item, or a no-match item. Each of those outcomes is useful because it prevents the operator from confusing “something was found” with “something is usable.”

This is a major architectural boundary. The system must never be pressured into making the UI look better by making the decision less honest.

A conservative decision is still a decision.

The operator should handle exceptions, not volume

Human judgment is valuable. Human attention is limited.

The mistake many systems make is using human review as a dumping ground. If the machine is uncertain, it throws the whole record to a person. Over time, the review queue becomes a landfill: too many items, too little prioritization, no sense of urgency, and no clear explanation of why anything is there.

Gallus Resolve needs the opposite pattern.

Manual review should be structured. Exceptions should be categorized. The operator should know what kind of judgment is needed before opening the case.

The practical categories can be simple:

Ready for approved next step
Needs human review
Blocked from action
Unresolved
Insufficient support
Requires client decision
No usable outcome

The names matter less than the principle: every exception must have a reason to exist.

The takeaway

Gallus Resolve is designed around a different unit of value: not the record, not the signal, not the possible match, but the decision.

That requires a specific architecture:

Treat each record as an operational decision candidate.
Collapse large files into outcome distributions.
Route ambiguity into named exception queues.
Reserve human attention for cases that require judgment.
Produce review summaries without exposing proprietary mechanics.

The result is a system that does not ask operators to keep up with thousands of records. Instead, it gives them the few decisions that matter.

Every Boolean Permission Is a Race Condition

MATT ROSE — Tue, 23 Jun 2026 17:26:54 +0000

Most production systems do not fail because they forgot to check permission.

They fail because the permission was true too early.

That is the bug.

The system checked whether an action was allowed. The answer was yes. Then time passed. State changed. The account changed. The provider changed. The resource changed. The policy changed. The user clicked again. Another worker acted first. A webhook arrived late. A payment expired. A record was cancelled. A session went stale.

Then the system performed the action anyway because it was still holding an old boolean.

canProceed: true

That is not authorization.

That is a stale opinion.
Booleans Are Not Decisions

A boolean tells you almost nothing.

{
"allowed": true
}

Allowed by whom?

When?

Against what source?

For which action?

For which resource?

For how long?

Under which conditions?

Was the answer live or cached?

Was the provider available?

Was this a real decision or a fallback?

Can the decision expire?

Can it be revoked?

A boolean cannot answer any of that.

A boolean is a compression artifact. It takes a messy, time-bound, conditional decision and crushes it into true or false.

Then the rest of the system pretends that nothing important was lost.

Something important was lost.

Time.
The UI Is Not the Authority

A green button is not permission.

A checked box is not permission.

A dashboard badge is not permission.

A frontend state is not permission.

A user opened a page at 10:01. The backend said the action was available. The frontend rendered the button. The user clicked it at 10:04.

What happened between 10:01 and 10:04?

Maybe nothing.

Maybe everything.

The account could have been suspended. The payment could have failed. The resource could have been reassigned. The policy window could have closed. The external provider could have revoked the state. Another process could have already consumed the opportunity.

The UI does not know.

The UI is a photograph of an old decision.

Production systems should treat every frontend permission as stale by default.
This Is TOCTOU for Product Logic

Security people know this bug.

Time of check. Time of use.

You check a file, then use it later. Between the check and the use, the file changes.

The same bug exists in ordinary business logic.

Except instead of files, the objects are:

accounts
orders
bookings
payments
subscriptions
appointments
permissions
devices
contracts
inventory
external provider state

The pattern is the same:

check state
state changes
use stale check

This is not an edge case. This is the default condition of distributed software.

The world changes between reads and writes.

If your system cannot represent that, it will eventually act on fiction.
Permission Should Be a Lease

Stop treating permission as a boolean.

Treat it as a lease.

A permission lease says:

This subject may perform this action
against this resource
under these conditions
from this authority
until this time
unless revoked earlier.

That is authorization.

This is not:

{
"allowed": true
}

A real permission object should look more like this:

{
"decision": "allowed",
"decision_id": "dec_123",
"subject_id": "user_456",
"resource_id": "res_789",
"action": "execute_transfer",
"authority": "billing_service",
"source": "live",
"issued_at": "2026-06-22T18:45:00Z",
"expires_at": "2026-06-22T18:46:00Z",
"conditions": [
"account_active",
"payment_method_valid",
"policy_window_open"
]
}

Now the system has something it can reason about.

Not just “yes.”

A scoped, time-bound claim.
The Action Boundary Must Recheck

The place where the action happens is the only place that matters.

Not the page load.

Not the eligibility screen.

Not the preview step.

Not the prior API response.

The action boundary.

That is where permission must be validated.

Bad:

async function executeAction(input) {
if (!input.allowed) {
throw new Error("Not allowed");
}

return performAction(input);
}

This is not secure. It is theater.

Better:

async function executeAction(input) {
const lease = await getPermissionLease(input.decision_id);

if (!lease) {
return {
success: false,
status: "permission_missing"
};
}

if (new Date(lease.expires_at) < new Date()) {
return {
success: false,
status: "permission_expired"
};
}

if (lease.subject_id !== input.subject_id) {
return {
success: false,
status: "subject_mismatch"
};
}

if (lease.resource_id !== input.resource_id) {
return {
success: false,
status: "resource_mismatch"
};
}

if (lease.action !== input.action) {
return {
success: false,
status: "action_mismatch"
};
}

return performAction(input);
}

For irreversible actions, even that is not enough.

You recheck the authority live.

async function executeIrreversibleAction(input) {
const lease = await validatePermissionLease(input);

if (!lease.valid) {
return lease.refusal;
}

const live = await fetchAuthoritativeState(input.resource_id);

if (!live.allowed) {
return {
success: false,
status: "state_changed",
reason: live.reason
};
}

return performAction(input);
}

The more serious the action, the closer the check must be to the use.
Cached Permission Needs a Warning Label

Caching is not the enemy.

Unlabeled caching is.

Some workflows can safely use cached state. Many cannot. The problem is when the system hides the difference.

This is not enough:

{
"allowed": true
}

This is useful:

{
"decision": "allowed",
"source": "cached",
"cached_at": "2026-06-22T18:40:00Z",
"max_age_ms": 30000,
"authority": "account_service"
}

Now downstream code can refuse cached authority when live authority is required.

if (permission.source === "cached" && action.requires_live_authority) {
return {
success: false,
status: "live_authority_required"
};
}

That is the difference between an intentional fallback and an accidental lie.
“Success” Should Not Hide the State That Made It Possible

A lot of systems store the final action but not the decision that allowed it.

That is a weak audit trail.

After something goes wrong, the question is not only:

What happened?

The question is:

What did the system believe when it acted?

You need the decision snapshot.

create table action_decision_ledger (
id uuid primary key default gen_random_uuid(),

subject_id text not null,
resource_id text not null,
action text not null,

decision text not null,
authority text not null,
decision_source text not null,

issued_at timestamptz not null,
expires_at timestamptz,
used_at timestamptz,

conditions jsonb,
final_status text,
refusal_reason text,

created_at timestamptz default now()
);

Logs are not enough.

Logs tell you what the code said.

A decision ledger tells you what the system believed.

That is what matters.
Refusal States Are Product Features

A serious system knows how to say no.

Not just with a generic error.

With a precise refusal state.

permission_expired
live_authority_required
state_changed
authority_unavailable
authority_rejected
policy_window_closed
duplicate_action_in_progress
manual_review_required
provider_unconfigured
scope_mismatch

These are not error messages.

They are control flow.

Each one tells the system what to do next.

Retry.

Refresh.

Recheck.

Escalate.

Route to review.

Ask for new authorization.

Stop completely.

Generic failure is useless. Named refusal is operational intelligence.
The Pattern

The pattern is simple.

Ask the authoritative system for permission.
Issue a short-lived decision lease.
Bind the lease to subject, resource, and action.
Revalidate the lease at execution.
Recheck live authority for irreversible actions.
Refuse with named states when stale.
Store the decision snapshot.

That is not complicated.

It is just stricter than most systems are willing to be.

Most systems prefer the comfort of true.

Production does not care about comfort.

Production cares whether the thing is still true when you act.
The Engineering Law

Here is the law:

Never treat permission as a boolean.
Treat permission as a time-bound claim.

A boolean says:

yes

A permission lease says:

yes, for this actor, against this resource, for this action, from this authority, under these conditions, until this moment

That is the difference between a UI state and a production decision.

Final Thought

The most dangerous bugs are not always wrong at the moment they are created.

Sometimes they begin as truth.

The user really was eligible.

The resource really was available.

The policy really did allow it.

The provider really did agree.

The button really did belong on the page.

Then the world changed.

And the system acted as if it had not.

That is why every boolean permission is a race condition.

The fix is not another checkmark.

The fix is time.

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

MATT ROSE — Mon, 22 Jun 2026 03:21:22 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

I used Google AI Studio to build TeleBurn, an ultra-private utility application designed for secure messaging and disposable video communication. The core premise is simple: talk, and then burn it—allowing users to communicate without exposing their phone numbers.

The project was executed in two phases:

The Core Prototype: Built directly inside Google AI Studio to lock down the system instructions, prompt logic, and ephemeral state management.

The Production Deployment (teleburn.site): A hardened, production-ready implementation wrapped in a disciplined, gothic-modern interface that draws on minimal luxury aesthetics, stripping away standard SaaS visual noise to focus purely on utility.

To get the architecture and UI dialed in, I used prompts focused on strict design constraints and solid logic:

"Generate a React layout for an ephemeral messaging interface. The aesthetic must be gothic-modern and strictly adhere to minimal luxury design principles. Use stark, high-contrast typography, absolute grid discipline reminiscent of 1990s-era luxury brands, and avoid any generic SaaS icons or bloated UI elements."

"Write the React state management and backend logic for the disposable message payload. Ensure the data is securely isolated and completely wiped from memory upon the 'destroy' trigger. The implementation must leave zero residual traces in the local cache once read, treating the session with absolute security."

Demo

You can explore the project across both stages of its development: https://ai.studio/apps/f905eb16-4ed0-4863-ae35-28a51bc66ecc

and

https://teleburn.site

The AI Studio Prototype: Explore the core engine and run the interactive applet directly via the Google AI Studio App Link.  https://ai.studio/apps/f905eb16-4ed0-4863-ae35-28a51bc66ecc

The Live Production Site: See the finalized, high-fidelity implementation at https://teleburn.site.

My Experience

Building this highlighted how effectively Google AI Studio bridges the gap between raw system architecture and UI execution. The most surprising part was how well the model adhered to strict design directives—getting it to output a modern, highly disciplined interface required less hand-holding than expected. Instead of fighting the generated code, I was able to spend my time refining the secure data destruction mechanics and deployment.

When No Answer Beats a Wrong Answer: Designing Precision-First Systems

MATT ROSE — Wed, 17 Jun 2026 17:35:53 +0000

Most systems optimize for getting an answer. Some have to optimize for never getting the wrong one. Here's how building for asymmetric error costs changes everything about your architecture.

A note before we start: this is an architecture essay, not a product tear-down. It's just a design philosophy that I think more engineers should be deliberate about.

Two kinds of "wrong"

Most of the systems we build are quietly optimized around a comfortable assumption: that a missed answer and a wrong answer cost about the same. A search result you didn't surface and a search result that's slightly off are both just "not great." You tune for accuracy, you ship, you move on.

Then occasionally you build something where that assumption is not just wrong — it's dangerous.

I've spent the last couple of years building a system where the cost of the two errors is wildly asymmetric. Failing to produce an answer is mildly disappointing. Producing the wrong answer is unrecoverable — it doesn't just degrade the experience, it damages trust in a way you can't apologize your way out of.

Once you internalize that asymmetry, almost every default in modern system design starts to look subtly miscalibrated. This is a tour of what changes.

Accuracy is the wrong headline metric

The first thing that has to go is "accuracy."

Accuracy blends two very different failures into one number. A model that's 95% accurate might be making its 5% of mistakes by staying quiet — or by confidently asserting falsehoods. Those are not the same system. One is cautious; the other is a liability.

The metrics that actually matter when errors are asymmetric are precision and the shape of your failure distribution:

Precision: of the answers you did commit to, how many were right?
Abstention rate: how often did you correctly decline to answer?
False commit rate: how often did you assert something wrong? (This is the one you're really managing. It should be the metric on the wall.)

Recall — how many answerable cases you actually answered — becomes something you sacrifice on purpose. That feels deeply uncomfortable the first time you do it, because we're trained to think coverage is the goal. It isn't. In a precision-first system, coverage is a dial you're allowed to turn down to protect correctness.

"I don't know" is a first-class result

In most codebases, "I couldn't determine an answer" is an afterthought — a null, an empty array, a fallthrough else. It's treated as the absence of a result rather than a result in its own right.

In a precision-first system, abstention is a designed, named, fully-supported outcome. It has its own code path, its own logging, its own downstream handling, its own success criteria. "We looked and chose not to commit" is a correct behavior, and your system should be able to say it as clearly and confidently as it says anything else.

Practically, that means your core decision function doesn't return Answer | null. It returns something closer to:

Decision =
  | Committed(value, confidence, supporting_evidence)
  | Abstained(reason)

Both branches are first-class. Both are tested. Both are observable in production. The moment "I don't know" becomes a real return type instead of a missing value, the rest of the design gets much easier to reason about — because you've stopped pretending every input deserves an output.

A confidence floor you do not cross

The heart of the thing is a gate, and the gate has a non-negotiable floor.

Below a certain confidence threshold, the system does not commit — full stop. Not "commits with a warning." Not "commits but flags for review later." It abstains. The floor is a hard architectural boundary, not a soft suggestion, and it is the same for everyone. No special case, no VIP path, no "just this once because the demo is tomorrow" gets to lower it.

The reason this has to be structural rather than cultural is that confidence floors are exactly the thing that erodes under pressure. Someone will always have a very reasonable-sounding argument for why this case should squeak through. The floor only means something if it's enforced by the system, not by the discipline of whoever is on call that week.

def decide(signals):
    score = evaluate(signals)
    if score < FLOOR:
        return Abstained("below confidence floor")
    if not corroborated(signals):
        return Abstained("insufficient independent support")
    return Committed(resolve(signals), score, signals)

Notice there are two ways to abstain there, which brings us to the second principle.

One strong signal is not enough

A single source being very, very sure is not the same as being right. Confident-but-wrong is the entire failure mode you're trying to eliminate, and a lone high-confidence signal is precisely how it sneaks in.

So the gate asks for more than a high score — it asks for independent corroboration. Two signals that don't share a failure mode, both pointing the same way, are worth far more than one signal shouting. The key word is independent: two measurements derived from the same underlying source aren't corroboration, they're an echo. Designing for genuine independence — making sure your "second opinion" can't fail in the same way as your first — is most of the real work.

This is an old idea in disguise. It's quorum. It's defense in depth. It's why critical systems use multiple sensors that fail differently. The novelty isn't the pattern; it's the discipline to apply it to decisions, not just to availability.

Graceful degradation, not graceful guessing

When part of the system is unavailable — a dependency is down, a signal is missing, something times out — there's a strong temptation to "do your best with what you have." In a precision-first system, that temptation is the enemy.

Degradation should make the system more cautious, not more creative. Fewer signals available means a higher bar to commit, not a lower one, because you have less ability to corroborate. The correct behavior under partial failure is to abstain more often, not to fill in the gaps with optimism. A system that gets bolder as it gets blinder is a system that will eventually hurt someone.

The hardest part isn't technical

Here's the thing nobody warns you about: the engineering is the easy half. The hard half is that a precision-first system will, by design, do nothing in a large number of cases — and "did nothing, correctly" is a genuinely difficult thing for an organization to celebrate.

Stakeholders see the abstentions and read them as missed opportunities. There's relentless gravity toward "can't we just lower the bar a little?" Every conversation, every dashboard, every incentive nudges toward more coverage. And every one of those nudges is asking you to trade away the exact property that makes the system trustworthy in the first place.

So part of the architecture lives outside the code. You have to make the asymmetry legible: show people the cost of a false commit in the same frame as the cost of an abstention, so that "we chose not to answer" reads as the system working, not the system failing. The floor survives only if everyone understands why it's there.

The takeaway

If you're building something where being wrong is worse than being silent — fraud decisions, safety interlocks, anything that touches a real person's trust — consider designing around these explicitly:

Measure precision and false-commit rate, not accuracy. Put the scary number on the wall.
Make abstention a first-class, designed outcome — a real return type, not a null.
Enforce a hard confidence floor in the system, not in the discipline of your on-call engineer.
Require independent corroboration, and do the hard work of making "independent" actually true.
Degrade toward caution. Less information should raise the bar, never lower it.
Make the asymmetry visible to the org, so "correctly did nothing" can be recognized as a win.

Recall is a dial. Trust is a ratchet — it only turns one way, and it turns slowly. Build like the wrong answer is the only one you can't take back, because usually, it is.

If you've built systems like this, I'd love to compare notes on how you keep the confidence floor from eroding over time — that's the failure mode I find myself defending against most.

Admin Panels Are Not Configuration Systems

MATT ROSE — Sun, 14 Jun 2026 05:13:58 +0000

I learned this the annoying way: admin panels are not configuration systems.

They can become one, but not by accident.

Early on, it feels harmless. Someone needs to change a headline. Someone wants to hide a section for one customer. Sales needs a different value on one account. Support needs to fix something without waiting on engineering.

So a field gets added.

Then another one.

At some point the admin panel becomes the place where “configuration” happens, except nothing about it is really controlled. It is just a form writing into something the product reads.

That is fine until people start forgetting what the original default was. Then nobody knows whether a value is global or customer-specific, whether a saved draft is live, whether a generated record used the old value or the new one, or whether rolling something back is going to affect one account or everyone.

That is when the admin panel stops being useful and starts becoming dangerous.

A default workflow carries more weight than people usually admit. Support has learned it. Documentation points to it. Billing logic was built around it. Other parts of the product assume it will still be there tomorrow.

So I do not treat defaults like casual settings anymore.

The source should stay locked. If a customer needs something different, create an override. Duplicate the thing. Version it. Preview it. Activate it when it is ready. But do not let a customer-level edit mutate the source template.

A rough version looks like this:

const sourceTemplate = {
  id: "default_workflow",
  locked: true,
  sourceOfTruth: true,
  sections: [
    { key: "intro", title: "Welcome", visible: true },
    { key: "setup", title: "Setup", visible: true },
    { key: "review", title: "Review", visible: true }
  ]
};

const customerConfig = {
  customerId: "customer_123",
  sourceTemplateId: "default_workflow",
  status: "draft",
  overrides: {
    sections: {
      setup: {
        title: "Account Setup",
        visible: true
      },
      review: {
        visible: false
      }
    }
  }
};

The original stays intact. The customer gets a different version. The admin panel edits the duplicate or the override, not the source.

The status is where a lot of products get sloppy.

I do not want production reading “whatever was saved last.” Saved and live are not the same thing. A draft can be saved. A preview can be rendered. An archived version can still exist for history. None of those should control production.

I usually want something closer to this:

const CONFIG_STATUS = {
  DRAFT: "draft",
  PREVIEW: "preview",
  ACTIVE: "active",
  ARCHIVED: "archived"
};

Production reads active. Not latest. Not preview. Not the thing someone saved five minutes ago while they were still testing copy.

That sounds strict until you have seen the alternative.

The alternative is a support person saving a draft and accidentally changing what customers see. Or a sales override becoming the new default because it was easier to edit the existing object than create a customer-specific layer. Or a generated document pulling today’s value even though it was supposed to reflect what was approved last week.

Those bugs are not always dramatic. Most of the time they are just messy. And messy bugs waste a lot of time because there is no single failing line of code. The product is doing exactly what it was told to do. The problem is that nobody can explain what it was supposed to do.

That is why I prefer resolving configuration in one place.

Do not make every component figure out which version it should use. Do not scatter account checks, copy overrides, feature flags, pricing rules, and visibility logic all over the app. That turns the product into a junk drawer.

Give the app the effective config and let it render.

function resolveEffectiveConfig(customer) {
  const source = getLockedSourceTemplate();
  const activeConfig = getActiveCustomerConfig(customer.id);

  if (!activeConfig) {
    return source;
  }

  return mergeSourceWithOverrides(source, activeConfig);
}

The resolver should be boring. It checks for an active customer config. It ignores drafts and previews in live paths. It falls back to the locked source when nothing active exists. It merges only the allowed overrides.

Everything else should be able to trust the result.

The tests should be boring too.

I want tests that prove drafts do not leak. I want tests that prove previews do not leak. I want tests that prove archived configs do not suddenly become live because they happened to be the last record created.

expect(resolveLiveConfig(customerWithDraftOnly)).toEqual(sourceDefault);
expect(resolveLiveConfig(customerWithPreviewOnly)).toEqual(sourceDefault);
expect(resolveLiveConfig(customerWithArchivedOnly)).toEqual(sourceDefault);
expect(resolveLiveConfig(customerWithActiveConfig)).toEqual(expectedOverride);

That is the kind of test that looks unimpressive until it saves you from a bad release.

Generated records need the same discipline.

If something gets generated from configuration, and that thing needs to remain historically accurate, snapshot the values. Do not keep pointing back to the live config and assume it will still mean the same thing later.

Invoices, agreements, receipts, audit logs, approvals, customer confirmations — anything like that should preserve the values used when it was created.

const generatedSnapshot = {
  customerId: "customer_123",
  generatedAt: "2026-06-14T00:00:00Z",
  configVersion: "v3",
  values: {
    setupFee: 12000,
    monthlyMinimum: 2500,
    transactionSharePercent: 20
  }
};

The current config can change tomorrow. The record from yesterday should not.

Otherwise history starts moving. A document that was generated with one set of values appears to have another. An invoice no longer matches what was approved. A customer asks why the number changed, and the answer is basically, “because the object was still live.”

That is not a good answer.

I have also become much stricter about what gets sent to the browser. The frontend usually does not need the full internal configuration object. It needs the small part required to render the page.

The full object may contain pricing, internal notes, admin flags, version history, legal variables, draft states, implementation details, or things that are not technically private but still should not be sitting in the browser.

So project it.

function projectPublicConfig(effectiveConfig) {
  return {
    sections: effectiveConfig.sections
      .filter(section => section.visible)
      .map(section => ({
        key: section.key,
        title: section.title,
        body: section.body,
        cta: section.cta
      }))
  };
}

The browser gets rendering data. That is all it needed anyway.

The version I trust looks like this:

const effectiveConfig = resolveEffectiveConfig(customer);
const publicConfig = projectPublicConfig(effectiveConfig);

return publicConfig;

For generated records:

const effectiveConfig = resolveEffectiveConfig(customer);
const snapshot = createImmutableSnapshot(effectiveConfig);

saveGeneratedRecord({
  customerId: customer.id,
  snapshot,
  generatedAt: new Date().toISOString()
});

For production UI:

const config = resolveLiveConfig(customer);

renderWorkflow(config);

For preview:

const previewConfig = resolvePreviewConfig(customer, draftConfigId);

renderPreview(previewConfig);

I do not like live and preview sharing the same loose path. That is how preview work becomes production behavior by accident.

None of this is about making configuration fancy. I am not interested in elaborate admin systems for their own sake. The point is control.

Customers will need different things. Internal teams will need to move quickly. The product will need account-level behavior eventually. That is normal.

The problem starts when every one of those needs is solved by making the default more editable.

If an admin panel can change the source, change what is live, change what gets generated, and expose internal state through the same path, it will eventually create a problem that is harder to unwind than it would have been to model correctly in the first place.

The questions I want the system to answer are simple:

What is the locked default?

What is the active customer override?

What is only a draft?

What values were used when this record was generated?

What is safe to send to the client?

If those answers are not clear, the product does not really have a configuration layer. It has a form connected to production.

That might be acceptable for a while. Early products make tradeoffs. I understand that.

But once the system touches real customers, real billing, generated records, or account-specific behavior, the boundary has to get stricter.

Lock the source. Duplicate before editing. Preview before activation. Resolve active config only. Snapshot generated outputs. Send the client only what it needs.

That is the version I trust.

Stop Trusting Every WHERE Clause: Tenant Isolation in PostgreSQL

MATT ROSE — Sat, 13 Jun 2026 01:55:00 +0000

Multi-tenant apps usually start with a simple rule:

Every query needs to be scoped to the current tenant.

That works fine until it doesn't.

Someone writes a new endpoint. Someone adds a reporting query. Someone ships a quick admin tool. One missing WHERE tenant_id = ... later, one account can see data that belongs to another account.

That's the kind of bug that can end a product.

I don't like leaving tenant isolation entirely up to application code. The app should still scope queries correctly, but the database should also enforce the boundary. If the database is the last place where the data lives, it shouldn't blindly trust every query that reaches it.

PostgreSQL Row-Level Security gives you a way to push that boundary down into the database.

The basic idea

Row-Level Security, or RLS, lets PostgreSQL decide which rows are visible for a given query.

Instead of relying only on code like this:

SELECT * FROM customer_records WHERE tenant_id = $1;

you can make the table itself enforce the tenant boundary.

That means a careless query like this:

SELECT * FROM customer_records;

doesn't automatically return everything.

The database checks the active tenant context first.

Start with a tenant anchor

Every tenant-owned table needs an anchor column. In most systems that is something like tenant_id, account_id, or organization_id.

Here's a small example:

CREATE TABLE tenants (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL
);

CREATE TABLE customer_records (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  full_name TEXT NOT NULL,
  email TEXT NOT NULL
);

The important part isn't the table name. The important part is that each row belongs to a tenant.

Now enable RLS:

ALTER TABLE customer_records ENABLE ROW LEVEL SECURITY;

Once RLS is enabled, PostgreSQL will apply policies before returning rows. Without a policy, the table is effectively locked down for normal access.

That default-deny behavior is the point.

Pass tenant context into the transaction

The database needs to know which tenant is making the request.

I usually prefer setting that inside the transaction, then letting the policy read it.

Example using Node.js and pg:

async function getCustomerRecordsForTenant(client, tenantId) {
  try {
    await client.query("BEGIN");

    await client.query(
      "SELECT set_config('app.current_tenant_id', $1, true)",
      [tenantId]
    );

    const result = await client.query("SELECT * FROM customer_records");

    await client.query("COMMIT");

    return result.rows;
  } catch (error) {
    await client.query("ROLLBACK");
    throw error;
  }
}

Notice the query:

SELECT * FROM customer_records

There's no WHERE tenant_id = ... in that query.

The filtering is not gone. It moved into the database policy.

Write the RLS policy

Now connect the row’s tenant_id to the tenant context set on the session.

CREATE POLICY tenant_isolation_policy
ON customer_records
FOR ALL
USING (
  tenant_id = current_setting('app.current_tenant_id', true)::UUID
)
WITH CHECK (
  tenant_id = current_setting('app.current_tenant_id', true)::UUID
);

The USING clause controls which existing rows are visible.

The WITH CHECK clause controls which rows can be inserted or updated.

So if the active tenant is Tenant A, the database should only expose rows for Tenant A. It should also reject writes that try to create or move records into another tenant.

Read isolation and write isolation are separate problems. You need both.

Why this is safer than app-only filtering

Application-layer filtering depends on every developer remembering to write the right condition every time.

Database-enforced isolation gives you a second boundary.

If someone writes:

SELECT * FROM customer_records;

the policy still applies.

If someone writes:

DELETE FROM customer_records;

the policy still applies.

If the tenant context is missing, the comparison does not match tenant-owned rows, so the query should fail closed instead of exposing everything.

That does not mean RLS is magic. You still need to be careful with privileged roles, service-role access, migrations, background jobs, and admin tooling. A bad bypass can still cause damage.

But RLS changes the default failure mode. A missing application filter no longer has to mean cross-tenant exposure.

A few rules I would not skip

Use a tenant context that's set inside the transaction. Don't rely on a loose global variable in application memory.

Keep service-role or admin access away from normal request paths. If you have a role that bypasses RLS, treat it like a dangerous tool.

Test the policies directly. Do not only test the API layer.

For example:

SELECT set_config('app.current_tenant_id', 'TENANT_A_UUID', true);
SELECT * FROM customer_records;

Then repeat with a different tenant and confirm the rows change.

Also test writes:

INSERT INTO customer_records (tenant_id, full_name, email)
VALUES ('TENANT_B_UUID', 'Test User', 'test@example.com');

If the session is scoped to Tenant A, that insert should not be allowed for Tenant B.

Those tests are boring. They are also the kind of boring that prevents ugly production incidents.

Use the database as a backstop

I still write scoped application queries. I still validate permissions in the API. I still treat authorization as an application concern.

But I don't want the database to be passive.

In a multi-tenant system, the database should know enough to say no.

RLS is not a replacement for good application design. It is a backstop for the day someone writes the wrong query, ships the wrong report, or builds an admin endpoint too quickly.

That day comes eventually.

When it does, I would rather have PostgreSQL enforce the tenant boundary than hope every WHERE clause was perfect.

The Catch and Release Pattern: Handling High-Volume Webhooks in Node.js

MATT ROSE — Sat, 13 Jun 2026 01:38:15 +0000

If you are building an API that integrates with third-party vendors, you will eventually face the webhook flood.

When an external service sends a massive spike of webhook events, the standard approach of processing the data and inserting it into a database synchronously will block the Node.js event loop. Your API will time out, the vendor will assume the delivery failed, and you will drop critical data.

To survive unpredictable traffic spikes, you need to decouple the HTTP response from the data processing. Here is how to implement the "Catch and Release" pattern using Node.js, Express, and BullMQ.

Prerequisites

Node.js and Express installed.
A running instance of Redis (required for BullMQ).
Basic understanding of asynchronous JavaScript.

The Synchronous Trap (What Not to Do)

Most developers write their first webhook receiver like this:

app.post('/webhook/inventory', async (req, res) => {
  const payload = req.body;

  try {
    // ❌ Anti-pattern: Heavy processing before responding
    const normalizedData = heavyDataTransformation(payload);
    await database.insert(normalizedData);

    // Vendor waits for the database to finish...
    res.status(200).send('Success');
  } catch (error) {
    res.status(500).send('Failed');
  }
});

The problem: If the vendor sends 500 webhooks a second and your database takes 200ms to insert a record, the database connection pool will max out. Requests will queue up, memory will spike, and the connection will close. The data is gone forever.

Step 1: Implementing "Catch and Release"

The golden rule of webhook ingestion is to acknowledge receipt immediately. We want to return a 200 OK or 202 Accepted status back to the vendor before we do any heavy lifting.

To do this safely without losing the data in memory if the server crashes, we push the raw payload to a persistent background queue.

First, install BullMQ and Redis:

npm install bullmq ioredis

Next, configure the queue:

import { Queue } from 'bullmq';
import Redis from 'ioredis';

// Connect to Redis
const redisConnection = new Redis(process.env.REDIS_URL);

// Create the ingestion queue
const webhookQueue = new Queue('webhook-ingestion', { 
  connection: redisConnection 
});

Now, rewrite the Express route to catch the payload, queue it, and release the connection:

app.post('/webhook/inventory', async (req, res) => {
  const payload = req.body;

  try {
    // 1. Push raw data to Redis immediately
    await webhookQueue.add('process-inventory', payload, {
      attempts: 3,
      backoff: { type: 'exponential', delay: 1000 }
    });

    // 2. Release the vendor connection instantly
    return res.status(202).send('Accepted for processing');

  } catch (error) {
    console.error('Failed to queue webhook', error);
    return res.status(500).send('Internal Server Error');
  }
});

With this pattern, your Express server can handle thousands of requests per second. The route does nothing but write JSON to Redis, which is incredibly fast.

Step 2: Processing the Queue Safely

Now that the data is safely persisted in Redis, we can process it at our own pace using a BullMQ Worker. This worker runs on a separate thread (or an entirely separate server) so it never blocks our Express API.

import { Worker } from 'bullmq';

const worker = new Worker('webhook-ingestion', async job => {
  const payload = job.data;

  // Now we can safely perform heavy processing
  const normalizedData = heavyDataTransformation(payload);

  // If the database is locked, it throws an error, 
  // and BullMQ automatically retries based on our backoff strategy.
  await database.insert(normalizedData);

}, { connection: redisConnection });

worker.on('completed', job => {
  console.log(`Job ${job.id} processed successfully`);
});

worker.on('failed', (job, err) => {
  console.error(`Job ${job.id} failed:`, err);
});

Conclusion

By implementing the Catch and Release pattern, you separate the HTTP transport layer from your business logic.

Express acts purely as a lightning-fast catcher's mitt.
Redis/BullMQ acts as the shock absorber, holding the data safely.
The Worker acts as the engine, processing data only as fast as your database can handle it.

This architecture ensures zero data loss, prevents database exhaustion, and keeps external vendors happy with lightning-fast response times.