About me

Applied AI Solutions Builder

I build AI-assisted tools for everyday workflow problems. I care about making them useful, understandable, and clear about where human judgment matters.

Away from the keyboard, I enjoy film photography, cooking, and the energy of team sports.

Selected work / 001

Projects

Grounded retrieval, governed development, and authority-preserving automation.

Choose a roll to develop its proof cover, then open the case notes to follow the decisions.

Clean film / no selectionThree rolls ready

Choose a project to open its proof cover.

Each roll reveals Current, Next, Before, Decision, After, and the boundary around its evidence.

No project selected. Choose a roll to open its proof cover.

Static equivalent / JavaScript unavailable

All three project dossiers remain available without motion.

01 / Trustworthy source-grounded retrieval

Danish Immigration RAG

Evidence-bounded local retrieval keeps citations, source review, and refusal boundaries visible.

Problem
Policy questions become unsafe when a fluent answer hides which official material supports it, which source version was reviewed, or where the available evidence stops.
Constraints
Keep retrieval local and inspectable rather than depending on an opaque hosted corpus. Attach citations to the answer and distinguish source review from generated prose. Refuse or qualify unsupported conclusions instead of presenting legal guidance as certainty. Keep the answer path local-only and separate it from explicit, user-approved knowledge-release updates.
Current
The public repository implements a local answer path with citations, source-state checks, signed knowledge releases, and explicit refusal behavior.
Next
Official-source review and independent semantic adjudication must close the recorded production-qualification gaps.
Limitation
This project does not provide legal advice or eligibility decisions. Its public repository proves a local application and governance machinery, but the bundled knowledge release is fixture-based, five semantic metrics lack independent adjudication, and the work is not production-qualified.
Human decision
A reviewer decides which sources are authoritative and when an unsupported conclusion must be qualified or refused.
Evidence
Public architecture, evaluation, and governance records support the case study; the three-state visual remains an intentionally synthetic explanation.
Snapshot
Public repository evidence / main at ade2b28
Evidence date
2026-08-18
Disclosure
approved
Disclosure approved
Yes
Disclosure reviewed at
2026-09-05
Disclosure reviewer
Eric Leung — prior approval confirmed by owner
Disclosure notes
The owner confirmed in the 2026-09-05 conversation that this narrative was already approved. This records that existing decision; whole-site release and separate repository-link reviews remain distinct.
Reviewed links
four public project records reviewed for portfolio use
Project workflow
  1. Source review — Check authority, scope, version, and public-use boundary.
  2. Local ingest — Prepare an inspectable local corpus with stable source identity.
  3. Retrieve — Surface passages that match the question and preserve their source trail.
  4. Cite — Keep answer claims beside the passages that support them.
  5. Evaluate — Check support, changed-source behavior, and refusal boundaries.
  6. Qualify release — Hold publication until evidence and limitations are reviewed by a person.
Development workflow
  1. Frame — State the visitor question and the exact evidence seam under test.
  2. Contract — Define content, disclosure, citation, and no-overclaim requirements.
  3. Slice — Implement one visible retrieval and review path at a time.
  4. Check — Exercise content, browser, accessibility, and fallback behavior.
  5. Review — Inspect claims, source boundaries, limitations, and presentation together.
  6. Qualify — Record what is controlled, recorded, or still unverified before release.
Validation provenance / status
  • Public evaluation report / 2026-07-14 — Evidence date: 2026-07-14; recorded / Public evaluation quality bar and its linked machine-readable report in the project repository.: All 20 evaluation surfaces completed with zero execution errors; citation coverage, answer behavior, trust indicators, and six automated workflows passed their recorded checks.Environment: Windows 11 with WSL2 Ubuntu and local Ollama; Evidence type: Machine execution and hash-bound workflow evidence; Limitations: Five release-blocking semantic metrics remain not evaluable because independent human adjudication is absent; strict release qualification is false.
  • Source registry production qualification — Evidence date: 2026-08-18; unverified / Public source-governance document and repository implementation at the reviewed main commit.: The repository implements explicit source states, signed manifests, integrity checks, user-approved installation, and atomic rollback boundaries.Environment: Signed local knowledge-release workflow; Evidence type: Governance contract and production-blocking registry state; Limitations: The bundled corpus contains project-authored fixtures; official snapshots and named human source-review records are still required for production qualification.
