Skip to main content

Trust centre

Every control here exists in code.

Not policy language, and not a roadmap. This page names the specific mechanism for each control, so a reviewer can check it rather than take it.

The safety promise

Exact or abstain

An answer ships only when it is verifiably certain — otherwise it asks a specific question or escalates to a human, with a stated reason.

Numbers are calculated exactly from official rates. Legal claims must be backed by a cited authority in official sources. When facts are missing, the jurisdiction or year is unsupported, sources are stale or authorities conflict, the assistant asks for facts, refuses the exact conclusion, or routes to a human. It never answers a high-risk tax question from general model knowledge.

Every high-risk answer displays

JurisdictionTax yearCoverage statusLaw-as-ofSource versionCitationsClaim-by-claim supportAssumptionsVerification status

Tenancy and access

Isolation is structural, not a filter somebody remembered.

Every workspace is isolated by design, so a query that forgot to filter by tenant is not a bug that can be written. Each tenant's documents are searched separately too, so one client's data cannot surface in another's answers.

  • Structural tenant isolation

    Every tenant record is scoped to its workspace and site by design, so queries always filter by tenant. Deletions cascade, so no orphaned record survives a deletion.

  • Isolated document search

    Each tenant's documents are searched separately. A search never crosses a tenant boundary.

  • Per-site permission enforcement

    One shared permission layer checks every request, rather than each screen deciding for itself.

  • Staff-only admin surfaces

    Internal operations tools require staff access. They are not reachable with a tenant role.

  • 8-role RBAC matrix

    One role-by-permission matrix, declared once and shown in the admin — not permission checks scattered through the code.

Roles

Eight roles, declared once.

One role-by-permission matrix, declared once and shown in the admin — rather than permission checks scattered through the code, where one of them is always out of date.

The eight TaxOrch roles against the permission areas the reference publishes. Each cell states whether the role owns the area, reads it, or whether the area is not part of that role.
RoleClient tax dataBookkeeping entryCase and return draftingCase finalisationTenant administrationSources, imports, releasesStaff onlyModel routes, prompt versionsStaff onlyEvidence and audit trail
Taxpayer / clientThe end customer whose data it isOwns—Not part of this role—Not part of this role—Not part of this role—Not part of this role—Not part of this role—Not part of this role—Not part of this role
BookkeeperDay-to-day data entry and categorisationReadsOwns—Not part of this role—Not part of this role—Not part of this role—Not part of this role—Not part of this role—Not part of this role
PreparerBuilds the case and the return draftReadsReadsOwns—Not part of this role—Not part of this role—Not part of this role—Not part of this role—Not part of this role
ReviewerSigns off; required before finalisationReadsReadsReadsOwns—Not part of this role—Not part of this role—Not part of this role—Not part of this role
AdminTenant administration—Not part of this role—Not part of this role—Not part of this role—Not part of this roleOwns—Not part of this role—Not part of this role—Not part of this role
Content operatorManages sources, imports and releases—Not part of this role—Not part of this role—Not part of this role—Not part of this role—Not part of this roleOwns—Not part of this role—Not part of this role
Model operatorManages product configuration—Not part of this role—Not part of this role—Not part of this role—Not part of this role—Not part of this role—Not part of this roleOwns—Not part of this role
AuditorRead-only access to evidence and audit trails—Not part of this role—Not part of this role—Not part of this role—Not part of this role—Not part of this role—Not part of this role—Not part of this roleReads
  • ReviewerA reviewer must be assigned before a case can be finalised. Finalised cases are immutable; reopening is explicit and audited.
  • Content operatorA staff-only surface. Promotion is immutable and rollback restores the prior release and its index.
  • Model operatorA staff-only surface. Model route changes are written to the audit log.
  • AuditorRead-only by definition. The role has no write path anywhere in the product.

The authoritative grid is the role matrix shown in the product’s admin. This table renders the eight role definitions it declares; a cell marked as not part of a role is a statement about that definition, not a measurement of a live deployment.

