CASE 11 / Product & systems
Cloud answers you can trace to the evidence.
A solo-built cloud investigation workspace: snapshot history, costs, and a read-only AI assistant. Live beta by invitation, using sample data.
- THE PROJECT
- Stratum
- THE CONTEXT
- Independent product
- THE CHAPTER
- Invite-only beta
- THE PROBLEM
- Cloud investigations need trustworthy change history and evidence behind an answer.
- WHAT I OWNED
- Solo snapshot engine, comparison logic, investigation UI, read-only tools, and beta access controls.
- THE RESULT
- An invited sample-data beta with linked inventory, costs, history, and real model investigations.
Original concept illustration, not a production screenshot. Internal product details are intentionally kept high-level.
COMPONENTS / RESPONSIBILITIES / SCOPE
How the parts fit together.
The original engine stores history in PostgreSQL. The hosted beta instead serves deterministic sample observations, with Supabase for access and quotas. They share comparison logic but do not silently mix their data.
01
Observations and history
The snapshot engine retains raw evidence alongside normalized resource state. The beta supplies a bounded synthetic scenario.
- The boundary
- Only complete observations publish state or become comparison baselines.
- Implementation note
- A partial attempt remains visible as a diagnostic event, not an apparently empty cloud estate.
02
Shared domain calculations
One pure comparison implementation serves engine and demo history. Costs use exact-decimal aggregation and historical ownership attribution.
- The boundary
- Tags participate in material comparisons; reordered arrays must not produce empty updates.
- Implementation note
- Billing attribution uses inventory observed on the usage date, not just the latest owner's tag.
03
Workspace and read-only tools
React views and per-request MCP tools read the same scoped domain data through FastAPI.
- The boundary
- The tool server fixes the workspace. Model arguments cannot select a different workspace or mutate cloud resources.
- Implementation note
- Evidence links are recorded by successful tool reads, not accepted as arbitrary URLs generated by the model.
04
Bounded beta assistant
Invited users can run real Groq-backed investigations under persistent per-person and shared budgets.
- The boundary
- Usage is reserved before model attempts; unavailable quota storage or exhausted budgets stop the request.
- Implementation note
- There is no automatic paid-provider fallback. Free-hosting cold starts and provider limits remain visible product constraints.
Conceptual responsibility map. Not a production deployment diagram or a screenshot.
01 / The problem.
Before an assistant can explain what changed in a cloud environment, the history must be trustworthy. A partial collection must not imply that missing resources were deleted, and a tag-only change must not disappear from the comparison. I built Stratum around inspectable observations first, then connected an assistant to those records.
02 / My role.
I built Stratum solo, from the Python snapshot and comparison engine to the FastAPI endpoints, React/TypeScript workspace, and MCP-backed assistant. My scope includes inventory and resource history, costs, governance views, evidence links, and the invite-only beta's access and usage limits. The original PostgreSQL engine and the hosted sample-data workspace are separate runtimes.
- My contribution
- Solo implementation of the snapshot pipeline, comparison logic, investigation UI, read-only tools, and beta access and quota controls.
- Shared scope
- The model and hosting are external services. Sample workspaces are fictional contexts, not isolated customer tenants or evidence of real cloud adoption.
- What changed
- An invite-only beta connecting sample inventory, changes, costs, and governance to real model investigations with retrieved-source links.
03 / One investigation, several connected views.
I built the workspace around a resource: find it in inventory, inspect its observed configuration, compare its history, and follow related costs or governance findings. The Ask AI screen adds a conversation and evidence panel to those same records rather than a separate, disconnected chat dataset.
The hosted beta uses synthetic observations and costs. Its assistant makes real model calls, but the data being investigated is sample data. The portfolio's smaller Stratum demo is different again: it uses fixed teaching answers and makes no model calls.
04 / Incomplete collection is not deletion.
The original engine retains running, partial, and failed attempts for diagnosis, while its readers and comparisons use only successful observations. If collection stops halfway through, the resources it did not reach must not suddenly appear deleted.
I also corrected a subtler gap: tags were stored but missing from the material comparison. Attributes and tags now feed the same normalized view for hashing and diffing. The shared comparison code keeps the engine and sample workspace from disagreeing about what changed.
05 / Reconcile costs before explaining them.
Costs are aggregated as Decimal values and returned as decimal strings; the browser converts them only for display and chart geometry. Grouped totals, filtered views, and the ledger come from the same rows, rather than independently assembled dashboard figures.
Ownership attribution uses the inventory observation relevant to the usage date. A resource deleted later still has historical costs. Regression cases check that paginated rows and grouped totals reconcile, including costs for deleted resources.
06 / A source link is a check, not a guarantee.
Each investigation gets a read-only MCP tool server fixed to its workspace. Successful reads record the sources actually retrieved and produce links to the corresponding inventory, comparison, cost, or finding view. The model cannot choose another workspace through its tool arguments.
I bounded conversation input, model rounds, tool calls, and retrieved evidence. The invited beta adds durable personal and shared quotas, with allowance reserved before attempts and no automatic paid fallback. These controls limit access and usage; they do not prove that every sentence in a model answer is correct.
07 / Keep the beta and Azure pilot distinct.
Regression tests cover partial-state exclusion, tag-aware history, cost reconciliation, source links from actual tool reads, workspace scoping, and quota failures. Model tests use stubbed responses rather than billable requests.
An optional organization-scoped Azure pilot is implemented behind a disabled-by-default feature flag. It has not been deployed or verified against a real authorized subscription. Private workspaces without collected data stay empty; sample data is not substituted to make them look connected.
08 / The result.
- Built linked inventory, resource history, change, cost, and governance views.
- Shared material comparison logic between the original engine and the sample-data workspace.
- Connected real model investigations to scoped, read-only tools and inspectable source links.
- Kept beta usage bounded and the unverified Azure pilot explicitly separate.