Named human decisions
  • Choose what can enter the corpus — A human reviewer decides which source material is authoritative, current enough, and safe to expose in a public case study. Why: Retrieval quality cannot repair a source that is out of scope, private, stale, or presented without the context needed to interpret it.
  • Keep unsupported answers bounded — A human reviewer defines when the system must qualify, refuse, or point back to the source instead of filling an evidence gap. Why: A confident answer is not evidence of eligibility, legal advice, or current policy, so the boundary must remain visible in the release decision.
  • Qualify the release claim — A human reviewer decides whether the available validation supports a public explanation and names the limitations that remain. Why: Schema completeness and passing checks make the dossier inspectable; they do not authorize factual or publication approval.
Before / Unsupported draft
Support trace

Claim: Drafted · Citation: Missing

Hold / Held for review
Decision / Source reviewed
Source review

Source: Versioned · Scope: Narrowed

Review / Scope narrowed
After / Bounded response
Release record

Answer: Qualified · Citation: Attached

Bounded / Citation attached
Intent / Build / Proof case notes
Motivation and problem
When an answer cannot outrun its sources

The trust problem begins when fluent language appears more certain than the material beneath it. This project keeps source identity, version, supporting passages, and the stopping rule close to the answer so a visitor can inspect the boundary instead of inferring it from tone.

Project workflow
Six handoffs behind one evidence-bounded response

Candidate material moves through source review, local ingest, retrieval, citation, evaluation, and release qualification. Each handoff leaves a small record that can be checked independently; the generated answer is never the only artifact in the workflow.

What works today
A local assistant with its evidence trail attached

The public project implements a loopback-only web assistant, hybrid local retrieval, local generation, citations, source freshness, refusal behavior, signed knowledge-release verification, and rollback. Its machine evaluation completed all 20 surfaces, while deliberately withholding strict qualification where human semantic judgment is missing.

Next milestone
Close the human qualification gaps

The next milestone is a production-candidate release built from archived official pages and named human review records, followed by independent adjudication of required facts, forbidden claims, privacy requirements, citation relationships, and unsupported-claim rate.

Human decisions
Release authority stays with a reviewer

A person decides which sources are authoritative enough to enter the corpus, which claims require qualification or refusal, how changed material is handled, and whether the resulting evidence is safe and accurate enough to present. The retrieval layer prepares a record; it does not grant authority.

Evidence and demonstration
Public records behind the synthetic explanation

The linked repository, architecture, evaluation quality bar, and source-governance record are the factual evidence for this case study. The browser-native sequence remains synthetic by design: it explains an unsupported draft, a source-review decision, and a bounded response without presenting itself as a live immigration answer.

How the development workflow was tailored
Build around source, citation, and refusal seams

The development workflow is sliced at source approval, retrieval, citation, response checking, and release qualification seams. Each slice can be reviewed independently, while the content contract fails closed until evidence provenance, limitation language, and disclosure status are present.

Limitations
What this dossier deliberately refuses to claim

The assistant is not legal advice and does not decide eligibility. The public source registry says its bundled documents are project-authored fixtures rather than reviewed official snapshots, and five release-blocking semantic metrics remain not evaluable without an independent reviewer. Passing machine checks therefore does not establish production qualification.

Four-beat static demonstration

Without motion, the same demonstration reads as input, intervention, bounded outcome, and limitation: a question enters, reviewed sources attach, a changed source is held, and the answer stops at available evidence.

  1. 01 / Question — Question enters the local guide
    Input: A visitor asks a policy question. Intervention: The guide records the question before drafting. Outcome: The request has a visible evidence target. Limitation: No answer is implied by the question alone.
  2. 02 / Sources — Reviewed passages attach
    Input: A bounded source set is available. Intervention: Relevant passages and source identity stay beside the draft. Outcome: Support can be inspected before release. Limitation: Source presence does not prove every claim.
  3. 03 / Review — Changed source is held
    Input: A source version or scope changes. Intervention: Review narrows the answer and marks the evidence gap. Outcome: The unsupported conclusion does not pass silently. Limitation: The synthetic change is not a live policy update.
  4. 04 / Answer — Answer stops at evidence
    Input: Only the reviewed support remains available. Intervention: The response qualifies its boundary and keeps citations attached. Outcome: A human can release, revise, or refuse the bounded response. Limitation: The frame is illustrative and makes no legal or eligibility claim.

