Andrew Xia

Applied AI and systems design.

I build document-review software, verification tools for AI-assisted development, and an ecosystem simulation game. I define the requirements, design the systems and review the results, using AI to help implement them.

McGill · Computer Science / UNSW · AI & Database Systems ↗

Explore the work ↓ Inside a document review

AI extracts the values. A quantity rule flags the conflict for REVIEW. A person decides what needs correcting.

Curated example with invented documents. Two quantities disagree; the illustrated workflow flags them for a person to review.

Selected projects

Explore what each project does, why I designed it that way, and what the recorded tests show.

01 / VERDICT · Document AI · prototype

AI-assisted document review, with traceable findings.

Independent prototype · in development

01Problem: Important shipment details are split across several documents. A reviewer has to catch when those documents disagree.
02What I built: I designed the review workflow and its decision boundary: models extract, written rules flag conflicts, and a person can trace each finding to the documents and values behind it.
03Proof: Synthetic cases illustrate cross-document checks, source-linked findings and follow-up drafts. A separate June 2026 evaluation compared extracted values with labelled reference values on clean English text reconstructed from 85 synthetic documents.

57documented checks across compliance review and shipment pre-check

85synthetic document texts evaluated

96.3%field agreement · synthetic English text · June 2026Matching allows normalisation and numeric tolerance.

Explore a synthetic case ↓Read the case study →

Verdict — explore a shipment review

Explore four fictional shipment cases. Open a finding to compare its source fields, or replay the steps from documents to a follow-up draft. The examples show how model extraction, written checks and human review fit together.

SYNTHETIC CASES · illustrated prototype workflow

Illustrated replay: no model requests or document uploads.

Static snapshot: the recorded Case B results and first source trace are shown below. Switching cases, inspecting other sources, opening drafts and copying content require JavaScript.

The invoice and packing list disagree999-55667788 · PVG → SYD · 40 pcs · 612.5 kg · Ceramic tableware · CIF

Receive documents
Classify
Extract fields
Apply rules
Assign status
Draft follow-up

Processing trace (technical detail)

Rule scores in the trace are illustrative values, not risk probabilities. Snapshot references do not prove that the edited explanations are verbatim engine output.

Invoice vs packing list disagree

2 discrepancies need human confirmation; 1 synthetic configuration check is recorded.

01▸ {"upload":{"received":3,"expected":3}}
02▸ {"classify":{"air_waybill":{"method":"heuristic","conf":0.96},"commercial_invoice":{"method":"heuristic","conf":0.95},"packing_list":{"method":"heuristic","conf":0.93}}}
03▸ {"extract":{"fields":10,"low_confidence":0}}
04▸ {"validate":{"rules_fired":3,"warning":2,"info":1}}
05▸ {"example_result":{"status":"REVIEW","illustrative_rule_score":54}}
06▸ {"draft":{"subject":"Synthetic AWB 999-55667788 — two discrepancies to confirm"}}

Findings & source evidence

Synthetic fixture: compare document fields
Original English explanation and references
Quantity mismatch: invoice declares 40 cartons / 4,800 pcs; packing list shows 38 cartons / 4,560 pcs.
Synthetic fixture: compare document fields
- commercial_invoice · cartons: 40 cartons · 4,800 pcs
- packing_list · cartons: 38 cartons · 4,560 pcs
rule BG-XDOC-007 · example rule catalogue c6f89cf4…

Case route

Keyword matching runs first; the LLM handles low-confidence classifications.

Confidence values are part of the example, not probabilities of correctness.

Confidence (0–1)

Separate extraction evaluation · June 2026 · deepseek-v4-flash · temperature 0 · prompt precheck-extract-v3.0 · one recorded run over 85 document texts

View the extraction evaluation

Recorded extraction evaluation · 2026-06

Evaluated June 2026 · corpus v1

Corpus	85 synthetic document-text fixtures · 511 labelled fields · 17 document sets
Field agreement (normalisation + numeric tolerance)	96.3%
Lenient agreement (also allows substring containment)	99.0%
Document-level extraction errors	0 of 85 documents
Missing field values	2 of 511 fields
Method	Field-by-field comparison with string, date and identifier normalisation and numeric tolerances; lenient matching also permits substring containment. Mismatches are printed for review.
Run conditions	deepseek-v4-flash · temperature 0 · prompt precheck-extract-v3.0 · 1 run

Numbers cover clean English text reconstructed from hand-authored ground truth for synthetic documents. PDF parsing, OCR, scans, photos, other layouts and real customer paperwork were not evaluated.

Evaluation scope & project status

