AI features: questions for a tax agent and counsel (together)

Prepared 2026-10-05 from the repository at bc0c833c. Not sent. This closes the “counsel and a tax agent have read section 6” condition in docs/ROADMAP.md Phase 6 (AI) and owner decisions D2 and D3 of docs/superpowers/specs/2026-10-03-ai-features-design.md (spec), section 6.

What is NOT claimed. The product asserts no legal conclusion. spec section 6 says it is “written to be checked against the Act, not to assert compliance”, and nothing in it has been reviewed by counsel or a tax agent. Statements below about the Personal Data Protection Act 2010 (and its amendments) are the author’s recollection, not read from the Act; the Income Tax Act 1967 provisions are cited exactly as the repository cites them, and not independently re-read. “Until answered” is what the software does now, which is the engineering team’s choice, not advice.

What the spec actually cites (read exactly). The “11A.1” in the spec is not PDPA and not a section of the Income Tax Act: it is section 11A.1 of the architecture spec (2026-09-20-erp-architecture-design.md), which cites ITA 1967 s.82(8): “records relating to a business in Malaysia shall be kept and retained in Malaysia”, and from it derives the rule “No offshore processor may touch record data.” Section 11A.2 cites ITA 1967 s.82A (records retained at least seven years from the end of the year of assessment) and PR 5/2000 (electronic records readily convertible to readable form). The architecture spec’s own caveat: “Not reviewed by a tax agent … re-verify before relying on any date.” The AI spec cites no PDPA section number at all; it refers to “the Personal Data Protection Act 2010 (Malaysia) as understood” and notes the amendments post-date the author’s sources.

1. What Tier 0 does today (built, merged to main)

Tier 0 means deterministic code inside the deployment. No language model is reachable: the run record’s provider column is constrained to none, and INSIGHT_ENABLED (in .env.example) can only switch features off. Nothing leaves the process.

• Claim flags (rules R1, R2, R3, R5, R6, R7, version claimflags/v1). Read an employee’s expense claim lines and their own history and the organization’s history by category: duplicate receipt details, splitting under an approval threshold, round-number clusters, amount above the claimant’s own 95th percentile or the organization’s 99th, first claim from a supplier above a floor. Each flag stores the numbers that triggered it (aggregates for comparisons with colleagues, never a colleague’s line) and a translated reason. Flags are advisory: they gate and route nothing and never change a claim. The claimant sees nothing by default; approvers with insight.flags.read see them. The ids of flags an approver could see at the moment of decision are written to the audit trail.
• Spend forecast. Seasonal or trailing-mean forecast with a back-tested range, from posted ledger actuals by category and project.
• Natural-language report search. A deterministic matcher over report names, periods and the organization’s account and analytic names. Output is a proposal that passed the ordinary report validation, or a question. Runs nothing. Audited by a hash and length of the question, never the words.
• Switches. Per feature per organization: off (default for everyone), shadow (analysis runs and stores results; only administrators and auditors see them), live (approvers see flags). Moving a mode is an administrator action recorded in the audit log with before and after. Shown flags and runs are kept, by design, for the claim’s retention window and cannot be deleted by the application.
• Hosting. Test deployments are in Singapore with made-up data; the intended customer deployment is Malaysian (RUNBOOK section 1).

2. What Tier 1 and Tier 2 would send (not built, not offered)

Correction to the request’s wording: in the spec Tier 1 is a locally run model and nothing leaves; only Tier 2 is an external model. Only natural-language report search can use either (spec 4.3). Neither exists; blocked on D2 and D3.

What a Tier 2 prompt would contain (spec 4.4, 6.2): the user’s typed question, a catalog of valid report keys with parameter names, the organization’s account and project names and codes needed to resolve the question (no balances), today’s date and fiscal-year boundaries, and the output schema. Not sent: amounts, ledger rows, claim text, receipt or OCR text, person names beyond catalog entries the user may already see. A masking step would replace email-, phone-, long-digit- and NRIC-shaped strings in the question. The reply is validated outside the model against a closed schema (a report that exists, parameters that pass the allow-list); no tool use, one call per question. The payload would not be stored, only its hash and the redaction manifest (D9).

The spec’s own admitted weakness: a project named after an individual client, or a question naming an employee, is personal data the masking cannot reliably catch, and “that is an argument about the prompt’s content, not a legal conclusion”.

3. Questions

Each: Now, Answer changes, Reply (yes/no or short answer).

Q1. Does a Tier 2 prompt as specified breach “no offshore processor may touch record data” (ITA s.82(8) as the architecture spec reads it)? Is an account or project name, or a free-typed question, a “record” for s.82(8)? Can a prompt that carries no ledger figures be sent to a processor outside Malaysia?