Synthetic demonstration — public-safe recreation, not a live immigration answer.

02 / A desktop app for local AI coding agents

Alfredo

Give local coding agents a bounded task, inspect their changes and tests, and review the result before preparing a pull request.

Problem
When an AI agent changes code, you need to know what it was allowed to change, what it actually changed, which tests ran, and how the result was accepted.
Constraints
Keep task state, permissions, execution, evidence, and review decisions in the Python Orchestrator, the backend that checks and records authorized actions. Bind each delegated slice to an exact Mission, goal, acceptance criteria, allowed paths, command policy, and eligible Local Agent before launch. Run agents in isolated working copies with limits on files, commands, and resources. Incomplete evidence can be inspected, but acceptance requires a complete Evidence Package. Allow automatic actions only within the recorded permission boundary; gated or uncertain decisions return to a person. Accepted work is PR-ready and does not authorize a merge.
Current
Alfredo runs local coding agents in isolated working copies, records their changes and tests, and supports review and repair before preparing a pull request handoff.
Next
The documented remaining work is public package publication and reinstall, human desktop and accessibility testing, and repeated performance measurements.
Limitation
The reviewed evidence supports a local workstation and verified Linux release candidate; it does not prove public registry publication, broader operating-system compatibility, human real-display or assistive-technology acceptance, production performance, or automatic merge or deployment.
Human decision
People select the repository and task, resolve requests for additional authority, and handle escalated reviews. Some actions proceed automatically within existing permissions.
Evidence
The linked reports record review-rule tests, a real-backend workstation journey with recovery and restart, and separate installed Linux and browser checks.
Snapshot
Public repository evidence / main at af74a85
Evidence date
2026-09-03
Disclosure
approved
Disclosure approved
Yes
Disclosure reviewed at
2026-09-05
Disclosure reviewer
Eric Leung — prior approval confirmed by owner
Disclosure notes
The owner confirmed in the 2026-09-05 conversation that this narrative was already approved. This records that existing decision; whole-site release and separate repository-link reviews remain distinct.
Reviewed links
four public project records reviewed for portfolio use
Project workflow
  1. Choose a repository and task — Select the Git repository, called the Coding Workspace, then start or resume a Mission: the recorded body of work.
  2. Check the permitted scope — Verify the goal, success criteria, allowed files, commands, and eligible agent. Matching requests can proceed under existing authority; other requests need a decision.
  3. Run an agent in isolation — Queue a local coding agent in an isolated worktree, a separate working copy of the repository.
  4. Collect changes and test results — Build an Evidence Package containing changed files, a diff summary, commands, test results, risks, proposed context updates, and inspectable artifacts.
  5. Review and repair — Inspect complete or incomplete evidence. Review decisions can accept the result, request repair, or escalate to a person; incomplete packages cannot be accepted.
  6. Prepare a pull request handoff — Keep accepted evidence and prepare PR-ready instructions. Acceptance does not authorize merging the changes.
Development workflow
  1. Build in issue-sized pieces — The architecture records a development backlog organized into Issue Slices, each representing a piece of the product.
  2. Implement and test review rules — The June report records Python review decisions, typed client and desktop contracts, and tests for incomplete evidence and stale decisions.
  3. Test the connected workstation — The August report drives the React clients against the real Python backend through repository selection, task dispatch, review, recovery, and restart.
  4. Verify the installed Linux candidate — A separate gate builds and installs the packaged desktop through a local test registry, then checks the launcher, interface, backend, and artifact integrity.
  5. Record results and remaining checks — The reports list passing checks alongside unfinished release, human accessibility, and performance work.
Validation provenance / status
  • Modernized workstation verification / 2026-08-30 — Evidence date: 2026-08-30; recorded / Public Issue #75 modernized-workstation verification report at the reviewed Alfredo main snapshot.: The recorded journey selects an exact workspace and Mission, confirms a shared-understanding gate, dispatches governed tracked and ad hoc work, reviews evidence, recovers a controlled crash, retires accepted sessions, and restores the same chronology after restart.Environment: Real Python CLI and backend, React/Tauri workstation, installed Linux release candidate, and Chromium desktop-to-mobile viewports; Evidence type: Public-seam integration, recovery, release-candidate, and responsive-browser evidence; Limitations: The run did not publish packages, perform registry-only reinstall, complete human real-display or assistive-technology acceptance, or establish production performance.
  • Review Workspace Evidence Package / 2026-06-25 — Evidence date: 2026-06-25; recorded / Public Review Workspace Evidence Package completion report at the reviewed Alfredo main snapshot.: The focused record verifies complete and incomplete Evidence Packages plus acknowledged accept, repair, and human-escalation decisions, including stale-revision protection and disabled incomplete acceptance.Environment: Python Orchestrator, React and TypeScript clients, and Rust/Tauri bridge test surfaces; Evidence type: Evidence contract, integration, and rendered review-action tests; Limitations: This focused historical record supports the review seam; the later integrated workstation report is the current overall capability snapshot.
