ChatGPT + DUO + your own agent
Build your own Singapore
tax computation agent
build a small, auditable Singapore corporate income tax agent that turns a fictional company's accounts and reviewed tax decisions into a draft computation, supporting schedules and a review pack. Build the knowledge foundation first, then the templates, skills, scripts, assets, workflow and agent instructions. Prove that the complete system works in the environment where you will actually use it.
Keep one conversation open in this ChatGPT app. Use it to investigate, ask questions, approve bounded changes and review the work. The agent can inspect the selected environment and choose the implementation; you do not need to memorise shell commands. You supply the context and judgement that software cannot establish for you.
The two tracks are Codex on your PC and Hermes Agent on your VPS. Codex performs the work in a local project organised with eve-inspired architecture (opens in a new tab); this course does not install or deploy eve. Hermes runs the agent on the VPS. Both tracks use the Markdown second brain (opens in a new tab). Build the tax agent as a separate practice project, with its own approved sources, fictional case inputs and permissions. NanoClaw and OpenClaw remain optional later ports.
Scope: a teaching guide for a fictional-data practice project, revised 9 October 2026. The worked arithmetic has been checked under its stated assumptions against the cited IRAS guidance. No tax engine or private-agent case is supplied or certified. The official IRAS workbook has not been executed for this lesson. A qualified Singapore tax reviewer must approve the student's rules, expected results and workpapers before real use; this guide does not authorise filing.
Three modes. Keep the conversation moving.
Darryl Wong's DUO Framework version 0.2 (opens in a new tab) gives this conversation three modes:
- Discover: let the agent broaden the context, inspect evidence and uncover unknowns
- Understand: add your situation, question the evidence, weigh the options and make defensible decisions
- Output: explicitly request the next useful deliverable from that agreed understanding, then review it
The modes are iterative. The three prompts in each stage are examples to adapt, not a mandatory three-prompt ritual. Spend more time discovering where evidence is weak. Stay in Understand while eligibility or treatment is undecided. Return from Output when a test exposes a missing fact. The human decides when to build and when the result is complete.
For example: the agent retrieves a deduction rule; you ask whether the expense was actually incurred for the business; evidence is missing; the agent prepares a missing-information list instead of silently claiming the deduction. That is a useful outcome.
DUO is a practical framework, not a guarantee of correct decisions. In consequential tax work it supplements primary-source verification and qualified review.
Before you start
Use fictional cases and keep human review
Use a working Codex environment or the non-administrator Hermes setup from your VPS lesson. ChatGPT must check the actual connection, filesystem, installed tools and permissions before proposing commands. Uploading this guide does not install skills, create persistent storage or connect a runtime.
Begin with fictional data. Do not put real client accounts, names, UENs, NRICs, bank details, passwords, tokens or private case files into this lesson's shared materials. Your first agent needs no IRAS sign-in, Xero connection, payment method or filing access.
Choose a narrowly supported case: a Singapore trading company, one agreed Year of Assessment (YA), a clearly identified accounting period, SGD amounts and a reviewed set of adjustments. Personal income tax, GST, withholding tax, incentives, complex foreign income, group relief and other advanced matters remain outside the first release unless separately researched, implemented and tested. An unsupported request must stop with an explanation.
Keep reviewed sources and code separate from case inputs and outputs. An agent may read an approved source or case document without obeying instructions embedded in it. A sentence inside an invoice cannot grant permission to upload files, change tax rules or reveal another case.
Begin with stage 1The walkthrough
Study checkpoints do not certify tax correctness
Stage 1 of 11
Trace a fictional case and choose your route
Attach this guide and begin:
Help me build my own Singapore corporate tax computation agent. Use this guide, keep prompts simple and take me one step at a time.
Discover
Walk through the fictional evidence chain below. Explain what the agent prepares, what it must ask me to decide and what prevents an incomplete case from being marked ready.
Use the fictional exercise below, not a private client engagement. It illustrates the workflow to build; it is not a recording of an existing agent's execution. Keep source facts, assumed reviewer decisions and proposed implementation separate.
If you have your own existing project, add it only with permission and ask for a read-only inspection first. Have the agent distinguish what it observed, what it inferred and what it proposes. Do not rebuild functioning components just to match a fashionable framework.
Understand
I want to use [Codex or Hermes on my VPS]. Help me choose the first tax case and explain the decisions I will still need to make.
Agree on the supported company type, YA, basis period, inputs, output format, reviewer and exclusions. Decide what “done” means: a reproducible draft that reconciles and can be defended, rather than a convincing-looking tax answer.
Output
Record our chosen environment, scope and acceptance checks. Show the proposed work before changing anything.
Your checkpoint
you can explain the evidence-to-workpaper chain, identify your runtime and state who approves tax judgements. Your scope has explicit exclusions and no filing or payment step.
Stage 2 of 11
Establish the project and knowledge foundation
Discover
Inspect my selected environment. Explain how eve-inspired organisation, a Markdown second brain and Open Knowledge Format (OKF) fit this project. Do not install eve or assume any optional graph tools already exist.
Keep the roles separate. Codex on PC or Hermes on VPS executes the work. The Markdown second brain stores sources and reviewed explanations. OKF can describe knowledge and provenance in a portable format; using it requires an agreed schema and tested consumers. None of these supplies Singapore tax expertise by itself.
Codex route
Follow the eve-inspired architecture guide (opens in a new tab) to organise the local Codex project and separate development guidance from application responsibilities. Use Codex to build, run the approved scripts and review outputs. There is no separate eve runtime, adapter or deployment in this track. Keep reviewed knowledge and the deterministic calculation core reusable, and start with fictional data.
Hermes VPS route
Use Hermes as the runtime on the VPS. Do not install eve as a Hermes prerequisite. Inspect the existing Hermes version, profile, project trust, skills, effective context and terminal backend. Agree on a private, durable project area and case isolation without granting administrator access or disturbing another service.
Understand
Show me the smallest foundation that is useful now. Which optional features can wait?
Both tracks start with captured sources, a small curated wiki, text search, version history and source review. Use the Markdown second-brain guide (opens in a new tab), adapted to the selected environment. Graph tooling, embeddings, dashboards and schedulers are optional; do not claim they exist without implementation and tests.
Output
Build only the approved foundation in a new practice project. Show me where sources, reviewed knowledge, code and fictional cases belong.
Create the initial project instructions now: name the supported task, use fictional data and exclude filing/payment actions. Finalise detailed operating instructions in Stage 9 after the layers are understood. Preserve existing instructions and use a layout that fits the selected environment. The layer map is a design reference, not an installation command.
Your checkpoint
the project can retrieve one captured source and one reviewed wiki page. You can explain which parts work and which are proposed. Codex uses eve-inspired organisation without installing eve; Hermes uses its own runtime on the VPS.
Stage 3 of 11
Build the tax knowledge base before the calculator
Discover
Research the IRAS sources for our chosen case and YA. Build a source map and flag old, conflicting or incomplete guidance.
Start with the official source links below. Read the relevant sections and linked guidance, rather than trusting search snippets. Record the exact URL, title, capture date, source revision where available, applicable YA or effective period, section and reviewer. Preserve a new capture when a source changes instead of overwriting the evidence used by an earlier case.
The wiki should explain the supported rules, conditions, exceptions and questions to ask. Separate an official rule, your interpretation of it and a company's eligibility decision. A statement that a source exists is weaker than a citation to the passage supporting the exact claim.
Understand
Walk me through one rule and one exception. Which facts must a person confirm before the agent can use them?
Try the current-year rebate page as a source-reading exercise: an older announcement and a later enhancement appear on the same page. Ask which passage controls the proposed ruleset and how the review record proves that. Do not put a plausible number into a generic “current tax rate” file without year and version boundaries.
Output
Create a small reviewed wiki for our scope, with source links, year applicability and unresolved questions. Leave unreviewed rules unavailable to the calculator.
Follow the playbook's distinction between immutable source captures and maintained synthesis. Keep a curated index and append-only change log. Choose either the playbook's explicitly OKF-inspired profile or a validated current OKF profile; do not label one as the other. Designate who can approve a rule for computation.
Your checkpoint
each supported rule leads to its source passage and approved year-specific interpretation. A stale, missing, conflicting or unreviewed rule blocks a completed computation instead of becoming a guess.
Stage 4 of 11
Create the case and workpaper templates
Discover
What information and review records does our first case need? Show me the smallest useful templates.
Prepare an intake, source register, adjustment schedule, eligibility decision record, computation summary, supporting schedules, unresolved-items list and review checklist. Templates should help people notice missing facts before the calculation starts.
For each account or adjustment, retain a stable line identifier, original amount and sign, evidence reference, proposed treatment, rule reference, reviewer decision and effect on the computation. Keep unknown values distinct from zero. Mark decisions as proposed, confirmed or unresolved; a model's confidence score is not a reviewer's approval.
Understand
Use a fictional case to show how these templates prevent missing evidence, double counting and the wrong tax year.
Confirm how the accounts tie together, whether profit is before or after tax, how the accounting period maps to the selected YA, and what happens when a required schedule is absent. Do not infer start-up exemption or cash-grant eligibility from a company name or a blank field.
Output
Create the approved blank templates and one clearly fictional filled example. Explain every field I must review.
Use the synthetic example below as a starter, not a hidden answer that the agent can simply copy. Have the agent generate the fictional accounts and schedules so the supplied profit, adjustments and totals can be traced.
Your checkpoint
another student can follow one amount from fictional source evidence through a reviewed adjustment to the summary. Missing evidence stays visibly unresolved, and no template contains live client data.
Stage 5 of 11
Build small reusable skills
Discover
Break the work into reusable skills. For each skill, explain its inputs, outputs and reasons to stop.
Useful responsibilities are intake and validation, source lookup, adjustment preparation, eligibility review, computation, reconciliation, workpaper production and final review. These are responsibilities to design, not required filenames or a fixed number of agents. Start with a small set that can be tested independently.
A skill should describe when to use it, what it needs, what it may produce, which tools it may call and when a person must decide. Keep detailed references, executable scripts and reusable assets outside a giant prompt. Link them from the skill and test that the installed runtime can actually find them.
Understand
Show me how the agent handles an unfamiliar expense. What prevents it from silently treating it as deductible?
Require an explicit unresolved state. The agent can suggest a treatment with sources and questions, but it cannot manufacture the missing business facts. Human acceptance of a classification should remain attached to that case and rule version.
Output
Create and test the approved skills using fictional inputs. Show both a successful handoff and a case that correctly stops.
Have the agent inspect its runtime's actual skill format, discovery roots and instruction precedence. A copied skill folder is not proof that the runtime loaded the intended version.
Your checkpoint
each skill has a clear contract and a demonstrated stop condition. An unrecognised account or missing eligibility decision cannot quietly flow into a final number.
Stage 6 of 11
Build the deterministic calculation scripts
Discover
Separate the tax judgements from the arithmetic. What should the code calculate, and what must it receive as reviewed inputs?
The model can gather evidence and propose adjustments. The released engine should calculate from validated data and an approved ruleset. It must not invent formulas during a case or substitute a newer year's configuration because it looks similar.
Use decimal-safe arithmetic, such as Python Decimal or a justified equivalent. Define every rounding stage explicitly and verify it against the relevant official guidance or calculator. Formatting a float to two places is not a rounding policy. Keep raw values, tax adjustments, rounding adjustments and displayed values distinguishable.
Understand
Explain one calculation in ordinary language. Show the input checks, rounding choices and independent checks before you implement it.
The engine should reject invalid types, duplicate lines, unsupported years, incomplete decisions and impossible combinations. Agree on signs and the calculation order. Reconcile the accounts, adjustment schedules, allowances, chargeable income and tax result. Checking only the final subtraction is too weak.
Output
Build the approved engine and verifier, then test them against reviewed expected results. Keep changes separate from the released version.
Have the agent add a machine-readable result and run receipt recording the input, ruleset and engine versions, checks and output identity. The verifier must inspect the evidence independently of the model's prose. These are project design requirements; an OKF label or a hash alone does not implement them or validate the law.
Your checkpoint
the same approved inputs produce the same numbers without model arithmetic. A changed input, ruleset or engine is detectable, and unsupported or unresolved cases cannot receive a completed status.
Stage 7 of 11
Prepare the assets and verify the workpaper
Discover
Identify the reusable assets for the review pack. How will we prove that the workbook and written summary show the engine's actual result?
Useful assets include a blank workpaper, output schema, schedule layouts, synthetic fixtures, expected results, a source-review form and a release checklist. Inspect their licences and provenance. Keep generated workbooks and case data outside the reusable template bundle.
Use one authoritative result to populate the workbook, summary and receipt. A workbook writer must not silently create a second tax engine with different rules or rounding. If formulas are needed, define and test them deliberately.
Understand
Show me a workbook that looks correct but contains a deliberate mismatch. How do our checks catch it?
Check important cell values, formulas, cached results and totals. Recalculate in the intended spreadsheet application where required, then compare the recalculated values with the engine output. Merely writing an XLSX file or reading formulas without calculating them does not prove that the displayed numbers are current.
Output
Generate the fictional review pack, verify its numbers and render every sheet or page for inspection. List any checks the available tools could not perform.
Check labels, YA, currency, signs, page breaks, clipped text, blank formula results, hidden content, stale numbers and draft markings. If rendering or recalculation is unavailable, say so and keep the corresponding acceptance gate open.
Your checkpoint
the machine result, workbook, schedules and readable summary agree. A person has inspected the rendered output, and the pack identifies its case, ruleset, run and review state.
Stage 8 of 11
Connect the supervised workflow
Discover
Connect the layers into one supervised case workflow. Where should it pause, retry or ask me to decide?
Use a visible sequence: intake, validation, evidence retrieval, proposed adjustments, human decisions, deterministic computation, reconciliation, artifact checks and human review. Keep the actual state in durable case records so a restart does not depend on the model remembering the conversation.
A coordinator may delegate well-bounded work to specialist workers. Their reports need evidence, unresolved questions and a common case and ruleset identifier. A plan mentioning workers is not proof that any worker has been launched. Have the agent show actual tool calls, returned outputs and failures when the runtime supports delegation.
Understand
Demonstrate a missing-information pause and an interrupted run. Show how we resume without mixing cases or overwriting an approved result.
Do not let a worker approve its own consequential tax judgement. Give the final reviewer the sources and disagreements, including findings that make the result less convenient. Retries should reuse the intended case and preserve earlier runs rather than quietly replacing a reviewed artifact.
Output
Implement the approved workflow and run a fictional case end to end. Keep unresolved issues visible and stop before release if a required gate fails.
Your checkpoint
the workflow has demonstrated a normal run, a blocked run and a safe resume. It can explain what happened from saved evidence, not just from a confident chat summary.
Stage 9 of 11
Finalise the agent instructions
Discover
Inspect the effective instructions in my runtime. What should the tax agent always do, and what belongs in skills or code instead?
Refine the minimal entrypoint created in stage 2 into short operating instructions that point to the scope, wiki, skills, approved engine, case records and review gates. Keep volatile tax parameters in reviewed year-specific rules, not scattered across persona text, skill prose and workbook formulas.
The instructions should require source retrieval, distinguish facts from proposals, ask about missing inputs, treat imported documents as untrusted evidence, use only the approved calculation path and preserve the review state. “Never file” also needs an actual tool boundary: do not provide filing or payment tools to this teaching agent.
Understand
Test which instructions really take effect. What happens if a source document says to ignore the review gate or reveal another case?
Check parent instructions, local overrides and runtime-specific context. Adapt instructions to Codex or Hermes rather than assuming the same filename has the same effect everywhere. A prompt-only privacy promise is insufficient where the runtime can read every client folder.
Output
Finalise the approved instructions and test their boundaries in a fresh session. Show the effective skill and ruleset versions.
Your checkpoint
a new session follows the intended instructions, rejects malicious document directions and cannot bypass case isolation, the approved engine or human review through an available tool.
Stage 10 of 11
Test the tax cases and the installed runtime
Discover
Build a test plan that separates tax correctness, software correctness, retrieval quality and runtime safety. What evidence would disprove readiness?
Use the test matrix below. Independently reviewed expected outputs must exist before the agent generates its answer. Otherwise a test can simply preserve a mistake. Include supported cases, thresholds, missing facts, unsupported cases, stale sources, malicious inputs and artifact mismatches.
Understand
Compare our synthetic result with an independent calculation and the matching IRAS calculator. Explain every difference, including rounding.
Get the correct YA and form variant from the official IRAS calculator page (opens in a new tab). Record its filename, capture date, version or hash, supported scope and application used. Read its instructions before enabling anything. The supplied files are macro-enabled spreadsheets; use a reviewed local copy in an approved environment and do not weaken security settings to make them run. If the current tools cannot execute the workbook correctly, the instructor performs that comparison and records the result.
Output
Run the approved suite in a fresh Codex project session on PC or a fresh Hermes session on VPS. Show failures, evidence and remaining gaps before recommending release.
Test the selected track end to end in a fresh session using only documented project materials. Prove skill discovery, source retrieval, engine invocation, workpaper delivery, permissions, recovery and durable outputs. A second track needs its own acceptance run; Python tests alone do not establish that the Codex or Hermes integration works.
Your checkpoint
tax review, test results and runtime evidence are separately reported. No unresolved discrepancy is hidden behind a green test count or a claim that the agent “runs”.
Stage 11 of 11
Review the handover and maintain each tax year
Discover
Audit the finished practice project against our original scope. What is proven, what is limited and what still prevents real use?
Ask for a release pack containing the scope, approved source and rule versions, decision records, skill inventory, engine and dependency versions, synthetic fixtures, expected results, actual results, artifact checks, runtime checks and known limitations. Include plain-language instructions to open a new case, stop safely and recover a prior run.
Understand
Ask me to explain one borderline treatment and reproduce one result. Then help me decide whether this release is ready for its stated purpose.
The instructor or qualified tax reviewer should challenge the student's understanding, not simply read the agent's explanation aloud. Production acceptance also needs an authorised data-processing and access plan, retention rules, case isolation and accountable human review. A class checklist does not grant access to real client data.
Output
Prepare the handover for my review, with a clear release decision and a controlled process for future rule changes. Keep filing outside this agent.
For a new YA or changed rule, capture the new evidence, compare it with the released rules, obtain tax review, create a new version, run old and new regression cases, validate the runtime and approve the release. Preserve prior-year reproducibility. Never silently edit the rules behind an already reviewed workpaper.
Your checkpoint
you can operate and explain the supported workflow, identify its limits and demonstrate how a rule change would be reviewed and tested. The release decision belongs to an authorised human.
Reference architecture
What the Daisy reference agent separates
Daisy's owner identifies its tax-computation repository as an agent already used in the practice. The component map below comes from a read-only source inspection on 9 October 2026. No client engagement, private workpaper or repository test suite was executed for this publication. Source inspection establishes how the code is organised; it does not establish that every workflow succeeds or that every tax treatment is accepted.
| Component inspected | Responsibility visible in source | Lesson for your build |
|---|---|---|
| Structured CLI and validation/classification agents | Load intake and trial-balance records, validate the balance and classify lines before calling the orchestrator | Check inputs before calculation; retain classification warnings |
| Orchestrator and computation engine | Coordinate calculation and supporting schedules rather than ask a model to invent arithmetic | Give the engine one canonical calculation path |
| Strict YA configuration provider | Require an explicit year file and reject a mismatched YA in that file | Missing year rules must not silently become default-year rules |
| Corporate-tax summary module | Separately calculate gross tax, set-offs, rebate, cash-grant status and final payable; use Decimal for this summary | Keep eligibility decisions and rounding stages visible |
| Report generator and runtime adapter | Project the runtime result into human-readable deliverables | Rendering must not become a second tax engine |
| Agent instructions and knowledge register | Require source checks, draft labels, reviewed workpapers and an applicable IRAS calculator comparison | A workflow instruction is a review requirement, not proof the review occurred |
There are boundaries worth improving rather than copying blindly. The classifier's unmatched expense path can return a deductible classification and emits an auto-classification warning. That is not the lesson's stronger unresolved-item stop. Add and test an explicit review gate before treating an unfamiliar expense as accepted. The engine also uses floats in parts of the computation while the summary uses Decimal; do not describe the entire repository as decimal-safe without checking every conversion and rounding stage.
The main CLI selects the strict year provider, but older helper paths still contain default-year fallbacks. Inspect the actual entry point your skills invoke, not only a nearby class with a reassuring name. No code was changed in the reference repository during this review.
Use this as a reference pattern, not an installation bundle. The guide's connected wiki, OKF receipts/attester, durable case-state controls and verified Hermes port remain proposed build requirements unless separately implemented and evidenced. Keep the private repository and its client material out of the student download.
Evidence and understanding
Fictional evidence-to-workpaper walkthrough
Use the fictional company Practice Trading for the year ended 31 December 2025 (YA 2026). It has no relationship to a real client. The figures and reviewer decisions below are teaching inputs, not observed engagement evidence.
| Record | Teaching input | What the agent does | Human decision or stop |
|---|---|---|---|
| ACC-01: fictional profit and loss | Revenue 300,000; expenses 179,000, including depreciation 10,000 and an unresolved expense 2,000; profit before tax 121,000 | Check the sum and preserve the original amounts | Stop if accounts do not reconcile |
| EXP-02: fictional expense record | Amount 2,000; tax treatment initially unknown | Request purpose, supporting evidence and applicable rule; propose a treatment with sources | No automatic deductible or non-deductible default; reviewer must decide |
| DEC-02: assumed review decision | For the numerical exercise only, reviewer determines EXP-02 is non-deductible | Add back 2,000 and attach the decision reference | If the decision is withdrawn, invalidate the completed result |
| CA-01: assumed reviewed allowance schedule | Allowances total 8,000 | Deduct the schedule total, not accounting depreciation | Missing schedule, unsupported eligibility or inconsistent total blocks completion |
| ELIG-01: assumed eligibility record | Partial exemption applies; start-up exemption and cash grant do not | Select the specified YA rules and compute the conditional example | Missing eligibility decision blocks completion |
| RUN-01: draft output | Computation and schedules generated from the same inputs and decisions | Reconcile 121,000 + 10,000 + 2,000 - 8,000 = 125,000 before exemption; retain source and version references | A reviewer checks treatment, output and limits; no filing tool is provided |
The first useful result may be a question rather than a number. Remove DEC-02 and ask the agent to continue. It should identify EXP-02 as unresolved and withhold a ready-for-review completion status. It may show a clearly conditional scenario, but must not silently substitute the earlier assumed decision.
Then change ACC-01 and rerun. The schedules, computation, receipt and readable summary must all reflect the new input. Keep the previous run instead of overwriting its evidence. These are tests for the student's implementation, not claims that an agent has already passed them.
Supporting reference
The layer map
Open the layer map
These are proposed responsibilities for your practice project. Let ChatGPT select actual paths and tools after inspecting the target. The structure should remain understandable without a particular model provider.
| Layer | What it owns | Evidence that it works |
|---|---|---|
| Execution environment | Codex on PC using eve-inspired organisation, or Hermes on VPS | Actual tool versions, permissions and a fresh-session smoke test |
| Source captures | Dated official guidance and supporting source passages | Original evidence is preserved and a cited passage can be opened |
| Reviewed wiki | Scope, tax concepts, conditions, exceptions and source provenance | Known-answer and unsupported-question retrieval tests |
| Year rules | Approved parameters and interpretation for a supported YA | Reviewer, source versions and regression results |
| Templates | Intake, adjustments, decisions and review pack structure | A fictional case can be completed without losing evidence |
| Skills | Bounded procedures and stop conditions | Intended versions are loaded and handoffs are tested |
| Scripts | Validation, deterministic calculation, reconciliation and verification | Independent expected results and deliberate failures |
| Assets | Blank workpapers, schemas, fixture packs and render layouts | No stale case data; generated output matches the result |
| Flow | Ordered work, explicit states, pauses, retries and review gates | Normal, blocked and interrupted cases behave correctly |
| Instructions | Entry rules and links to the approved project materials | Fresh-session and adversarial behaviour checks |
| Tool boundary | Approved invocation, case isolation and private output delivery in the selected track | End-to-end checks in Codex or Hermes |
Keep evidence, code and case records distinct. A compact repository might contain source captures, a wiki, rules, templates, skills, scripts, assets and tests, with private case storage outside the distributable teaching bundle. That is an organisational suggestion, not a required directory tree.
Evidence and understanding
Synthetic case for the first calculation
This is a fictional arithmetic exercise for YA 2026. All amounts are SGD. The instructor must confirm the rule interpretation before accepting it as a regression fixture. Do not use it to infer eligibility for an actual company.
Assume a trading company with an ordinary 12-month accounting and basis period from 1 January to 31 December 2025. Its reviewed accounts show profit before tax of 121,000. This already includes depreciation of 10,000 and an expense of 2,000 that the reviewer has expressly determined is non-deductible. A reviewed capital-allowance schedule supports 8,000. Assume no other adjustments, income streams, losses, donations, credits or tax deducted at source. Partial tax exemption applies; start-up exemption does not. The company is not eligible for the cash grant.
Under those explicit assumptions:
| Step | Expected amount in SGD |
|---|---|
| Profit before tax | 121,000 |
| Add back depreciation | 10,000 |
| Add back reviewed non-deductible expense | 2,000 |
| Adjusted profit | 133,000 |
| Deduct reviewed capital allowances | 8,000 |
| Chargeable income before exemption | 125,000 |
| Partial exemption of 7,500 plus 57,500 | 65,000 |
| Chargeable income after exemption | 60,000 |
| Gross tax at 17 percent | 10,200 |
| YA 2026 rebate under the stated assumptions | 5,100 |
| Net tax payable in this exercise | 5,100 |
The exemption arithmetic uses the YA 2020 onwards bands illustrated by IRAS: 75% on the first 10,000 and 50% on the next 190,000 of normal chargeable income. IRAS exemption examples (opens in a new tab)
The rate and current-year rebate are checked against the IRAS rates and rebate page (opens in a new tab). This case deliberately avoids a rounding boundary and cash-grant interaction; separate tests must cover them. It also assumes, rather than proves, the expense treatment and allowance eligibility. No IRAS spreadsheet was executed to certify these figures when this guide was written.
Create this fictional case, calculate it independently and show where the evidence, human decisions and arithmetic are kept separate.
For a second regression fixture, keep gross tax of 10,200 but assume the reviewer confirms cash-grant eligibility. The tax rebate becomes 3,100 and net tax payable 7,100; record the 2,000 cash grant separately. Eligibility requires the relevant active-company and 2025 local-employee conditions, not just evidence that cash arrived. IRAS rebate examples (opens in a new tab)
Now remove the reviewer's decision on the 2,000 expense. A useful agent asks for the decision and blocks completion; it does not reuse the earlier answer as if the missing fact were still established. Then change one input and require every affected schedule, number and receipt to change consistently.
Supporting reference
Tax source and year reference
Open tax source and year reference
Publication review, 9 October 2026: the computation approach, expense conditions, depreciation/allowance distinction and YA 2026 rate, partial exemption and rebate example were checked against the cited IRAS pages. This is not a complete tax rulebook. Re-open sources during your build and record the version you actually use; the official calculator has not been executed for this lesson.
- IRAS preparing a tax computation (opens in a new tab): use its computation approach and supporting schedules to define the review pack
- IRAS basic company tax guide (opens in a new tab): establish the basis period and YA, including cases where the first accounts cover more than a year
- IRAS business expenses (opens in a new tab): expense deductibility depends on conditions including income-producing purpose, incurred liability, revenue character and statutory restrictions; a label alone is insufficient
- IRAS capital allowances (opens in a new tab): research the particular asset, available election, acquisition period and supporting schedule
- IRAS rates and exemptions (opens in a new tab): the corporate rate is 17%; the updated YA 2026 rebate is 50%, the qualifying cash grant is 2,000 and the combined maximum benefit is 40,000. The earlier announcement remains on the page. Grant eligibility and its interaction with the rebate require separate review; do not simply subtract both amounts from tax
- IRAS official calculators (opens in a new tab): select the Basic Corporate Income Tax Calculator for the matching YA and Form C-S or Form C. IRAS describes it as designed for trading companies; it does not cover every possible tax case
- IRAS return types and eligibility (opens in a new tab): choosing a workpaper format does not establish eligibility for a particular return
Use current-year guidance for current-year rules and preserved historical guidance for an old case. The newest page is not automatically the correct rule for every YA. If evidence conflicts, preserve both versions, identify the affected claims and ask for a qualified decision before releasing the ruleset.
Evidence and understanding
Test matrix for human acceptance
Record the fixture, intended rule version, independently approved expected outcome, actual outcome, evidence and reviewer for each test. “Expected outcome” can be a required stop or question rather than a tax number.
| Test | What must be demonstrated |
|---|---|
| First supported case | Every source, adjustment and total reconciles with the reviewed synthetic reference |
| Eligibility uncertainty | Missing exemption or grant facts produce questions and block completion |
| Unknown account | No automatic deductible fallback; the unresolved item reaches human review |
| Unsupported scope | Wrong entity, unsupported YA or an excluded tax matter stops clearly |
| Year change | A prior-year case continues to use its approved historical rules |
| Changed official guidance | A new capture and rule proposal do not silently change released computations |
| Threshold boundaries | Values just below, at and above each relevant band or cap match reviewed expectations |
| Rounding boundaries | Fractional inputs and intermediate rounding match the agreed authority and displayed values |
| Source retrieval | Correct passages are returned; irrelevant, contradictory and unsupported questions are identified |
| Input integrity | Duplicate lines, missing schedules, wrong signs and mismatched totals are detected |
| Reconciliation | Accounts, adjustments, allowances, exemptions, tax and outputs agree end to end |
| Receipt integrity | A changed input, engine, rule or output invalidates the corresponding verification |
| Artifact drift | Wrong workbook cells, stale cached values, changed formulas and mismatched summaries are caught |
| Prompt injection | A malicious source cannot alter rules, read another case or trigger outside delivery |
| Case isolation | Case A cannot see Case B through files, memory, search or conversation history |
| Interrupted run | Resume preserves the right case and does not overwrite an approved result |
| Fresh runtime | Installed skills, engine, storage and delivery work without development-session memory |
| Portability | Each claimed runtime reproduces the same approved result and passes its own boundary checks |
| Human explanation | The student can defend one treatment and reproduce one number without relying on the agent's confidence |
Do not use broad numerical tolerances to hide unexplained differences. Match the approved rounding policy and account explicitly for any expected presentation difference. A high pass count can coexist with a wrong tax interpretation, missing failure paths or a workbook that disagrees with its manifest.
Supporting reference
Technical reference for the agent and instructor
Open technical reference for the agent and instructor
Knowledge and rule releases
Prefer primary IRAS material, with legislation or specialist review where required. A proposed project source record should identify the passage, captured file, URL, date, applicable period, interpretation, review status and affected rule IDs. Those are local design requirements. Validate any claimed strict OKF fields against the chosen specification version instead of inventing a standard.
The current OKF specification (opens in a new tab) describes Markdown knowledge with YAML metadata and an Attested Computation concept. It distinguishes an executor and receipt from a deterministic, non-LLM attester. In this project, implement and test the corresponding engine and verifier before claiming attested computation. A provenance record makes a result inspectable; it does not establish legal correctness.
Keep the reviewed wiki and tax rules versioned. Limit changes to source ingestion and proposed updates until the appropriate reviewer approves a release. A search index is disposable; source evidence and reviewed pages are not. Plain text search is adequate to start. Evaluate retrieval before adding embeddings or graph traversal.
Case and computation contracts
Use explicit schemas for the case identity, jurisdiction, entity type, YA, period, currency, source references, account lines, adjustments, eligibility decisions, allowances and unresolved items. Decimal amounts should survive every conversion unchanged. Reject an unknown field when it could conceal a mis-spelled tax input; explain validation errors in terms the student can correct.
A proposed run receipt should bind the case inputs, decision record, ruleset, engine and dependency versions, executed entrypoint, result and generated artifacts. Store actual identifiers or hashes, execution status and checks. Keep secret values and unnecessary personal data out. A verifier should reject changed or missing evidence, not rely on the model saying “verified”.
Test that the runtime invokes the released calculation path and cannot silently edit it during an ordinary case. Protect reviewed code and knowledge with actual filesystem or tool controls where possible. Use bounded execution, resource limits and an explicit output directory.
Reconciliation and artifacts
Define each invariant precisely. Source account totals should agree with the intake and accounts; each adjustment should have one treatment and traceable source; schedule totals should match the engine; outputs should match the same verified run. Where a relationship does not hold, show the difference and stop rather than inserting a balancing amount.
Check workbook formulas and actual calculated values separately. Reopening a generated workbook is not the same as recalculating it. Record which application and version performed calculation and rendering. Preserve draft status when a required check is unavailable.
For a focused intermediate-rounding test, the IRAS exemption examples (opens in a new tab), pages 6–7, show normal chargeable income of 61,765 producing an exempt amount of 33,383 and a remainder of 28,382. Ask the tax reviewer to confirm the applicable rounding rule before implementing it. This isolates the rounding lesson; it does not add the surrounding concessionary-loss scenario to the first release.
Operations and privacy
Keep each case's files, retrieval scope and runtime history isolated. Verify who can read outputs and what survives a restart. Do not store detailed client tax evidence in broad personal memory. Do not publish the case bundle, expose a management dashboard to the internet or add an unauthorised delivery channel as a convenience.
A useful first release has no filing, payment or live accounting write tools. If a later project adds integration, review its data destinations, permissions and approval controls separately. Building a calculator does not authorise sharing client data with model providers, messaging services or tax portals.
Supporting reference
Portability after the first route works
Open portability after the first route works
A reusable core comprises reviewed knowledge, year-specific rules, schemas, deterministic code, templates, assets and tests. A runtime adapter handles skill loading, effective instructions, tool invocation, filesystem boundaries, case state and artifact delivery. Copying the same SKILL.md file does not prove identical behaviour.
Codex on PC with eve-inspired architecture
Work in the local Codex project and follow the architecture guide (opens in a new tab) without installing eve. Check applicable project instructions and overrides, discovered skills, tool access and approvals. Invoke the approved calculation engine through a narrow, tested path and verify a complete fictional case in a fresh Codex session. Reusing the project structure does not prove skills load or permissions are enforced.
Hermes Agent on the VPS
Inspect the installed Hermes release, profile and project context. Prove skill discovery, a private durable case area, non-root execution and the selected isolated terminal backend. Keep the existing permitted-user restrictions on any messaging channel. The dashboard is an operator surface, not automatically a client tax portal. See the official skills (opens in a new tab), context files (opens in a new tab) and security documentation (opens in a new tab).
NanoClaw as an optional later port
Check the actual repository, version and container setup. Distinguish host setup skills from skills visible inside the case agent's container. Verify mounts, credential boundaries and group/session storage; a new chat may still share a group's files or memory. Do not assume an older fork behaves like current upstream. Start from the current repository (opens in a new tab) and its security model (opens in a new tab).
OpenClaw as an optional later port
Inspect skill precedence, workspace instructions, session routing and the actual sandbox configuration. A workspace alone is not an isolation boundary. Verify approved read-only knowledge and code access, one case's writable outputs and the absence of unneeded host or elevated tools. See the official skills (opens in a new tab), workspace (opens in a new tab) and sandboxing guidance (opens in a new tab).
For any port, run the same reviewed fixtures in a clean installed runtime and compare results and failure behaviour. Say “portable to this tested version” only after recording the evidence. Otherwise call it a proposed adapter.
Evidence and understanding
Keep the conversation simple
Use a short prompt when you get stuck, then allow the answer to change the plan.
Explain that in ordinary language and show me one example.
Which facts came from a source, which are assumptions and which need my decision?
What evidence would show that this answer is wrong?
Stop building for a moment. Help me understand this decision.
Show the smallest change that fixes this failed test, then run the relevant tests again.
What did you actually test, and what is still only proposed?
Prepare the next useful output from the decisions we have agreed. Keep unresolved points visible.
Evidence and understanding
Final student check
You are ready to present the practice project when you can:
- Explain Codex on PC, Hermes on VPS, eve-inspired organisation, the Markdown second brain, OKF, skills and deterministic calculation
- Open a source passage and show how its reviewed interpretation enters a particular year's rules
- Explain a tax judgement separately from the arithmetic that follows it
- Trace a fictional account through its adjustment, schedule, calculation and rendered workpaper
- Demonstrate a correct refusal or pause for an unknown, unsupported or incomplete case
- Show the fresh-runtime evidence, including skill discovery, privacy boundaries and recovery
- Reproduce the worked calculation and explain every difference from the independent reference
- Identify exactly who reviewed the rules, expected results and final pack
- Describe a controlled year update that preserves old results and never files automatically
The learning goal is an agent you can examine, challenge and improve. A polished workpaper is useful only when its evidence and decisions can withstand review.
Supporting reference
Instructor notes and sources
Open instructor notes and sources
This lesson uses DUO version 0.2 (opens in a new tab), the Markdown second brain (opens in a new tab) and eve-inspired architecture (opens in a new tab) for the Codex-on-PC track. The Daisy component map is a sanitized read-only source inspection; the numerical walkthrough is fictional, not a client case or executed reference-agent run. Wiki/OKF additions are teaching proposals unless separately evidenced. Hermes does not require eve.
Treat the eleven stages as a route through a build, with permission to loop back. Assess the student's decisions, source use, ability to spot uncertainty and evidence of safe execution, as well as the resulting artifact. Do not score success by prompt length, number of agents, framework names or test count alone.
The synthetic computation, architecture, proposed contracts, test matrix and teaching prompts were prepared for this guide. They are not an IRAS-endorsed system or a substitute for professional tax advice. Official links are cited beside the relevant claims. Runtime documentation and moving source branches can change; record the exact versions used by the student's project.