Audit trail

Every AI interaction, with the versions it ran on.

Actor, tenant, event type and recorded versions. Refusals are logged separately with their reason, which makes refusal rate on covered questions a measurable, gated metric rather than an anecdote — and a CLI command exports the log for durable retention.

Monthly cryptographic audit proofs with SHA-256 verification.

Logged actions
  • calculate
  • grounded answer
  • source update
  • source rollback
  • configuration change
  • model route change
  • case finalize
  • case reopen
  • gate waiver
  • deletion
  • document download
  • audit proof generation
  • ledger resync
  • anomaly resolution
  • page proposal deployment
  • bookkeeper chat
  • privacy export
Privacy

The safe setting is the one you get without asking.

The data-use opt-out is on by default, sensitive extracts are encrypted at rest, and taxpayer identifiers are removed before any text leaves your workspace.

  • The data-use opt-out is on by default

    Your data is never used beyond your own work without an explicit opt-in. The safe setting is the one you get without asking for it.

  • Encryption at rest for sensitive extracts

    Full SSNs and bookkeeper conversation content are encrypted. Stored display fields keep only masked values.

  • Never logged

    Raw document contents, sensitive figures and conversation content are never written to logs. Bookkeeper message content is not visible to internal administration tools either.

  • Identifier redaction

    Taxpayer identifiers are redacted from processing and from support surfaces before anyone sees them.

  • Personal data never leaves your workspace

    Personal identifiers are removed before any text is used beyond your own workspace.

  • Seven-year default retention

    Configurable, with a seven-year default for tax documents. A retention-eligibility report lists what is due for deletion.

  • Legal hold

    A hold flag blocks deletion for records under dispute or audit, overriding the retention schedule.

  • Per-tenant data export

    A privacy export of all tax data for a tenant. Privacy requests are modelled and tracked to completion.

  • Secure deletion, audit-logged

    An explicit deletion path, with the deletion itself written to the audit log. Access to sensitive documents is recorded.

  • Licensed sources only

    Every source carries its publisher, licence, jurisdiction, version and collection date. Sources with unknown or restricted rights are not used.

Security

Named threats, named controls.

Each row is a specific attack and the specific mechanism that stops it. A control described only by its category is a control nobody can check.

  • SSRF via source fetching

    Public HTTP and HTTPS only. Localhost, loopback, link-local, reserved ranges and cloud metadata endpoints are blocked, and the guard fails closed on DNS resolution failure. It applies to every source fetch.

  • Prompt injection

    Uploaded and source text is sanitised — “ignore previous instructions” and spoofed system or assistant lines are neutralised. System and legal controls always win, and bypass attempts are logged.

  • Malware in uploads

    ClamAV scanning, with a fail-closed option.

  • Oversized or malicious uploads

    Maximum upload bytes, maximum image dimension, and OCR timeouts.

  • Metadata leakage from images

    EXIF stripping on upload.

  • Abuse and cost exhaustion

    Throttling on AI generation and question endpoints, with a configurable free-question limit.

  • Unsigned exports

    Audit-proof manifests are HMAC-signed.

  • Tampered ledger

    Entries are hash-chained per tenant, and a CLI command validates the whole chain.

  • Tampered audit proof

    A SHA-256 is recorded at generation; verification re-reads the stored PDF and compares in constant time.

  • Unsafe model output

    JSON is validated and repaired with bounded retries. Unrepairable output fails safe and is never executed.

  • Internal leakage

    Every public page is checked by a leakage guard so that no internal instructions or secrets are published.

AI governance

Some things autonomy settings can never reach.