Named human decisions
  • Set the scope and resolve permission requests — A person selects the repository and Mission. Alfredo checks each delegation against recorded authority; requests requiring additional permission or a gated worker need an explicit decision. Why: Automatic approval is possible within an existing boundary. The routing model cannot expand that boundary by proposing a task.
  • Handle decisions that need human review — A person can inspect the evidence and choose acceptance or repair, and handles outcomes escalated for human review. The architecture also supports a model reviewer whose recorded outcomes can drive repair and PR readiness. Why: Raw test output or model prose alone cannot authorize acceptance; the Orchestrator checks the review decision and evidence requirements.
  • Keep delivery separately authorized — Alfredo prepares pull request instructions without granting merge approval. Its documented package publication path requires separate authorization. Approval to publish this portfolio narrative is the portfolio owner's policy. Why: A recorded review outcome does not establish that a package was released or that the owner approved a public portfolio claim.
Before / Boundary approved
Task contract

Allowed: guide.md · Worktree: Isolated

Bounded / Ready to delegate
Decision / Boundary check fails
Evidence Package

Expected: guide.md · Unexpected: settings.json

Invalid / Invalid result
After / Human-led review accepts repair
Review outcome

Boundary: Restored · Authority: Human

Accepted / PR-ready, not merged
Intent / Build / Proof case notes
Motivation and problem
Make an agent's work inspectable

A useful-looking change can hide which files an agent was allowed to touch, which commands it ran, and how the result was accepted. Alfredo brings the task, permissions, changes, tests, and review outcome together in one desktop app. Its Python backend checks and records authorized actions.

Project workflow
From a chosen repository to a reviewed result

Select the repository, called the Coding Workspace, and start or resume a Mission, the recorded body of work. Alfredo checks the task and agent against existing permissions before running it in an isolated working copy. Changes and tests form an Evidence Package for inspection. Review can accept a complete result, request repair, or escalate to a person. Accepted work is ready for a pull request handoff.

What works today
Local agents, recorded permissions, visible results

The reviewed architecture describes a React/Tauri desktop app with a Python Orchestrator, the backend responsible for task state and permission checks. It supports tracked and ad hoc tasks, isolated worktrees, evidence inspection, and review and repair. The August integration report exercises dispatch, acceptance, controlled crash recovery, retained session records, and restoration of the work history after restart.

Next milestone
Finish release and human usability checks

The August report leaves public package publication and a fresh public-registry installation open. It also calls for people to test the installed desktop with a keyboard and assistive technology, plus repeated measurements of the installed app before making performance claims. These are the report's remaining checks at the reviewed snapshot.

Human decisions
Where a person makes the decision

People select the repository and Mission and handle permission requests or escalated reviews. Matching tasks may be approved automatically within existing authority. People can review evidence, and the architecture also gives a model reviewer a role in repair and PR-readiness decisions. The backend checks those decisions; incomplete evidence cannot be accepted. Merge approval remains separate, and this portfolio's publication approval belongs to its owner.

Evidence and demonstration
What the reports show

The June report records tests of evidence inspection, acceptance, repair, and escalation to a person. The August report drives real backend actions through test clients and separately checks an installed Linux candidate and responsive browser layouts. These are documented test results, not a human production-usage study. The four browser beats are a fictional example of a failed file-boundary check followed by repair and human-led review.

How development was verified
From review rules to the connected app

The sources record issue-sized implementation work. The June slice adds backend review rules, typed client and desktop interfaces, and rendered tests. The August work connects the React clients to the real Python backend and separately verifies the installed Linux candidate, recovery, restart, and browser layouts. This connects focused review-rule tests to checks of the assembled app and its installed package.

Limitations
The limits of the recorded evidence