Independent prototype, in development. The public examples and published evaluation use synthetic fixtures. The recorded evaluation covers clean English text reconstructed from hand-authored ground truth, not PDF parsing, OCR, scans, photos, other layouts or real operational documents. System checks support review; they do not authorise shipment or replace professional judgment. The rule implementation is not professional or regulatory validation. No production-traffic performance is claimed.

How these examples were made

These examples use invented document values. Rule IDs, thresholds and follow-up drafts have been simplified for presentation, so the examples are not unedited operational reports. The rule-catalogue hash identifies the public example catalogue; it does not establish that a finding is correct.

Synthetic example record: 2026-06-12 · public rule catalogue c6f89cf4…

Independent project · AI coding verification

nonconstantRepository checks for AI-assisted development.

I built nonconstant as a Shell toolkit for checking AI-assisted changes in a Git repository. Its checks detect edits to protected criteria, scan for four known failure-suppression patterns, and compare status assertions in supported formats with repository facts. Each check returns pass, fail or cannot judge.

A three-state gate contract

Each Shell gate returns 0 (pass), 1 (fail) or 2 (cannot judge), keeping missing prerequisites distinct from a successful check.

Criteria protection and gate registration

Protected criteria are checked for edits. Each enabled gate must register a passing and a failing example.

A configurable verification layer

Project configuration controls installation and paths. Report names are checked for a commit reference in Git history, and an optional Spec Kit workflow runs the gates.

One claim. Three verification outcomes.

Choose a preset to see why “cannot judge” is not the same as “pass”.

Interactive explanation · illustrative presets. This browser does not run shell gates, inspect your repository, or call an AI agent.

Illustrated evidence

Completion claim

“I checked it. The work passed.”

Conditions: Target, configuration and baseline are available.
Criteria: Protected criteria are unchanged.
Checks: The illustrated checks passed.

PASSexit 0

The illustrated evidence supports the declared check. It does not prove the whole task is correct.
Selected
FAILexit 1

The protected criteria changed. A confident completion claim cannot turn that evidence into a pass.
Selected
CANNOT JUDGEexit 2

The check lacks required conditions. No observed error is not evidence of success.
Selected

Selected result: Evidence complete → PASS · exit 0

Explore nonconstant source

Scope, origins and integration

An installable Shell / AWK / YAML toolkit, not a hosted agent platform or a complete orchestrator. Ten gates are registered; eight are distributable. Each installed project still needs its own configuration and checks. Known limitations are documented in the source.

DevLoop v1 was my earlier Python agent orchestrator: task dispatch, isolated worktrees and run records. Its incidents informed this separate verification project; nonconstant imports none of its code.

GitHub Spec Kit is an optional, pinned upstream workflow engine. nonconstant supplies the checks and does not fork or modify Spec Kit. This is an open-source integration, not a partnership or endorsement.

The meta-gate checks that passing and failing demonstrations are registered; it does not rerun every demonstration. These gates are inspectable controls, not a guarantee of correct reasoning or tamper resistance.

DevLoop v1 source ↗Upstream Spec Kit ↗

03 / GAME DESIGN & SYSTEMS

Terrarium

An independent simulation project built around environmental intervention and ecological feedback.

I design the experience, simulation rules and acceptance checks, with AI-assisted implementation.

Independent PC ecosystem simulation · in development

SYSTEMS ARCHITECTURE / 03TERRARIUM

Building an ecosystem from interacting rules.

Water and nutrients shape habitat, feeding links populations, and individual creatures respond to local conditions. The systems below show how these connections are modelled.

HYBRID SIMULATIONRESOURCE CONSTRAINTSOBSERVABLE STATE

Hybrid scalesRELATIONSHIPS / NOT EXECUTION ORDER

01INPUT Intervention interface 02FIELDS Continuous fields 03HYBRID Hybrid-scale modelling 04STATE State-driven behaviour 05BUDGET Energy accounting 06RETURN Capacity-limited nutrient return 07OBSERVE Event observation

Continuous fields, population densities and discrete individuals: different resolutions, coupled through habitat and feeding.

System interfaces

Intervention interface Continuous fieldsLocal change
Continuous fields Hybrid-scale modellingPlant capacity
Hybrid-scale modelling State-driven behaviourFood and prey
State-driven behaviour Energy accountingActual intake
Energy accounting Capacity-limited nutrient returnResidual energy at death
Capacity-limited nutrient return Continuous fieldsNutrient return
Hybrid-scale modelling Event observationPopulation thresholds
Continuous fields Event observationTerrain-share shifts

DESIGN FOCUS

INPUT

Intervention interface

Player intent enters the simulation as a local perturbation, not a prescribed outcome.

DESIGN CHOICE

