5
Foundation phases delivered
Phases 0–4 established contracts, data, state, paper intent, and audit foundations.
Autonomous Trading Systems Lab · public-safe case study
Building autonomy without surrendering judgment.
I turned an ambiguous, high-consequence systems idea into a governed AI-assisted engineering program: bounded requirements, deterministic authority, observable evidence, independent review, and a human decision gate before consequential action.
Authority mapPublic abstraction
AIExplain and proposenever authorizes
no model crosses this line
01 · Executive scan
The signal in sixty seconds.
This is not a story about asking a model to build a trading bot. It is a case study in implementation leadership: turning uncertainty into a system that knows its boundaries, exposes its evidence, and stops when proof is missing.
0
Model authority over risk
Language models may explain or propose. Deterministic code and human approval retain authority.
6
Proof states kept separate
Documented, implemented, tests green, CI green, operator verified, and complete are not synonyms.
4
Failures converted to controls
Real defects strengthened validators, regression tests, evidence rules, and review gates.
What the work demonstrates
- Requirements and architecture under real ambiguity
- AI-agent coordination with bounded roles and traceable handoffs
- Expected-versus-actual validation and evidence review
- Risk-aware release discipline and human accountability
What it does not claim
- A profitable strategy or positive trading expectancy
- Live brokerage execution or production runtime readiness
- AI making trade, risk, or promotion decisions
- A finished system: Phase 5 remains deliberately unmerged
02 · The business problem
Make a moving system legible, then make it governable.
The domain is market research. The transferable challenge is broader: many AI implementations fail because the data, decision rights, and definition of proof remain vague.
In plain English: before asking AI to reason, I made sure the system could tell what happened, where the facts came from, what it was allowed to do, and who could approve the next step.
01
The first product helped a human orient
A decision-support “Coach” combined structured market facts with on-demand model explanation. It proved the usefulness of deterministic facts first—and exposed the ceiling created by weak provenance and freshness.
02
The lab separated research from authority
The autonomous lab became a distinct system with a harder rule: models can contribute intelligence, but irreversible decisions remain outside the model layer.
03
The roadmap became a sequence of gates
Instead of building a monolith, the work moved through data contracts, deterministic state, auditability, risk rules, strategy, planning, simulation, evaluation, and readiness review.
04
Every failure had to improve the institution
A defect was not closed with a patch alone. It produced a regression test, stronger acceptance criteria, a clearer owner, or a safer stop condition.
03 · Architecture
A deterministic spine. Models beside it.
The architecture is intentionally asymmetrical. Code owns facts, state, risk, audit, and future execution planning. Models operate in a shadow research plane where they can classify, explain, challenge, and propose without gaining runtime authority.
Deterministic codeAI research planeHuman promotion gate
Runtime authority · fail-closed
Market evidencesingle source · provenance · freshness
Canonical statemarket state · auction state · fixed contracts
Paper intent and auditappend-only history · identity · durable recovery
Risk kernelPhase 5 · draft branch · no ALLOW
Strategy, planning, simulationPhases 6–9 · not started
Human live-readiness reviewPhase 10 · required before any consequential release
Shadow intelligence · no authority
Research modelsgenerate hypotheses and alternatives
Independent review agentchecks live evidence, not builder claims
Documentation agentpreserves decisions and institutional memory
A model can disagree with the deterministic system. It cannot override it. Any useful proposal must survive a contract, evidence, review, and human promotion path.
04 · Implementation method
The work moves in inspectable slices.
The core capability is not code generation. It is the operating layer around AI: deciding what matters, translating it into contracts, routing the right work, judging the evidence, and protecting the final decision.
01Frame
Clarify the user, objective, constraints, and consequence.
02Contract
Define behavior, boundaries, owner, and acceptance evidence.
03Build
Implement the smallest useful, reviewable slice.
04Observe
Compare expected and actual behavior with durable evidence.
05Challenge
Use independent review against the exact commit.
06Correct
Turn gaps into tests, stronger judges, or explicit stops.
07Promote
A human decides whether the evidence earns the next state.
| Role | What it owns | What it cannot do |
|---|---|---|
| Chien / operator | Problem framing, product direction, architecture, model routing, acceptance criteria, privacy, review, and final promotion. | Cannot treat persuasive model output as evidence. |
| Builder agent | Scoped implementation, tests, documentation, and exact-commit handoff. | Cannot self-approve consequential work. |
| Review agent | Independent inspection of code, CI, acceptance criteria, and unresolved threads. | Cannot rely on the builder’s summary as proof. |
| Deterministic system | Facts, state transitions, risk rules, audit records, and fail-closed behavior. | Cannot infer success when evidence is missing. |
05 · Failure as evidence
The strongest proof is what changed after something went wrong.
A polished case study should not hide the seams. These incidents show the system learning: each one sharpened a test, validator, contract, or review rule.
An API value meant something different than assumed.
The integration compiled, but the external date value was interpreted with the wrong semantics. The system rejected all telemetry rather than accepting corrupt input.
- Changed
- 72-assertion regression coverage and a rule to verify external semantics against docs, fixtures, and live probes.
- Signal
- Availability is not understanding.
A capture policy accepted a weak proxy.
Samples appeared to advance while the replay clock had not moved. The validator caught the mismatch and exposed a loose evidence-capture rule.
- Changed
- Strictly later chart time became required before a sample could satisfy the gate.
- Signal
- A passing check must prove the exact claim.
The evidence judge needed its own adversarial tests.
Existence checks and timing assumptions could certify artifacts that did not actually establish the promised behavior.
- Changed
- Assertions became bound to precise artifacts, chronology, hashes, and a paused-first invariant.
- Signal
- Test the tester.
“Executed” was mistaken for “passed.”
A validation command could run, exit non-zero, and still appear complete. Independent review blocked the work before promotion.
- Changed
- Completion now requires the result—not merely the presence—of validation evidence.
- Signal
- Review is part of the product.
06 · Current truth
Progress is reported without collapsing the boundaries.
This public view was reconciled against the private project’s current status, GitHub issue state, draft pull request, and CI on October 4, 2026. It describes engineering progress—not operational readiness.
As of 2026-10-04 · America/Los_Angeles
Phase 5
In progress and deliberately unmerged. The protected `main` branch still holds a fail-closed RiskKernel stub. The draft branch contains independently accepted slices and active corrections, but it is not merge-ready.
Hard boundary: no `ALLOW`, no live brokerage execution, no profitability claim, and no work represented as complete beyond its evidence state.
Phase 0
Build law and canonical contractsScope, architecture, governance, definition of done
CompletePhase 1–2
Source data and evidence packetsTelemetry, validation, canonical normalization
CompletePhase 3
Deterministic market and auction stateReplay evidence and bounded v1 classifiers
CompletePhase 4
Paper intent and append-only auditIdentity, idempotency, durable recovery
CompletePhase 5
Deterministic risk kernelDraft branch, reviewed micro-slices, corrections still active
In progressPhase 6–10
Strategy through live-readiness reviewLocked behind Phase 5 progression
Not started07 · Employer relevance
What this says about how I implement AI.
The trading domain makes risk visible, but the operating capabilities transfer directly to AI implementation, technical solutions, onboarding, product operations, and customer-facing systems work.
01
Discovery and scoping
I turn a broad goal into users, constraints, risks, decision rights, and a concrete definition of success.
02
Requirements translation
I convert ambiguity into contracts, acceptance criteria, dependency order, and explicit exclusions.
03
Architecture and integration
I design around data quality, authority boundaries, observability, failure modes, and ownership.
04
AI-tool orchestration
I route research, building, review, and documentation to specialized tools while retaining accountability.
05
Validation and diagnosis
I compare expected and actual behavior using tests, logs, fixtures, CI, visual evidence, and human checks.
06
Enablement and handoff
I make status, limitations, next actions, and ownership legible to technical and nontechnical stakeholders.
08 · Evidence paths
Read at the depth you need.
The public repository is intentionally layered: a recruiter can scan the result, an executive can understand the decisions, and a technical reviewer can inspect the method and its limitations.
This visual case study
Problem, ownership, architecture, proof boundaries, and role fit.
Return to the executive scanFull case study
The deeper written account, including evolution, failures, status, technology, and selected evidence.
Read the full case studyImplementation walkthrough
The requirements, integration, evidence, human-gate, and learning loop in a reusable public-safe form.
Inspect the walkthroughValidation gates
How the system handles scope, identity, dependencies, evidence, privacy, consequence, and release.
Review the gatesAttribution and limits
What AI tools contributed, what Chien owned, and which conclusions the work does not support.
Read the attributionPublic repository
Versioned public copy, maintenance notes, and the inspectable source for this page.
Open the repositoryThe takeaway
AI can accelerate the work. Accountability still needs an owner.
This project represents how I approach implementation roles: learn the workflow, make the boundaries explicit, connect the right tools, validate what actually happened, communicate in plain English, and remain responsible for the result.