Andrew Xia · AI systems & automation

Useful AI. Evidence you can inspect.

I build independent software for document review, coding-agent verification and ecological simulation. I design the workflows and acceptance checks; production IT informs access, change and recovery.

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 work

Different problems. Decisions you can see.

Document review, verification for coding agents, and an ecology simulation. Each explores a different way to make a complex system understandable.

01 / VERDICT · Document AI · prototype

Catch conflicting paperwork before the handover

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 the review workflow and identify their example ruleset. Separately, the 2026-06 extraction evaluation compared fields against clean English text reconstructed from 85 synthetic document fixtures.

57documented checks across two workflows

85synthetic document-text fixtures evaluated

96.3%field agreement · 2026-06 · normalisation / numeric tolerance

Explore a synthetic case ↓Read the case study →

Verdict — explore a shipment review

Explore a synthetic case, inspect its source fields, or replay the illustrated steps. Model extraction feeds written checks; a person reviews what the system flags.

SYNTHETIC CASES · illustrated prototype workflow

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.

Invoice vs packing list disagree999-55667788 · PVG → SYD · 40 pcs · 612.5 kg · Ceramic tableware · CIF

Upload
Classify
Extract
Validate
Score
Draft

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.

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
- Commercial Invoice · cartons40 cartons · 4,800 pcs
- Packing List · cartons38 cartons · 4,560 pcs
rule BG-XDOC-007 · snapshot c6f89cf4…

Measured on deepseek-v4-flash at temperature 0 · prompt precheck-extract-v3.0 · 1 recorded run

View the eval report

Recorded extraction evaluation · 2026-06

measured 2026-06 · 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%
Extraction failures	0 · True misses: 2 — both reproduced by the harness and reviewed field-by-field
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 this demo works

These synthetic cases illustrate the prototype’s document-review workflow. Document values are invented; rule IDs, thresholds and follow-up wording are simplified for presentation, not an unmodified operational report. Exploring a case makes no LLM request or document upload. The ruleset hash identifies the public example catalogue, not a guarantee of correctness. This is an independent prototype in development; the examples do not authorise shipment.

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

Independent project · AI coding verification

nonconstant“Done” needs more than a confident answer.

An AI agent can say the work passed even when a check is missing or its criteria changed. I built a separate verification toolkit that distinguishes evidence of success, evidence of failure, and not enough evidence to judge.

A checkable contract

Shell gates with three explicit outcomes, including a separate state for missing conditions.

Checks on the checks

Detection of changed criteria, known hidden-failure patterns, and status claims that no longer match the repository.

A portable verification layer

A configuration-led installer, commit-linked reports, and an optional pinned workflow integration.

Same claim. Different evidence.

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

Life is not a feature. It is a system of interdependent constraints.

Continuous fields, population densities and individual behaviour meet in one simulation core—exploring how local rules shape an ecosystem.

HYBRID SIMULATIONCONSTRAINED RESOURCESOBSERVABLE 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 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 returnResidual energy at death
Capacity-limited 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

Population fields and discrete individuals share a spatial model without sharing the same representation.

DESIGN CHOICE

Choose resolution by the interaction: aggregate abundance at field scale, preserve agency at individual scale.

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

Movement, feeding and reproduction respond to local state within an explicit action 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. Feeding, movement and breeding attempts run within that budget; 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 return

Death changes the form of a resource and creates feedback across simulation layers.

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

Continuous state change becomes a sparse sequence of significant world events.

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 & independent verification

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 densityDashed ring: one rain intervention

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

One level deeper: does the changing world still follow its rules?

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

Behind the world: a focused repeatability test.

Repeat the same conditions and the tested state matches. Change one measured value and the check detects the difference.

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

These fingerprints belong to a separate focused test, not the rain replay. That test compares selected simulation fields under fixed conditions.

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

Same starting point. Same tested state.

Baseline run5c08d02e68b5a8ce

A = B · Match

Same conditions, another run

5c08d02e68b5a8ce

C ≠ A · Drift caught

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

A systems foundation. An operational perspective.

Production IT makes access, change and recovery everyday concerns. That experience shapes my independent projects: start with the person doing the work, then make the system’s behaviour visible.

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

I define the work. Then test what came back.

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 Build with boundaries
Use AI for implementation while keeping access, decision rules and recovery paths explicit.
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 an exit code for a command it never ran 2026-08 · PUBLISHED

Useful AI. Evidence you can inspect.

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