Separate the timing of an action from its spatial effect. Let the simulation determine the response.

Structure & boundaries

INTERFACE: Intervention type · spatial extent · intensity · tick boundary
MECHANISM: Queued rain and fire actions apply a radial falloff to environmental fields before the next simulation step.
STATE: A bounded change to water and, for fire, nutrients.
BOUNDARY: This connection covers environmental interventions; species placement is a separate input.

FIELDS

Continuous fields

Habitat is a changing constraint field, not a collection of fixed terrain labels.

DESIGN CHOICE

Compute ecological constraints from continuous values; derive terrain labels for presentation.

Structure & boundaries

INTERFACE: Water · nutrients · baseline fields · biological modifiers
MECHANISM: Double-buffered updates combine diffusion, relaxation and configured losses. Species tolerance curves map water and nutrients to suitability; the lower score limits plant capacity.
STATE: Local suitability, plant carrying capacity and derived terrain classes.
BOUNDARY: Suitability constrains capacity. Consumption, density and spread also affect the resulting vegetation.

HYBRID

Hybrid-scale modelling

Grass and ants are represented by density. Four other species have individual positions and vital state on the same grid.

DESIGN CHOICE

Use densities to model aggregate populations; track individuals where position, feeding and energy need to be linked for each creature.

Structure & boundaries

INTERFACE: Species definitions · density fields · individual state · habitat constraints
MECHANISM: Grass and ants evolve as densities. Four other species use individuals with spatial footprints and vital state, projected back onto the shared grid.
STATE: Coupled food densities, individual positions and population totals.
BOUNDARY: Representations are configured per species; this is not an adaptive level-of-detail system.

STATE

State-driven behaviour

Local state determines which actions are eligible; an action-point budget limits how often they are attempted. Filter feeding is evaluated once per simulation step, outside that budget.

DESIGN CHOICE

Compose behaviour from state, eligibility and spatial constraints instead of scripting a fixed life sequence.

Structure & boundaries

INTERFACE: Food and threats · satiety · spatial occupancy · action points
MECHANISM: Speed accumulates action points. Within that budget, grazing or hunting, movement and eligible breeding are attempted in sequence. Filter feeding is evaluated once per simulation step without spending action points. Pursuit and avoidance bias local movement choices.
STATE: Changes in position, prey, vitality and reproductive opportunity.
BOUNDARY: Local rule-based decisions; no learned policy or global planning is implied.

BUDGET

Energy accounting

Resource transfers couple source and receiver; capacity and transaction order matter.

DESIGN CHOICE

Resolve receiver capacity before debiting the source. Commit reproductive cost only after successful placement.

Structure & boundaries

INTERFACE: Available intake · storage capacity · metabolism · breeding cost
MECHANISM: Grazing debits food in proportion to energy actually absorbed. Predation retains unabsorbed energy in remains; reproduction transfers energy only after offspring creation succeeds.
STATE: Bounded reserves, metabolic expenditure and explicit transfers.
BOUNDARY: Local transfer accounting, not a claim of closed-world energy conservation.

RETURN

Capacity-limited nutrient return

Remains release nutrients into the soil over time. The soil’s remaining capacity limits each transfer, and the unreturned amount is kept in the remains.

DESIGN CHOICE

Model the receiver’s capacity at the transfer boundary; carry the residual as state rather than clipping it on arrival.

Structure & boundaries

INTERFACE: Residual energy · decay rate · soil headroom · remains age
MECHANISM: Each tick releases no more than local nutrient capacity permits. The remainder persists with its age and is included in world snapshots.
STATE: Gradual nutrient return and persistent residual state.
BOUNDARY: Persistence is age-limited; not all residual resources are guaranteed to return.

OBSERVE

Event observation

The chronicle records an event when a species population crosses its presence threshold or accumulated changes in terrain shares reach a configured threshold.

DESIGN CHOICE

Separate world evolution from its interpretation. Preserve the observer’s baseline when restoring a world.

Structure & boundaries

INTERFACE: Population totals · terrain shares · observation baselines
MECHANISM: Population threshold crossings and accumulated terrain-share shifts trigger templated records. Observation baselines are restored with world snapshots.
STATE: Event entries, epoch transitions and a recoverable observation context.
BOUNDARY: Threshold-based observation and authored templates, not generated causal explanations.

AI helps implement the work. I own the design choices, the questions worth testing, and the decision to accept or revise an implementation.

ENGINEERING RECORDSRecorded states & a repeatability test

ENGINEERING RECORD / LOCAL INTERVENTION

Local rainfall: a paired-run comparison

Same starting state, one local intervention. Compare the run without added rain against the rain run, and follow their water and vegetation at the same moment.

