Application reasoning architecture
Implemented decision-tree and evaluator patterns made some reasoning executable, but evidence and authority remained distributed.
implementedFlagship case study
WTA Decision Intelligence
documented
How I translated complex market reasoning into explicit evidence states, clear authority boundaries and a testable implementation path.
Product architecture definedFoundation implementedHistorical-first scopeHuman-governedIn development
From discretionary reasoning to governed decision intelligence.
WTA began with a difficult product question: how could nuanced human market judgement become explicit enough to inspect, challenge and test without handing methodology or capital authority to an AI model?
I led two linked workstreams: structuring historical decisions and their evidence, including rejected decisions; and defining a delivery architecture with deterministic components, bounded AI roles, validation and human approval gates. The product is not an AI that trades. It is a governed decision system where AI supports defined work inside clear human authority.
Starting condition
- Reasoning remained partly tacit and difficult to audit
- Decision evidence was distributed across changing artifacts
- Authority boundaries depended on human interpretation
- Negative decisions were easier to lose than executed actions
Product direction
- Functions, states and dependencies become explicit
- Evidence and provenance attach to governed objects
- AI roles operate inside named permissions and prohibitions
- TRADE and NO TRADE decisions remain available for research
I evolved the architecture by making ownership, evidence and delivery boundaries explicit.
Functional Reasoning and governance
Reasoning shifted toward named functions, states and dependencies, connected to explicit governance controls.
approvedLayered decision-intelligence architecture
A five-layer candidate and controlled-autonomy structure were specified for review; they are not presented as a finished runtime.
proposed01IntentHuman methodology
02FunctionsStates & dependencies
03EvidenceTraceable decisions
04ReviewValidation & conflict
05AuthorityHuman approval gate
The product had to align product ownership, implementation and assurance.
Decision owner
Methodology owner
Sets intent, resolves ambiguity and retains final authority over methodology and any future capital decision.
Delivery team
Product and implementation workflow
Needs approved requirements, typed inputs and outputs, acceptance conditions and a safe path to integration.
Assurance
Reviewer
Needs clear evidence to distinguish documented, approved, implemented, proposed, superseded and unresolved work.
Research
Future analyst
Needs both positive and negative decision populations so that future claims can be tested rather than reconstructed retrospectively.
The central failure mode was ambiguity crossing layers: a concept could be described, treated as approved, implemented unevenly and then discussed as though it were complete. The product response was to make state, source and authority visible.
I owned the translation between intent and executable work.
Product strategy
Defined the product problem, stakeholders, delivery boundary and appropriate first slice.
Roadmap and risk
Sequenced evidence, governance and implementation work around risk and dependency.
Requirements
Converted human intent into explicit states, dependencies, contracts and acceptance criteria.
Decision governance
Kept methodology approval and future capital authority behind human gates.
Delivery assurance
Separated source-backed implementation evidence from proposed architecture.
Iteration
Preserved unresolved questions and supersession records to inform the next decision.
How I applied this
I treated “done” as an evidence question. A capability could not move from proposed to implemented because it appeared in a plan; it needed a matching artifact or repository state. That distinction is now visible in the registry and the case-study metrics.
Useful automation could not come at the cost of unbounded authority.
Methodology integrity
An implementation agent must not invent, rewrite or approve trading methodology.
Source conflict
Contradictory artifacts must be surfaced to a human, not silently reconciled by a model.
Capital risk
Research output must not create a direct path to live-capital execution.
False maturity
Architecture documentation, a specification and a production runtime are different evidence states.
Research bias
Capturing only executed trades would remove the rejected population needed for falsifiable analysis.
How I applied this
I chose a historical-only first vertical slice. It creates space to test schemas, routing and evidence handling without live market execution or capital authority.
I turned scattered project material into a reviewable product map.
I reviewed architecture, governance, reviewer, autonomy and supersession material, then normalised it into a 47-object Phase 3 knowledge index.
Source artifactsArchitecture · governance · review · lineage
→Object registryID · category · source · state
→Product decisionsAdopt · defer · supersede · resolve
Crucially, unresolved questions were preserved as first-class objects. That stopped missing answers from being converted into confident implementation assumptions.
How I applied this
The public model below is deliberately sanitised. It presents reviewed IDs, names, states and plain-language explanations while excluding proprietary trading rules, internal definitions, private paths and operational data.
I used the risk model to rule out attractive but unsafe shortcuts.
Rejected
One giant autonomous agent
Fast to describe, hard to audit. It would combine reasoning, implementation, review and authority inside one probabilistic boundary.
Rejected
Research-to-Capital connection
It collapsed discovery and financial authority into a direct edge before the evidence and governance layers were mature.
Deferred
All layers at once
A broad build would increase integration surface before the smallest end-to-end evidence path had been tested.
Rejected
Silent conflict resolution
Choosing the newest or most confident source automatically would hide product decisions that require owner judgement.
Governance came before higher autonomy.
Decision and trade-off
Use a historical-only first vertical slice
- Decision
- Prove one evidence path with historical data, deterministic routing and a human approval boundary.
- Why
- It tests integration while containing financial and methodological risk.
- Trade-off
- Less immediate automation and no live-capital value claim.
Decision and trade-off
Retain negative decisions
- Decision
- Capture both TRADE and NO TRADE classes, including failed gates.
- Why
- Later research needs rejected cases and counterfactuals, not only executed actions.
- Trade-off
- A larger schema and greater evidence-discipline cost.
Decision and trade-off
Make unresolved state explicit
- Decision
- Record unanswered authority, reviewer and autonomy questions in the same index.
- Why
- Unknowns should remain visible backlog, not hidden implementation assumptions.
- Trade-off
- The architecture appears less complete, but it is more trustworthy.
Decision and trade-off
Separate specification from approval
- Decision
- Allow AI to draft and review bounded specifications while a human approves methodology.
- Why
- This captures speed without confusing contribution with authority.
- Trade-off
- More handoffs and deliberate gates in the workflow.
I converted expert intent into requirements that engineering can test.
1
Human intentDescribe purpose, boundary and exception.
2
Governed specificationName inputs, outputs, states, dependencies and failure conditions.
3
Acceptance contractDefine deterministic checks, test fixtures and prohibited behaviour.
4
Bounded implementationChange only approved scope; preserve repository evidence.
5
Review and approvalCompare result to intent and escalate conflicts to the human authority.
How I applied this
The implemented Project Zen boundary distinguishes a reasoning/specification role from a bounded implementation role. Neither role may self-approve methodology, and repository state supplies the evidence for what actually exists.
I designed a four-part operating model with clear ownership at every hand-off.
The delivery foundation is implemented; future autonomy remains gated.
AreaEvidencePublic state
Phase 3 knowledge index47 tracked architecture/evidence objectsimplemented
Repository governance lifecycleApproved and implemented objectimplemented
Reasoning/specification and implementation rolesBoundaries represented in the registryimplemented
Graph Platform v0.1 vertical sliceHistorical-only implementation planproposed
Discovery Engine layers0 of 3 layers implementedproposed
Reviewer runtimes0 of 2 runtimes implementedunresolved
The metrics show where delivery evidence exists across the architecture.
These figures show how the tracked architecture has been documented, approved and implemented.
47documented
tracked architecture/evidence objects
15 / 47approved
approved objects · 31.9% coverage
10 / 47implemented
implemented objects · 21.3% coverage
15 / 47proposed
proposed objects · 31.9% coverage
6 / 47unresolved
explicitly unresolved objects · 12.8% coverage
4 / 47superseded
supersession records · 8.5% coverage
4implemented
explicit human/AI workflow roles
12documented
controlled-autonomy roadmap stages
0 / 3proposed
Discovery Engine layers implemented
0 / 2unresolved
Reviewer runtimes implemented
Reviewed public evidence sample
This table presents a reviewed, recruiter-friendly view of the architecture and its current state.
P3-CONCEPT-001Concept
Functional Reasoning
Frames approved market functions as explicit states, dependencies and failure conditions.
DocumentedApprovedHigh confidence
P3-CONCEPT-004Concept
Structured Evidence
Creates a traceable evidence layer for positive and negative decisions.
DocumentedImplementedHigh confidence, scope varies
P3-DECISION-002Decision
Repository governance lifecycle
Requires controlled versioning, review and integration around architecture changes.
ApprovedImplemented
P3-DECISION-003Decision
Project Zen authority boundary
Separates reasoning and implementation support from human approval authority.
ApprovedImplemented
P3-DECISION-004Decision
Staged autonomy policy
Treats autonomy as a gated roadmap, not a single launch state.
Approved
P3-AGENT-001Agent role
Reasoning and specification role
Supports bounded specification and review while requiring human approval.
ImplementedImplemented
P3-AGENT-002Agent role
Bounded implementation role
Implements approved logic and tests inside a defined repository scope.
ImplementedImplemented
P3-GOV-002Governance rule
No silent source conflict resolution
Escalates conflicting evidence rather than allowing an automated assumption.
ApprovedImplemented
P3-GOV-003Governance rule
No autonomous methodology rewrite
Keeps methodology changes behind explicit human authority.
DocumentedApproved
P3-ARCH-002Architecture
Functional Reasoning and governance architecture
Connects reasoning states to governance and implementation boundaries.
DocumentedApprovedCommittedImplemented with component variation
P3-UNRESOLVED-003Unresolved question
Reviewer authority and escalation contracts
Final reviewer permissions, scoring and escalation contracts still require resolution.
Unresolved
P3-UNRESOLVED-004Unresolved question
Evidence for future autonomy gates
Each later autonomy gate still needs an explicit evidence threshold.
Unresolved
The remaining decisions are visible, owned and not presented as delivery.
Loop Engineering scope
The exact canonical definition and boundary still require owner resolution.
Reasoning relationship
The formal relationship between Market Reasoning and Functional Reasoning remains open.
Reviewer contracts
Final authority, packet schema, scoring and escalation contracts need ratification.
Autonomy evidence
Each future autonomy gate needs a defined evidence threshold before it can open.
A historical-only vertical slice comes next.
The next implementation milestone is not broader autonomy. It is one end-to-end path that proves the evidence, routing, validation and human-review contracts work together.
The most valuable product outcome was a clearer decision boundary.
My early instinct was to treat architecture as the main deliverable. The audit showed that architecture without evidence state and authority lineage can create confidence faster than truth.
The stronger product approach was to separate four questions: What is the intent? What evidence supports it? Who can approve it? What has actually been implemented? That separation made the roadmap slower in appearance but safer and more executable in practice.
My next improvement is to make exit criteria as concrete as entry criteria. Every future autonomy stage should name the evidence that opens it, the evidence that closes it and the human role accountable for the decision.
Decision intelligence is not more automation. It is clearer reasoning, evidence and authority made inspectable before automation expands.
Next step
Build the next decision boundary carefully.
I’m open to Junior Product Owner roles where complex reasoning, evidence and AI-enabled delivery need clear human governance.