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 developing agentic acquisition from approved sources. The V2 workflow already
exercises extraction and evidence checks on owned fixtures; the external workflow
is still in progress.
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 agentic investigation workflow. The current system has typed
agent stages and executable verification; broader validation and release checks
are still underway.
A software engineering demonstration that connects requirements to interfaces, test
evidence, and release decisions. The workspace is built around the fictional
Northstar enterprise scenario.
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 to develop the enterprise workflow on this architecture. I’m
defining the next capabilities around the existing requirements and release
process.
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
The fictional Northstar modernization scenario spans intake, legacy records,
documents, notifications, identity, reporting, and a partner gateway. EICC makes the
relationships between those systems and their delivery evidence inspectable.
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 preserve actual relationships. 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 continuing to develop EICC around its existing requirements, integration,
and delivery workflows. The current implementation is the foundation for that
work; further capabilities are still being defined.
FUTURE
Scope to be defined
The repository does not commit to a specific next feature set. Future work will
be documented as its scope is settled. Real enterprise integration and
deployment remain outside the demonstrated scope.
I’m Muhammed, a Computer Science graduate from the University of Maryland. I’m
interested in software engineering and in using AI and machine learning in practical
applications.
My projects take me from data processing and model evaluation through backend services
and the interface. I like having enough context to follow a result back through the
system, especially when it fails. I’m continuing to develop these projects as I work
through their limitations.