In this recording, rain first adds water while some areas have less grass than in the no-intervention run. Later, the grass differences go both ways: more in some places, less in others.

Two recorded states at the same tick: no intervention on the left, local rain on the right. Colour represents water; leaf glyphs encode block-mean grass density. The dashed circle marks the rain footprint. — Sand → teal: lower to higher waterLeaf size: block-mean grass densityWhite dashed ring: rain area

An abstract view of recorded water and grass density, not gameplay footage. The browser does not run the game engine. Sampled frames play at a presentation pace, not in real time. Leaf glyphs show area density, not individual organisms.

About this recording

A fixed source snapshot and seed; two independent runs differ by one localized rain intervention. Block means of water and grass density use fixed visual scales, quantized to 8 bits for this presentation.

seed 42 · 48 × 48 → 12 × 12 · 21 recorded frames · ticks 0–80

80 ticks span 4 seconds of simulation time in this configuration, sampled at uneven intervals. Difference rings mark quantized grass-density differences of at least 0.008.

This slice does not validate the entire ecology, long-term stability or player experience. The repeatability test below is a separate record.

record SHA-256 53d62771e51370395f02de455be0eed006b923910bf448050e599f3303dc4ff3

Can the same setup reproduce the same state fingerprint?

Engineering detail · separate recorded repeatability test · 2026-09-13

Behind the world: a focused repeatability test.

Repeating the same conditions produced matching fingerprints for the selected fields. Increasing one species-density value changed the fingerprint.

I design the experience, simulation rules and acceptance checks, with AI-assisted implementation.

A state fingerprint is a short value calculated from selected simulation fields. These results come from a separate repeatability test, not the rain recording.

Test conditions: Same code + settings · Same starting point + run length

Same setup. Matching state fingerprints.

Baseline run5c08d02e68b5a8ce

A = B · Match

Same conditions, another run

5c08d02e68b5a8ce

C ≠ A · Change detected

Changed one species-density value by +0.5

1191f7875ca68ccb

What this fingerprint covers: water field · nutrient field · species-density arrays

The fingerprint covers only the state listed above. It does not prove identical pixels, every hidden state in the game, security or tamper resistance.

commit e9216167 · 4.7.stable.official.5b4e0cb0f · seed 42 · 300 ticks · species.densities[0][0] + 0.5 · FNV-1a 64-bit; float fields quantized to 1e-9

Behind the work

Computer science and IT operations.

My IT operations work involves user access, system changes and fault recovery. That experience shapes how I design permissions, handle failures and make software easier to operate.

I studied computer science at McGill, with a mathematics minor, then completed a master’s at UNSW focused on AI and database systems.

How I build with AI

AI helps me implement. I stay responsible for the problem, the system boundaries, the acceptance criteria and the decision to ship.

01 Frame the problem
Decide who needs the result, what can go wrong, and what a useful outcome looks like.
02 Set the scope and checks
Set out what AI may change, which checks it must pass, and when I need to review the work.
03 Check the result
Inspect the work, run the relevant checks, and keep the evidence and unresolved questions together.

How this works in the projects

Verdict: define the product contract
The document-review workflow separates model extraction, deterministic checks and human review. Project specifications and phase prompts guide AI-assisted implementation.
Verdict: check changes before accepting them
Its pre-commit hook runs type-check, tests and build; CI also runs lint. Registered tool hooks reject selected prohibited edits. These are scoped checks, not a security sandbox.
DevLoop: keep work inspectable
The historical Python orchestrator uses separate Git worktrees, resource limits and run records. Worktrees isolate changes, not processes or credentials.
nonconstant: distinguish a failure from a missing check
Shell gates return pass, fail or cannot judge. Enabled gates require recorded passing and failing examples; the registry check does not replay those examples.
Across projects: turn failures into specific changes
10 documented incident patterns connect failures to changed checks or working practices. The Verdict build incident is one example; each safeguard has its own coverage and limits.

Full write-up: the failure-mode dictionary → · nonconstant: https://github.com/HaohangXia/nonconstant

The reasoning behind the work

Define what would count as a useful result before deciding what to ask a model to do. The full notes set out the assumptions, working checks, and problems this approach still does not solve.

Explore the engineering decisions →

Case study — Verdict

Why I separated extraction from decisions, how reviewers can inspect a finding, and what the evaluation does—and does not—measure.

Read the case study →

Writing

The decisions, surprises and lessons behind the work.

My coding agent reported a build pass from a hook with no build step 2026-08 · PUBLISHED

Get in touch

A question about a project, an idea, or a different way to approach the problem? I would enjoy comparing notes.

xhh-0-hhx@outlook.com

Let’s compare notes