• Now: no external call is possible.
• Reply: yes/no; if no, the conditions (region, contract).
• Answer changes: D3 option (a) never, (b) Malaysian region with written terms only, (c) any with opt-in (spec recommends never (c)).
• Until answered: Tier 2 not built.

Q2. Is s.82(8) the right and complete source for the offshore rule, and does the test deployment outside Malaysia matter? The spec reads s.82(8) as binding on deployment, including backups. Test hosting is in Singapore with made-up data.

• Reply: reading correct, yes/no; is made-up test data outside the rule, yes/no.
• Answer changes: the runbook wording; when real data may touch the test host.

Q3. PDPA position of Tier 0 claim flags. Rules compare each claimant to their own history and to the organization (R5, R7). Is that profiling of employees that needs (a) a notice to employees, (b) a lawful basis recorded, (c) a right to see or correct a flag? Today the claimant sees nothing (D4, to avoid teaching the thresholds).

• Now: shadow or live per organization; claimant sees no flags; approvers do.
• Reply: yes/no per (a), (b), (c); and whether hiding flags from the claimant is itself a problem.
• Answer changes: a notice text, a claimant-visible view, or a per-organization employee-notice acknowledgement before shadow (none exists today).
• Until answered: no real employee data should be analysed; modes default off.

Q4. Retention and erasure of flags. Flags shown to an approver, runs, and feedback follow the claim’s seven-year window (ITA s.82A as cited) and the application cannot delete them. Feedback free-text notes are the reviewer’s personal data. The spec calls flags “derived, advisory data, not statutory records” yet retains them as if they were.

• Reply: (a) is a flag a record needing seven years, or may it be deleted on request, short answer; (b) may a data-subject erasure request be refused while the clock runs, yes/no.
• Answer changes: retention constants, the delete path for flags and notes.
• Until answered: seven years, no delete.

Q5. Cross-organization data. Statistics are per organization only; no pooled model, no shared threshold learned from other tenants, no training. Confirm this is sufficient to avoid a separate consent.

• Reply: yes/no.

Q6. Provider terms (applies only if Tier 2 is ever built). List what the contract must say: no training on customer data, retention period, deletion on request, sub-processors, region, breach notification, and what we must record (provider, region, contract reference as an operator attestation).

• Answer changes: required configuration fields and the consent screen text.

Q7. Consent and who gives it. Tier 2 would be opt-in per organization by a named administrator, timestamped, revocable, default off, never set by migration or seed. Is an administrator’s click enough, or does each end user whose typed question is sent need notice?

• Reply: short answer.
• Answer changes: consent screen wording; a per-user notice.

4. What must be true: proposed conditions for the two gates (for you to correct)

Before an organization moves a feature from shadow to live (today an administrator’s call, D6; no numeric floor, no minimum sample, no prompt; the settings write is audited but nothing checks the evaluation view was opened):

1. Q3 answered, and any employee notice it requires has been given for that organization.
2. The administrator has read the evaluation view (precision per rule, sample size, dismissals).
3. Claim flags: a stated minimum sample, set by the owner after the first shadow period.
4. Retention answer (Q4) built. Which of these are necessary, and which sufficient?

Before any external model is enabled:

1. Q1, Q2, Q6 and Q7 answered in writing and built.
2. A provider with the required region and terms exists and is recorded in configuration (INSIGHT_LLM_PROVIDER is not built; today there is no such setting).
3. The per-organization consent record and the global switch (none by default) exist and the canary test (claim text never appears in a prompt) passes.
4. Owner decision D3 moved from (a). Which are missing?

5. What each answer changes in the repository

Answer	Change	Size
Employee notice required before shadow	per-organization acknowledgement, text in three languages	small to medium
Claimant must see their flags	new view, D4 reversed	medium
Flags deletable or shorter retention	constants, delete path, retention test	small to medium
Tier 2 permitted in a Malaysian region	provider adapter, consent screen, redaction, budgets (plan task 8)	large, new work
Tier 2 never	nothing; Tier 0 stays	none
Different offshore reading of s.82(8)	runbook and test-host rules	docs

6. Spec points to carry

• spec 6.2 says “§11A.1 says no offshore processor may touch record data”; the section is the architecture spec’s, citing ITA s.82(8), not the PDPA. Do not describe it to counsel as a PDPA rule.
• spec 1.3 lists an external_llm_consent column on insight_org_setting; the built table has none (no consent flow exists).
• spec 5.1 says moving to live “requires” a minimum labelled sample as a soft prompt; the roadmap records that no minimum was set and no prompt was built.
• spec 6.4 calls flags “not statutory records” but applies the statutory retention window and forbids deletion.