Filing preparation and payment steps always require explicit human approval, and no autonomy level covers them. Approving a filing step produces a preview — never an external submission.

  • AI kill switch

    A per-tenant switch that disables the AI path entirely.

  • Workflow autonomy level

    Per-tenant control over what the agentic layer may do unattended.

  • Permanent high-impact exclusion

    Filing preparation and payment steps always require explicit human approval. Autonomy settings can never cover them, and approving a filing step produces a preview — never an external submission.

  • Escalation confidence threshold

    A per-tenant threshold below which answers escalate to a human, alongside review and auto-approve thresholds.

  • Production mode enforcement

    Grounding enforcement cannot be disabled per request.

  • Graduated capability disabling

    When the system is not ready, high-risk workflows are disabled while low-risk help stays available.

  • Preview-only ledger suggestions

    Nothing auto-posts to the books. Accept or reject is always a human decision.

  • Human approval before changes

    Changes to how answers are produced are approved by a person before release.

Operating model

What happens between releases.

Sources carry an update cadence and stale ones block release freshness. A reviewer must be assigned before a case can be finalised, and a finalised case is immutable — reopening is explicit and audited.

  • Update cadence per source

    Each registered source carries an update cadence. Stale sources surface in source health and block release freshness.

  • Reviewer responsibilities

    A reviewer must be assigned before a case can be finalised. Finalised cases are immutable, reopening is explicit and audited, and memos and notices use only verified claims.

  • Release promotion policy

    Import, validate (gated), promote (immutable), index. A bad release cannot become active, and rollback restores the prior release and its index.

  • Law-change SLA

    Critical law change, calculator update, evaluation rerun, release. Overdue countries and topics surface in the expert review queue.

  • Country onboarding

    Register the official sources, add the rates and calculator, start at beta, check against known official answers, then release.

  • Support escalation

    Low-risk help stays available even when the system is not ready. High-risk advice is gated off, and uncertain cases route to a tax professional.

Disclaimers

The four statements, unedited.

Reproduced exactly as they appear in the product. They are not softened for a marketing page, because the version a customer sees in the product is the version that matters.

  • Decision support, not professional advice

    TaxOrch outputs are decision support and are not a substitute for advice from a qualified tax professional. Review all outputs before filing.

  • Coverage-limited exactness

    Exact results apply only within TaxOrch's declared coverage. Outside that coverage the assistant will tell you what it cannot answer and why.

  • TaxOrch does not file

    TaxOrch produces draft packages marked "not filed". It does not submit returns to any tax authority and does not execute payments. Any filing-preparation or payment step requires explicit human approval and produces a preview only.

  • Beta jurisdictions

    Jurisdictions marked beta give exact results but have limited depth. Professional review is recommended.

Documents

Take it with you.

Each document is generated from the control set on this page rather than from a policy template, so it cannot drift away from the system it describes. Summaries are open; the three a procurement process would expect to be attributable ask who you are.

No certification is claimedNothing on this site displays a compliance badge, because none is held.
  • Security posture summary

    Open

    Isolation, access control, encryption, upload scanning, SSRF, throttling.

    TXT · built on request
  • Privacy posture

    Open

    Retention, deletion, legal hold, export, redaction, the data-use opt-out.

    TXT · built on request
  • AI governance statement

    Open

    Exact or abstain, human-in-the-loop, audit trace, retention, opt-out.

    TXT · built on request
  • Data-processing description

    Details required

    What is processed, where, and by which components.

    TXT · built on request
  • Incident process

    Details required

    What happens when an answer is challenged.

    TXT · built on request
  • DPA template

    Details required

    Data-processing agreement content, ready for your counsel to review.

    TXT · built on request

Every document is generated from the control set this page describes, not from a policy template. None of them asserts a compliance certification, because none is held — and a trust page that would overstate that cannot be trusted about anything else on it.

Before you commit anything

The questions a review board asks, answered in public.

Tenant isolation, the audit trail, the the data-use opt-out and what happens to your data if you leave. Where something is not certified or not published, the page says so rather than implying otherwise.

Decision support, not tax advice. A professional reviews before anything is filed.