Historical vehicle valuation with calibrated uncertainty.
A React and FastAPI application backed by a trained Random Forest model. The data
pipeline checks source permissions, normalizes records, and separates asking prices
from completed sales.
Inference checks the model and calibration artifacts before returning an estimate
and prediction interval. A separate River simulation explores learning from new
outcomes.
IN DEVELOPMENT
I’m building an agent workflow to collect vehicle data from approved sources.
Extraction and evidence checks run on test fixtures I control; external
acquisition remains in development.
python · scikit-learn · fastapi · react · river
FailureLab
ACTIVE DEVELOPMENT
RECORDED WALKTHROUGHDEMO VIDEO
0:28 · Owned fixtures with the deterministic baseline. Recorded browser experiments.
CI investigation with reproducible browser experiments.
FailureLab retrieves logs, source, and browser evidence, then tests a proposed
intervention against the failing baseline. A LangGraph workflow handles diagnosis
and planning.
The application derives verdicts from recorded runs. Evidence and checkpoints are
retained for review and replay; the model cannot assign the final finding.
IN DEVELOPMENT
I’m expanding the investigation workflow and testing it beyond the current
fixtures. Provider acceptance, deployment checks, and release review remain open.
I built EICC to track requirements through integration tests and release decisions,
using a fictional enterprise called Northstar.
REST and SOAP tests run against local simulators. Contract fingerprints invalidate
stale evidence, and the server rechecks release gates before a transition.
IN DEVELOPMENT
I’m continuing work on the requirements and release workflows. The next feature
scope is still open.
AutoValue defines its target and checks data rights before model fitting. Record
identity survives processing, and the application serves a frozen model that
research experiments cannot change.
The problem
The sources report different kinds of prices. A monthly payment is not a vehicle
price, and an advertised price is not a completed sale. AutoValue keeps those
meanings separate and checks for duplicates and leakage before evaluating a model.
The implementation
Source-specific adapters map records into a common schema. Prices use integer
cents; text and mileage are normalized. Source identity and content hashes detect
duplicates, while malformed or conflicting rows enter quarantine with their
lineage intact.
The model boundary
RF05 uses scikit-learn preprocessing and Random Forest regression. Numeric
imputation and categorical encoding are fitted inside training folds. A separate
partition calibrates the prediction interval, and a frozen final holdout is
reserved for evaluation.
The serving boundary
FastAPI checks artifact hashes, estimator identity, fitted structure, and
calibration binding. Invalid or missing artifacts return a controlled 503. SQLite
retains a bounded history scoped to a hashed anonymous browser identifier.
RESEARCH AND SERVING
River runs as a separate shadow-learning simulation and cannot update the serving
model. The V2 research CLI has optional AI-assisted extraction, evidence
corroboration, and a private SQLite ledger. Those components have run on synthetic
fixtures. The documented external acquisition attempt stopped at browser and access
limits.
↗Actual application capture · repository-owned example vehicleClick to inspect ↗
Testing the boundaries
The repository includes tests for normalization, invalid records, provenance,
training permissions, evaluation separation, calibration, model authentication,
API contracts, history isolation, and shadow-learning behavior.
Outcome & limitations
The application returns historical 2023 U.S. asking-price estimates and calibrated
intervals. Errors vary across vehicle groups and intervals can be broad. The
private estimator is excluded from the public repository; a clean clone needs that
artifact for inference. Live-market valuation and production adoption are
unverified.
What I’m developing next
IN DEVELOPMENT
Agentic acquisition & processing
I’m developing an agentic workflow for finding records in approved sources and
extracting vehicle data. The V2 code already exercises evidence checks,
normalization, identity grouping, and governance on owned fixtures. Work
continues on the external acquisition workflow.
FUTURE
Verified outcomes for learning
The next direction is acquisition from authorized external sources, with
evidence confidence and explicit separation of asking prices from verified
sales. Only approved, verified outcomes should reach downstream learning. That
live pipeline is still planned.
Following an investigation from evidence to replay
FailureLab starts with the failed assertion and retrieves logs, source from the
failing commit, and browser evidence. The investigation proposes an intervention and
compares its behavior with the original failure.
01
Collect & retrieve
Authenticated import and HMAC-validated GitHub webhooks create bounded evidence
snapshots. Redacted content receives stable IDs and hashes. BM25 and exact
identifiers retrieve evidence within each investigation; neural retrieval and
reranking are optional.
02
Diagnose & plan
Two LangGraph stages return typed diagnoses and intervention plans. Pydantic
checks citation IDs, hypotheses, action names, and repetition budgets. Chat mode
uses a model provider; explicit baseline mode uses deterministic signatures.
03
Execute & verify
Playwright runs fresh, interleaved baseline and intervention contexts with the
same assertions. A finding is supported only if every baseline run fails and
every intervention run passes. Mixed results remain inconclusive.
04
Retain & replay
SQLAlchemy storage, leased jobs, heartbeat renewal, bounded retries, and
persistent checkpoints support recovery. Completed-case replay validates stored
identity and report data before returning the existing result without new
inference or execution.
↗Actual application capture · authored development incidentClick to inspect ↗
Constrain execution
The local runner accepts application-owned fixtures. Imported repositories require
an authenticated Linux runner, a reviewed manifest, and a disposable VM. Models
select typed actions; they cannot provide arbitrary shell commands. Provider
failures stop the workflow and consume the persistent call budget.
Validation & current scope
Tests exercise API contracts, live browser behavior, replay, crash recovery,
security boundaries, and release gates. An authored GitHub incident completed a
real Linux experiment. The v0.1.2 release gate remains incomplete following
provider availability failures; deployment smoke testing and human review remain
outstanding.
WHAT THE RESULT MEANS
A supported result applies to the tested mechanism in the recorded environment. The
authored fixtures check system behavior; production diagnostic accuracy remains
unmeasured. Reports preserve unsuccessful attempts and identify missing evidence.
What I’m developing next
IN DEVELOPMENT
Agentic investigation
I’m expanding the automated investigation workflow. The current code has
separate diagnosis and planning stages with typed outputs and executable
verification. The broader workflow remains in development; the live provider
acceptance gate, deployment checks, and human review are still outstanding.
FUTURE
Broader validation
The documented next step is to evaluate independent incidents with a frozen
holdout. Optional neural retrieval and deployment adapters also need measured
acceptance before making claims about their benefits.
Actual EICC workspace. The Northstar scenario is fictional.
IMPLEMENTED
EICC / ENGINEERING NOTES
Tracking requirements through integration and release
Northstar’s fictional case-intake workflow spans legacy records, documents,
notifications, identity, reporting, and a partner gateway. In EICC, an analyst can
follow a requirement through those systems to its tests and release evidence.
The problem
An interface change can invalidate a test, a stakeholder approval, and a release
decision. A dashboard needs to derive readiness from the current contract and its
evidence, while retaining the history of what was tested.
A modular monolith
A React and TypeScript workspace calls FastAPI through Nginx or the Vite
development proxy. Pydantic validates contracts; domain services own transitions;
SQLAlchemy and Alembic manage relational storage. Docker Compose defines the
PostgreSQL deployment; SQLite supports local development.
Model the relationships
A common artifact identity and seventeen joined subtype tables connect
requirements, integrations, tests, defects, changes, UAT, and releases. Foreign
keys enforce the relationships between records. Graph queries compute
traceability, impact, and release scope from stored records.
Execute the contract
The runner sends HTTP requests through a fixed in-process transport to REST/JSON
and SOAP/XML simulators. It captures request and response evidence for schema
mismatches, rejected authentication, timeouts, mapping errors, and downstream
faults.
WHEN A CONTRACT CHANGES
Each execution stores a fingerprint of its test and interface contract. Change a
mapping, and the earlier pass becomes stale. UAT approvals also depend on the
current criteria and evidence. The server rechecks release gates and rejects stale
approval when the contract changes.
Workflow integrity
Role checks, opaque cookie sessions, CSRF protection, optimistic revisions, and
explicit state transitions protect writes. Execution evidence and generated
Markdown document snapshots are immutable through the API. Updates and audit
events commit together.
Verification & outcome
Backend, migration, security, and Playwright suites cover the
requirements-to-release workflow. The recorded demonstration follows a SOAP
failure through correction, retest, UAT, and release completion. Everything runs
against a fictional local scenario; a release transition records a decision
without deploying external software. EICC has no AI approval path.
What I’m developing next
IN DEVELOPMENT
Enterprise workflow development
I’m developing the requirements, integration, and release workflows described
above. The demo shows the current implementation.
FUTURE
Scope to be defined
I haven’t selected the next feature set. External enterprise integrations and
production deployment are outside the current demo.
I’m Muhammed, a Computer Science graduate from the University of Maryland. I build
software that uses AI and machine learning, with an interest in how the data and
backend services work together.
I work on data processing, model evaluation, backend services, and interfaces. I like
tracing a result back to the input, model, or test that produced it, especially when
something fails.
