ORIGIN — Give Software the Ability to Understand Itself
What if software could investigate its own failures using the scientific method?
Modern software systems are increasingly distributed, interconnected, and difficult to understand. When one service begins failing, its effects can cascade across an entire application. Engineers receive alerts, inspect dashboards, follow traces, and often spend hours distinguishing the real cause from its symptoms.
Traditional observability tells us what happened. We wanted to build something that could investigate why it happened, what might happen next, and which intervention could safely improve it.
That's why we built ORIGIN — Autonomous Scientific Intelligence for Software Systems.
ORIGIN combines distributed observability, autonomous causal investigation, controlled experimentation, digital-twin simulation, and human-approved recovery into a unified scientific engineering platform.
Inspiration
The inspiration came from a fundamental limitation in modern DevOps and Site Reliability Engineering: collecting more telemetry doesn't automatically produce understanding.
Imagine a checkout application experiencing severe latency. The database appears busy, payment processing slows down, queues begin filling, and multiple services report degraded health.
Which service is actually responsible?
Simply identifying the slowest component is not enough. Correlation is not causation. Scaling the wrong service can even make the problem worse.
We asked ourselves:
What if a software system could formulate hypotheses, run controlled experiments, reject incorrect explanations, simulate alternative futures, and verify a recovery strategy before applying it?
ORIGIN is our attempt to make that possible.
What ORIGIN Does
ORIGIN is built around five connected capabilities.
1. Living System Intelligence
ORIGIN ingests OpenTelemetry traces and metrics, stores observations in PostgreSQL, and reconstructs the relationships between services.
Its interactive topology explorer visualizes service dependencies, latency, health, resource saturation, and failure propagation.
Rather than relying entirely on manually drawn architecture diagrams, it distinguishes registered dependencies from those established through observed distributed traces.
2. Autonomous Causal Scientist
When a system degrades, ORIGIN can launch an autonomous scientific investigation.
It:
- Analyzes telemetry and service relationships.
- Generates competing, falsifiable hypotheses.
- Selects controlled experiments.
- Runs allowlisted interventions inside an isolated laboratory.
- Collects treatment and control measurements.
- Calculates statistical comparisons using Welch's t-test and Cohen's d.
- Records supporting and contradicting evidence.
- Concludes with a supported explanation or reports INCONCLUSIVE when evidence is insufficient.
The core investigation process is deterministic and evidence-driven. It does not require a paid AI model to generate plausible-sounding diagnoses.
3. Living Digital Twin & Counterfactual Intelligence
Once ORIGIN investigates a failure, engineers can explore possible interventions using an executable digital twin.
The simulation models request arrivals, processing capacity, queue growth, resource saturation, downstream latency, shared database contention, and circuit-breaker behavior.
ORIGIN calibrates its model using recorded telemetry and evaluates predictions against held-out observations.
Users can capture a simulation snapshot, rewind time, create alternate branches, and compare outcomes.
For example:
What happens if we add more checkout replicas? What if we limit traffic instead? What if we isolate the slow payment dependency?
The system produces simulation trajectories and uncertainty estimates while clearly separating predictions from measured experimental results.
4. Verified Autonomous Recovery
ORIGIN connects investigation evidence and digital-twin predictions to controlled recovery workflows.
A recovery plan passes through:
- Evidence-based remediation planning.
- Safety-policy evaluation.
- Counterfactual simulation.
- Isolated sandbox verification.
- Human approval.
- Controlled execution.
- Post-execution observation.
- Automatic rollback when recovery criteria fail.
The implemented recovery environment is restricted to the synthetic laboratory. ORIGIN does not autonomously modify arbitrary production infrastructure.
This safety boundary is deliberate: autonomous operations should be verifiable and accountable.
5. Scientific Evidence & Reproducibility
Every investigation should leave behind more than a final answer.
ORIGIN persists hypotheses, experimental measurements, model calibration records, simulation branches, recovery decisions, and audit history.
Users can inspect the evidence and export scientific reports in Markdown or JSON.
The goal is to make operational decisions reproducible, explainable, and open to review.
How We Built It
ORIGIN uses a modular full-stack architecture.
Backend: Python 3.12, FastAPI, Pydantic, SQLAlchemy async, and Alembic.
Frontend: Next.js 15, React 19, TypeScript, Tailwind CSS, React Flow, and Recharts.
Infrastructure: PostgreSQL 16, Redis 7, Docker Compose, Nginx, and GitHub Actions.
Observability: OpenTelemetry, distributed tracing, telemetry ingestion, and Server-Sent Events.
Scientific computation: Controlled experiments, randomized treatment/control trials, statistical inference, discrete-event simulation, deterministic replay, and Monte Carlo uncertainty estimation.
Testing: Pytest, Vitest, Playwright, Ruff, and Mypy.
We also created a five-service synthetic distributed application containing an API gateway, checkout service, inventory service, payment simulator, and order database simulator.
This laboratory generates real service interactions and allows reproducible fault injection without affecting production systems.
Challenges We Faced
Distinguishing correlation from causation
A slow service is not necessarily the root cause of an incident.
We designed the investigator to compare competing hypotheses through controlled interventions rather than relying on telemetry correlations alone.
Preventing the investigator from seeing hidden answers
Our synthetic laboratory knows which fault was injected, but the investigator must not.
We separated benchmark-controller permissions from investigator access and tested that hidden fault information does not appear in authorized telemetry observations.
Building reproducible counterfactual simulations
Simulation results must be repeatable to support meaningful comparisons.
We implemented deterministic snapshots that preserve simulation state, pending events, and random generator state, allowing different interventions to be evaluated from the same starting point.
Making autonomous recovery safe
A system that can diagnose failures should not automatically gain unrestricted control over infrastructure.
We implemented allowlisted actions, bounded policies, human approval, sandbox verification, execution controls, and rollback behavior.
Connecting multiple complex systems
The most challenging engineering task was connecting observability, experimentation, simulation, recovery, persistence, and the user interface into one coherent workflow.
Each component had to consume real outputs from the previous stage rather than display unrelated demonstration data.
Accomplishments We're Proud Of
The final engineering report records:
- 30 passing backend tests covering causal investigation, simulation, recovery, and scientific integrity.
- 4 passing frontend unit tests.
- 8 passing release verification gates.
- 15 documented product claims mapped to implementation and verification evidence.
- A browser-tested guided scientific demonstration.
- A five-service instrumented laboratory.
- Reproducible simulation snapshots and counterfactual branches.
- Human-approved recovery with rollback safeguards.
The benchmark suite also reported correct root-cause identification across its defined failure scenarios and an inconclusive result for ambiguous noise.
These results describe the tested synthetic environment; they are not a claim of universal diagnostic accuracy.
What We Learned
Building ORIGIN taught us that reliable software intelligence requires more than an AI model.
We explored how distributed tracing, causal reasoning, controlled experimentation, statistical inference, discrete-event simulation, and operational safety can work together.
We also learned the importance of distinguishing three types of information:
Observation: What the system actually did.
Experiment: What changed when we deliberately intervened.
Prediction: What a calibrated model estimates might happen.
Keeping these separate is essential for trustworthy autonomous engineering.
What's Next
ORIGIN is only the beginning.
Future development will focus on broader unseen-fault benchmarks, Kubernetes and cloud integrations, improved causal identification, online model calibration, richer simulation models, and safe integration with real operational environments.
Our long-term vision is to make software systems more understandable, resilient, and scientifically manageable.
Final Thought
Monitoring tells us something is wrong. Scientific investigation helps us understand why. Verified recovery helps us act responsibly.
ORIGIN brings these capabilities together.
Give software the ability to understand itself.
Built With
- alembic
- causal-inference
- discrete-event
- docker
- fastapi
- github-actions
- next.js
- nginx
- opentelemetry
- playwright
- postgresql
- pytest
- python
- react
- react-flow
- recharts
- redis
- sqlalchemy
- tailwind-css
- typescript
Log in or sign up for Devpost to join the conversation.