The sources support the local workstation and a tested Linux release candidate. They do not establish public package availability, broad operating-system compatibility, completed human desktop or accessibility testing, or production performance. Accepted changes reach PR-ready status without merge approval. The portfolio owner separately decides whether to publish this account.

Four-beat static demonstration

The same story is available without motion: a task permits one file, a command changes another file and invalidates the session, a repair reverts that change, and a person reviews the corrected result for PR readiness.

  1. 01 / Bound — A one-file task is approved
    Input: A fictional task permits an example in guide.md only. Intervention: Alfredo records the goal, permitted file, command policy, and selected local agent before launch. Outcome: The task's permitted scope is visible before work begins. Limitation: The task and filenames are synthetic public-safe data.
  2. 02 / Check — A file-boundary check fails
    Input: In the isolated working copy, a command changes guide.md and also settings.json. Intervention: Alfredo checks changed files against the permitted scope and invalidates the session for the extra change. Outcome: The failed check is visible; this result cannot be accepted as successful work. Limitation: This example shows a command-produced change; model file plans are checked before writing.
  3. 03 / Review — The failed result needs repair
    Input: The failed result records the unauthorized settings.json change. Intervention: The reviewer requests a repair that reverts the unauthorized change while retaining the permitted guide.md work. Outcome: The repair must stay within the existing permission boundary and return corrected evidence. Limitation: The filenames are fictional demonstration data.
  4. 04 / Accept — A person accepts the restored boundary
    Input: The unauthorized settings.json change is reverted and the repair returns a complete Evidence Package. Intervention: In this human-led example, a person reviews the corrected changes and tests before accepting the result. Outcome: The work is recorded as PR-ready, not merged. Limitation: No live write, pull request, merge, publication, or deployment is implied.

Synthetic demonstration — public-safe recreation: a human-led example, not a live repository action or the only supported review path.

03 / Human-authoritative hybrid automation

PersonalWorthTracker

Deterministic rules, review-only suggestions, dry runs, and confirmed copied output keep authority visible.

Problem
Automation over sensitive records is risky when an uncertain suggestion can silently become a change to the original artifact.
Constraints
Keep the original artifact untouched and make copied output explicit. Use deterministic rules for known cases and route uncertainty to review-only suggestions. Review the dry run before explicitly requesting a copied-workbook write; this is an operator procedure, not a stored approval lock. Use synthetic records in the demonstration rather than real financial or private data.
Current
PersonalWorthTracker prepares workbook updates with deterministic rules and review-only suggestions. A person reviews the plan and requests a separate copy.
Next
Approve a reproducible synthetic source run before making release or performance claims.
Limitation
This is a synthetic explanation of the approved workflow, not financial advice, a financial product, a live model evaluation, or proof of autonomous writes. Source-project release verification remains pending. Dry-run review is an operator procedure, not a mandatory software approval lock.
Human decision
A person resolves uncertainty, inspects the full dry run, and explicitly requests a separate workbook copy.
Evidence
The fictional plan, human decision, and working-copy result show the control sequence. Source-project release evidence remains unverified.
Snapshot
Issue #20 architecture / synthetic dossier reviewed 2026-09-05
Evidence date
2026-09-05
Disclosure
approved
Disclosure approved
Yes
Disclosure reviewed at
2026-09-05
Disclosure reviewer
Parent agent under explicit owner-delegated authority
Disclosure notes
The owner delegated this publication decision to the parent agent after independent Astra verification. Approval covers this sanitized narrative and synthetic demonstration only. Public source-release evidence remains unverified; private source contents and deployment are outside this approval.
Reviewed links
No public source evidence approved; local source contents excluded
Project workflow
  1. Import — Read the selected input and workbook to prepare a proposed update.
  2. Classify — Apply deterministic rules to the rows that are already understood.
  3. Suggest — Keep model suggestions constrained to review; they cannot authorize a workbook write.
  4. Review — Ask a person to resolve ambiguous rows and approve the plan.
  5. Dry run — Inspect the full proposed update after resolving review rows and before requesting a copy.
  6. Copy — Explicitly request a separate workbook containing eligible updates; unresolved suggestions stay out.
