← Portfolio

Architecture / Product / Operations

Decision ledger.
What I changed. What I kept.

Most project write-ups show where things ended up. Here are some of the decisions along the way: what needed changing, what I chose to keep, and what the work cost.

DEC-005

Kitchen reno

Replace the lower cabinets. Keep the uppers.

We were replacing the countertops. Then the under-sink dishwasher turned out to be leaking into the basement, and neither that style of dishwasher nor a sink to fit over it was readily available.

Open the evidence →
Choice
Move the dishwasher, change the sink-area cabinets, and expand the work to all the lower cabinets. Keep the original uppers and paint them to match the new bases.
Rejected
Trying to preserve a setup built around an appliance we couldn’t replace, or letting “while we’re at it” take the upper cabinets too.
Cost
An almost full kitchen reno: new lower cabinets, configuration changes, upgraded appliances, plumbing lessons, and unexpected electrical work. The countertop templating had to be reworked once the dependencies underneath changed.
Evidence
The uppers still work and look good with the new bases. Same call I make with infrastructure: replace what needs changing, keep what still works, and give the extra work its own decision.

DEC-001

The Hive / Failure Lab

Treat recovery as a separate capability from access.

Tailscale made a remote Authentik change possible while physical access was hours away.

Open the evidence →
Choice
Require an independent recovery path, explicit rollback, and stop conditions for remote identity work.
Rejected
The assumption that network reachability made the change operationally safe.
Cost
More preparation—and sometimes deferring a change that is technically possible.
Evidence
A successful change became a documented near miss and a reusable change gate.

DEC-002

Bricktelligence

Make memory the product, not a chatbot feature.

A conversational interface was easy to add, but generic answers would not help a collector decide what to build or buy.

Open the evidence →
Choice
Build durable facts, event history, aggregates, inference, and tools before centering the assistant.
Rejected
A stateless chat wrapper over catalog search.
Cost
A deeper data model, asynchronous inference, and more operational surface area.
Evidence
Five product surfaces now feed one context system used by the Archivist and verdict engine.

DEC-003

The Archivist Stack

Open the mechanism. Keep the calibration.

The reusable architecture was valuable to other builders, but product voice and tuning were earned through use.

Open the evidence →
Choice
Release the engine under Apache-2.0 while keeping weights, thresholds, prompts, and routing in a private boundary.
Rejected
Hiding standard machinery as if obscurity made it defensible.
Cost
A stricter architectural seam between reusable code and product-specific judgment.
Evidence
A commercially usable repository with executable setup, tests, security defaults, and no private tuning.

DEC-004

TechBearing (retired)

Put operational context behind tools, not prompts.

Agents needed current system state, but operational truth changes faster than static instructions can be maintained.

Open the evidence →
Choice
Expose typed, live capabilities through MCP over SSE and keep history in durable application state.
Rejected
Copying snapshots into prompts or relying on a model vendor session as memory.
Cost
More service boundaries, ingestion work, authorization, and observability.
Evidence
While I operated TechBearing, roughly fourteen services shared one interface to current context and persistent history. The project is now retired; the architecture is kept here as a case study.