Engineering Evidence – From Requirements to Production

The problem

An engineering observatory built on mock data can demonstrate a screen, but it cannot answer questions about real delivery. Moving it into production meant connecting live sources, making the data useful to individual engineers, and keeping repeat queries responsive without masking source outages or serving stale results indefinitely.

On a three-person team, I wrote the product requirements and much of the design record, shaped a substantial share of the backlog, and implemented key parts of that transition. The product is team-owned and now sees steady, growing weekly use.

My responsibility

I delivered live-data integrations for key engineering views, a personal “my work” timeline, and the shared Redis caching implementation. I also separated the CI gate from deployment and contributed dedicated acceptance checks. Teammates contributed across the wider product; these are the parts of delivery I can attribute to my own work.

The decision: performance without a new dependency on the cache

A single cache lifetime is simple, but engineering data does not all change at the same rate. A catalog can tolerate a different lifetime from a recently updated activity view. Historical records can also be corrected after their original event date, so a date-window key alone does not detect every change.

I implemented the cache in stages: shared fail-open reads, lifetimes selected by data tier, and freshness-versioned keys for supported source tables. The key combines query identity with source-update watermarks. When those watermarks advance, subsequent requests use a new key; the old entries expire through bounded lifetimes instead of requiring broad deletion.

The source remains authoritative. A cache read or write failure does not replace the source result with an outage. If a required freshness probe fails, the request bypasses the versioned cache and queries the source. A source failure still surfaces as a source failure. Expiration remains a backstop, so the design bounds staleness rather than promising perfectly current results on every request.

Implementation and acceptance

I tested the boundaries as well as the successful path: real-Redis integration checks, cache read/write failures, freshness changes, and the source-error behavior. I also worked on acceptance checks for the product’s overview and tool views and separated validation from deployment so delivery follows a successful CI gate.

The cache’s job is narrowly defined: reuse query results where the freshness policy permits it. It does not become the system of record or hide the underlying source’s availability.

Delivered result

Key views now use live engineering data. Engineers have a personal work view, which has become the product’s most-visited page. Main data endpoints became substantially faster after the caching work, and the product is in production with steady, growing use. Internal performance and usage figures are not published here.

Those are delivery and adoption results. Observational engineering signals do not establish that AI caused productivity gains, reduced defects, or improved delivery flow.

Beyond the product

I co-facilitate a guild and office hours for around 38 practitioners and publish sourced briefs. I wrote the team’s harness thesis and seven-layer Agent Delegation Stack, giving engineers and leadership a shared vocabulary for context, controls, evaluations, and delegation. I also packaged review skills and feedback hooks for reuse in the team’s repositories.

Related work: the shared team brain, coding-agent execution, and trust tooling. My working model, Agent = Model + Harness, is developed in the Agent Harness field guide.