Development workflow
  1. Frame the boundary — Define what deterministic automation may do and which decisions stay with the operator.
  2. Separate the changes — Keep categorization, model suggestions, review decisions, and workbook writing independently inspectable.
  3. Use synthetic fixtures — Exercise known and ambiguous cases without copying personal financial records into tests.
  4. Check the boundaries — Check that suggestions still require review and that the copied output preserves the original.
  5. Review the evidence — Compare implementation and tests with the intended authority rules; a test count alone does not prove model quality.
  6. Qualify the account — Separate local source inspection from a reproducible public release and approved portfolio claims.
Validation provenance / status
  • Issue #20 / synthetic three-row workbook example — Evidence date: 2026-09-05; controlled / Purpose-built example based on the architecture approved in portfolio issues #15 and #20. All row labels and amounts are fictional.: Rows A and B follow deterministic rules; row C stays review-only until a fictional human decision. A complete dry run precedes a separate working-copy outcome.Environment: Static portfolio in a local browser; Evidence type: Controlled synthetic workflow demonstration; Limitations: The browser changes presentation state only. It does not run a model, process a workbook, or prove source-project write safety.
  • Public source-project evidence pending — Evidence date: 2026-09-05; unverified / Owner-directed local inspection. No private source files, workbooks, reports, repository links, or release identifiers are reproduced.: Local inspection informed the distinction between review-only suggestions, operator dry-run review, and an explicit copied-workbook write request. No source-project test result is claimed here.Environment: Owner-provided local source inspection; no public reproduction; Evidence type: Implementation and test review, not an executed release qualification; Limitations: An independently reproducible source snapshot and approved public evidence are still needed.
Named human decisions
  • Resolve uncertainty before it becomes change — A human decides how an ambiguous row should be classified and whether the suggestion is safe to include in the plan. Why: Uncertainty should route to a person, not be disguised as a deterministic output or silently copied to a new artifact.
  • Confirm the complete dry run — The operator inspects the complete dry run and explicitly requests the copied-workbook update. The documented sequence does not establish a mandatory software approval lock. Why: A partial preview can hide a surprising row. Review should precede the write request even when the command can be invoked directly.
  • Authorize the separate working copy — The operator checks the separate working copy before using it; a model suggestion cannot approve itself or authorize a write. Why: The system may prepare a working copy, but it must not present a write as authorized until the responsible person confirms it.
Before / Proposed plan
Dry-run plan

A / B: Rules matched · C / 10: Needs review

Dry run / Dry run
Decision / Confirmed plan
Review decision

Row C: Travel, not supplies · Dry run: 20 supplies / 40 travel

Approved / Approved
After / Copied output
Copy record

Original: Untouched · Result: Working copy

Copied / Local only
Intent / Build / Proof case notes
Motivation and problem
Suggestions become dangerous when they look final

Routine automation can reduce review effort, but an uncertain suggestion must not silently become a change. The approved project design separates deterministic work, model-assisted proposals, human confirmation, and copied-workbook output so responsibility remains visible at every step.

Project workflow
Six steps before an eligible copy exists

Read the input, classify known cases with deterministic rules, and keep model suggestions review-only. A person resolves uncertain rows, inspects a fresh dry run, and explicitly requests a separate workbook containing eligible updates. This describes the operator workflow; the command does not require a stored record proving the operator inspected the dry run.

What works today
The dry run is the decision surface

Local inspection supports a workbook-update workflow with deterministic classification, constrained suggestions, human review, and an explicit copied-output command. The demonstration below explains those boundaries with fictional rows. It does not execute the source project or establish release readiness; its browser checks establish presentation behavior only.

Next milestone
Publish a reproducible synthetic source run

The next evidence should show the source project processing an approved synthetic workbook: known rows, an unresolved suggestion, a reviewed decision, the full dry run, and an identifiable copy. Verify original preservation and failure cases before presenting that run as release evidence. No private source material is required in the portfolio.

Human decisions
Uncertainty routes to review, not authority

A person resolves ambiguous categories and rejects unsafe proposals. They inspect the full dry run, request the copy, and decide whether to use its result. A high-confidence model proposal is still only a suggestion. Following the review procedure remains the operator’s responsibility; no mandatory approval screen is claimed.

Evidence and demonstration
Compare the plan, confirmation, and copied result

The fictional example follows rows A, B, and C throughout. A and B match deterministic rules; C receives a constrained proposal that a person corrects. The dry run contains all three decisions before the working-copy outcome appears. These are controlled browser states, not a recording of a financial operation or an executed model.

How the development workflow was tailored
Test each safety boundary where it changes

