- Observation
- Policy, procurement, pricing, logistics, and company evidence often arrive through separate sources and at different times.
- Consequence
- The same opportunity can be judged against inconsistent facts with no clear point-in-time record.
- System response
- Source governance and an evidence ledger preserve provenance, timing, and review state before scoring begins.
Xueqi Liu
Full-stack Product Engineer
I build evidence-first software for complex decisions.
Across operations, automation, privacy, logistics, and global trade, I turn fragile workflows into systems with explicit boundaries, graceful failure, and verifiable behavior.
Current researchQuantitative decision discipline for global trade
How I move from ambiguity to evidence
Observe → Model → Decide → Execute → Verify → Learn
One decision loop connects the portfolio: every stage points to a concrete project and a bounded piece of evidence.
ObserveTradeFoundry
Gather bounded evidence before treating a pattern as an opportunity.
Nine-board modular-monolith architectureExplore the evidence intake case- 01
Observe
Gather bounded evidence before treating a pattern as an opportunity.
TradeFoundry · Nine-board modular-monolith architectureExplore the evidence intake case - 02
Model
Translate messy inputs into a versioned representation that can be inspected and replayed.
CargoMesh · Pinned DCSA contracts and deterministic Transaction IRExplore the deterministic modeling case - 03
Decide
Apply constraints, allocate attention, and preserve explicit human authority.
LeadOps Portal · Human approval as an explicit workflow boundaryExplore the approval-bound decision case - 04
Execute
Run approved work through durable, idempotent, and recoverable boundaries.
n8n Reliability Lab · Effectively-once boundaryExplore the reliable execution case - 05
Verify
Separate a completed action from independently supported business outcomes.
CargoMesh · Explicit verification statesExplore the verification-boundary case - 06
Learn
Feed successes, misses, and failures back into the next hypothesis.
TradeFoundry · Acceptance identifiers across boards S1–S9Explore the governed learning case
Current research / Private system
Bringing quantitative decision discipline to global trade.
What if global trade opportunities were researched, allocated, executed, and learned from like a governed quantitative portfolio?
The idea is not to turn trade opportunities into securities. It is to make evidence, hypotheses, allocation, limits, execution, and learning more explicit.
01 / Problem insight
Where commercial judgment loses structure
- Observation
- Commercial judgment is valuable, but its assumptions often remain implicit.
- Consequence
- A decision can look obvious after the outcome and still be impossible to challenge, replay, or improve.
- System response
- Explicit hypotheses connect a claim, supporting evidence, invalidation conditions, and a decision record.
- Observation
- A product-country-route combination competes for cash, time, operational capacity, and risk tolerance.
- Consequence
- A locally attractive opportunity can weaken the wider operating portfolio when constraints are evaluated separately.
- System response
- Allocation and risk limits compare opportunities under shared budgets and approval rules.
- Observation
- Successful deals are remembered more easily than abandoned, delayed, or loss-making paths.
- Consequence
- The next decision learns from a selective story instead of the full distribution of outcomes and failures.
- System response
- Outcome attribution keeps misses and failed paths in the learning record instead of silently discarding them.
02 / Quant-to-trade mapping
Method transfer, with boundaries
| Quantitative discipline | Global-trade application | Boundary |
|---|---|---|
| Signal | An evidence-supported candidate for further commercial research. | A signal prioritizes attention; it is not a price prediction or a promise of demand. |
| Falsifiable hypothesis | A product, country, route, or buyer thesis with evidence and explicit invalidation conditions. | A hypothesis is designed to be rejected; it is not a sales forecast. |
| Replay | A point-in-time review of what was knowable when a decision was made. | Replay checks process quality and leakage; it does not manufacture a future forecast. |
| Allocation | Distribution of research time, working capital, supplier capacity, and opportunity budget. | This is operating-resource allocation, not an investment product or securities portfolio. |
| Risk limit | Human-defined constraints for compliance, credit, cash flow, concentration, and supply-chain exposure. | Limits support review; they do not replace legal, compliance, finance, or executive judgment. |
| Governed execution | Approval-bound research, outreach, procurement, fulfilment, and settlement steps. | Consequential commercial actions remain under explicit human authority. |
| Attribution and learning | Comparison of hypotheses, decisions, actual outcomes, errors, and failure samples. | Learning improves the record; it does not imply a self-optimizing or profitable system. |
Selected systems
Different systems. One engineering discipline.
Each project demonstrates a different part of product engineering: original judgment, technical depth, end-to-end delivery, or reliability under failure.
Global-trade research often separates evidence, allocation, execution, and outcome learning.
Original product judgment across evidence, portfolio governance, and approval-bound commercial action.
- Python
- FastAPI
- PostgreSQL
- Alembic
- Architecture
The local MVP has explicit boundaries from source governance through evidence, opportunity, portfolio decisions, bilateral execution, control, settlement, and learning.
- Verification
The repository organizes deterministic fixtures and contract-level tests against explicit acceptance identifiers across all nine boards.
A completed logistics action is not necessarily a verified business outcome.
Contract-first modeling, deterministic IR, durable execution, and independent verification states.
- Python
- Temporal
- DCSA contracts
- Playwright
Lead operations become fragile when tenancy, approval, automation, incidents, and reporting disagree.
End-to-end product ownership with explicit tenant and human-decision boundaries.
- TypeScript
- Next.js
- Node.js
- PostgreSQL
A webhook is easy on the happy path; duplicates, retries, dead letters, and recovery expose the real system.
Effectively-once delivery, persisted attempts, bounded retry, and operator-controlled replay.
- n8n
- JavaScript
- PostgreSQL
- Docker
How I make decisions
Principles are useful only when a decision proves them.
Each principle is bound to a concrete situation, choice, trade-off, and inspectable piece of project evidence.
Evidence before claims
Important behavior should be supported by tests, records, or observable outcomes, with the scope of that evidence made explicit.
- Situation
- A logistics adapter can report success while the intended business outcome remains unproven.
- Decision
- Separate execution from VERIFIED, NEEDS_REVIEW, and HALTED evidence states.
- Trade-off
- More states and evidence collection create operational work, but prevent completion from becoming an unsupported claim.
Explicit boundaries
Automation should not silently bypass policy, tenancy, consent, or consequential human decisions.
- Situation
- Workflow automation could otherwise continue past a consequential human decision.
- Decision
- Model approval records and tokens as an explicit callback boundary.
- Trade-off
- The gate adds latency and state, but preserves accountable authority.
Graceful failure
A failure should become a visible, diagnosable, and recoverable state rather than an unexplained disappearance.
- Situation
- Retries, duplicates, and exhausted delivery can disappear between workflow executions.
- Decision
- Persist attempts, bound retry, open dead letters, and require an operator-owned replay.
- Trade-off
- Reliability adds database and operational complexity, but makes failure diagnosable and recoverable.
Reversible decisions
Under uncertainty, systems should preserve review, rollback, replay, and learning paths before increasing autonomy.
- Situation
- An uncertain commercial opportunity competes for limited cash, time, capacity, and risk budget.
- Decision
- Version allocation decisions, preserve replay, and keep consequential execution approval-bound.
- Trade-off
- The system moves more slowly than autonomous ranking, but a decision can be reviewed, changed, and learned from.
Evidence snapshot
Evidence says what it verifies.
The portfolio uses tests, architecture records, and demonstration boundaries as scoped evidence rather than cumulative vanity metrics.
Shows how responsibilities and control boundaries are shaped.
Pinned DCSA contracts and deterministic Transaction IR
CargoMesh compiles pinned logistics contracts into versioned, digest-backed business transaction representations.
Reference implementation using the documented accepted transaction demonstrations.Read case study: cargomeshShows which behaviors were exercised and where that proof stops.
Layered local verification
The repository documents local verification for the product, persistence, workflow, and operational boundaries.
Local verification; not evidence of live production traffic.Read case study: leadopsShows how licensing, access, and safety boundaries are made explicit.
Explicit source terms and open-source inventory
The repository separates portfolio source terms from third-party package licenses.
Repository-level licensing disclosure.Read case study: leadopsShows a real demonstration surface without turning it into production proof.
Evidence from a running local n8n instance
Workflow close-ups are captured from the running local instance rather than recreated as an unverified diagram.
Local demonstration only.Coverage
Read case study: n8n-reliability-lab500 → 429 → 201 with a final delivered state
LimitationThe public recording, captions, and metadata review are not complete
Shows the limitations that keep a public claim honest.
External integration boundary
The repository explicitly distinguishes synthetic adapters and local control boundaries from real carrier, identity, payment, and cloud integrations.
Public repository disclosure.Read case study: cargomeshThinking
Making engineering judgment inspectable.
Essays on the decisions, trade-offs, and honest boundaries behind the projects.
What quantitative thinking contributes to global trade
A decision-system view of evidence, ranking, uncertainty, and governed execution in trade research.
Read the essayVerification is a product feature
Why execution, observation, and verified outcomes should be separate states in reliable products.
Read the essayPrivacy belongs in the system contract
Consent, data minimization, and redaction become dependable only when every boundary enforces them.
Read the essayWorking perspective
Product thinking grounded in operational reality.
My work connects software design with workflows, human decisions, logistics, and cross-border operations. That is why the portfolio focuses on boundaries, exceptions, and verification as much as features.
Read how I workStart a conversation
A role, a system problem, or a focused collaboration.
For a role, a focused systems problem, or a commercial conversation, use the verified domain email or review the public GitHub work first.
View contact options