Product + approved fitment
Stable product ID, size, minimum load/speed, fitment version. Sample fitment is illustrative.
INDEPENDENT BUILD / RETAIL DECISIONING
A better answer.
Before the customer leaves.
Find compatible tires, see available inventory, and offer a useful alternative. Then inspect the decisions behind the recommendation.
Synthetic dataIllustrative fitmentSimulated retailer identityConnecting to local API…
02 / RECOMMENDATION EVIDENCE
Good options.
Good options.
Clear reasons.
Start with the customer.
Set the requirements, then explore recommendations and the underlying decision trace.
Inspect this execution
Run a recommendation to inspect its evidence.
Availability is a timestamped observation. Confirm stock with the
inventory system before reservation or ordering.
FOLLOW THE SYSTEM
One request.
One request.
Visible decisions.
Select a component to highlight its connections. The local implementation and cloud reference share logical boundaries.
Inventory + location
Quantity, observation time, source event, delivery estimate. Older and duplicate updates cannot overwrite newer stock.
Recommendation + evidence
Compatible options, factor contributions, scope, filter revision, request ID, versions, and measured timing.
INSPECT THE WORK
Built to be
Download demo source ↓
Built to be
questioned.
A reproducible implementation, explicit tradeoffs, and measured results from synthetic scenarios.
My contribution
Discovery, stakeholder and end-user conversations, requirements and PRD, technical architecture, and a bounded prototype with actual data. The engineering team supported production build and deployment.
Read the client case study ↗What this proves
Hands-on implementation of scoped recommendation logic, inventory freshness, state transitions, observable decisions, and failure handling. All demo data and fitment records are fictional.
Setup and source guide ↓Scenario evaluation
Actual local correctness checks and timings, with workload size, measurement conditions and cloud verification limits recorded.
Read the evaluation ↓Machine-readable results ↓The choices behind the implementation.
SQL establishes eligibility.
Compatibility, stock and freshness are deterministic constraints. AI can select explanation emphasis; application code renders product facts.
Decision record ↓Two adapters, one contract.
SQLite keeps the demonstration reproducible. Snowflake uses parameterized warehouse queries and a separately validated connection.
Decision record ↓Stock has a clock.
Inventory is independently timestamped and loaded idempotently. A conversation never converts an old observation into fresh availability.
Decision record ↓Ranking exposes its tradeoffs.
Fixed feature normalization, explicit weights, stable tie-breaking, and separate above-budget upgrade suggestions.
Decision record ↓
WATCH THE REASONING
From a requirement
From a requirement
to a useful answer.
Two-minute visual walkthrough using actual synthetic-demo outputs. Captions explain the decisions and platform boundaries.
This is an independently created demonstration. It does not depict the original client application or verify its production outcomes.