The development account concerns building and checking the automation, rather than operating a monthly run. Local inspection found separate implementation and tests for deterministic categorization, review-only model suggestions, and copied-workbook behavior. This supports a boundary-focused development account, not a claim about test-first chronology or exclusively manual authorship. Public development evidence remains pending.

Limitations
A demonstration is not release evidence

No real financial record, private memory, source workbook, destructive write, or independently validated performance result is present. The demonstration explains control architecture with synthetic material only and does not turn a passing schema or browser check into financial or operational advice.

Four-beat static demonstration

Sample.xlsx contains A: supplies 20, B: travel 30, and C: mixed purchase 10, in fictional units. Rules classify A and B. A model proposes supplies for C; a person corrects C to travel and checks the full dry run: supplies 20, travel 40. Only then does the example show Sample-working.xlsx; Sample.xlsx stays unchanged. No workbook is actually created by this page.

  1. 01 / Input — Three rows; one original workbook
    Input: Sample.xlsx: A / supplies / 20; B / travel / 30; C / mixed purchase / 10. All values are fictional units. Intervention: Read the three rows and preserve the original workbook. Outcome: A, B, and C are available for a proposed update; no output is written. Limitation: This page presents fictional data; it never opens a real workbook.
  2. 02 / Constrained review — Rules settle two rows; a suggestion stays pending
    Input: A matches supplies; B matches travel. C has no deterministic match. Intervention: The fictional model proposes supplies for C from the allowed categories: supplies or travel. Outcome: A / supplies / 20 and B / travel / 30 are classified. C / 10 remains review-only with no write authority. Limitation: A valid category or confident proposal is not human confirmation.
  3. 03 / Human confirmation — A person corrects C and checks the full dry run
    Input: C / 10 still needs a decision; the proposed category is supplies. Intervention: A person chooses travel for C and inspects all rows: A / supplies / 20; B / travel / 30; C / travel / 10. Outcome: Dry run: supplies 20; travel 40. The person explicitly requests a working copy after review. Limitation: This is a fictional operator decision, not an enforced approval screen or a live command.
  4. 04 / Working copy — An eligible copy; the original preserved
    Input: The reviewed plan contains supplies 20 and travel 40, with C corrected by a person. Intervention: The example applies eligible updates only to Sample-working.xlsx. Outcome: Working copy: supplies 20; travel 40. Original Sample.xlsx remains unchanged. Limitation: Illustrated outcome only: no download, workbook write, autonomous action, or financial result occurs here.

Synthetic demonstration — public-safe recreation: fictional rows and decisions, not a financial record or live model run.

Hobbies

Outside of work, I enjoy capturing everyday moments with my Nikon F3, experimenting in the kitchen, and cooking for the people I care about. I also love the energy and social side of team sports, especially basketball and volleyball.

  1. Film PhotographyView 7 photosClose photos

    I started this hobby over ten years ago. Here are some of my favorites to share.

    1. Man in Copenhagen
      01 / Film photography

      Man in Copenhagen

    2. Icelandic horse
      02 / Film photography

      Icelandic horse

    3. My friend Kellas
      03 / Film photography

      My friend Kellas

    4. My grandma
      04 / Film photography

      My grandma

    5. Mongkok, Hong Kong
      05 / Film photography

      Mongkok, Hong Kong

    6. Sham Shui Po, Hong Kong
      06 / Film photography

      Sham Shui Po, Hong Kong

    7. Guitar man in Hong Kong country park
      07 / Film photography

      Guitar man in Hong Kong country park

  2. CookingView 6 photosClose photos

    I mainly make Italian and Asian food, sometimes combining Chinese and Western styles.

    1. Homemade dumpling
      08 / Cooking

      Homemade dumpling

    2. Carbonara
      09 / Cooking

      Carbonara

    3. Pan fried Hakka stuffed tofu
      10 / Cooking

      Pan fried Hakka stuffed tofu

    4. Malay Curry Chicken
      11 / Cooking

      Malay Curry Chicken

    5. Chinese egg noodles with spicy minced pork
      12 / Cooking

      Chinese egg noodles with spicy minced pork

    6. Homemade Tonkotsu Ramen
      13 / Cooking

      Homemade Tonkotsu Ramen

  3. Watching old and new filmsNo photos shared yet

Contact

Let’s talk.

Get in touch by email or connect with me on LinkedIn.