×

Tax

Challenges

  • Rules vary across jurisdictions, filing periods, entities, and transaction types.
  • Exemptions and credits depend on detailed conditions and supporting evidence.
  • Nexus determinations combine thresholds with changing business activity.
  • Rule updates can alter calculations and prior decision assumptions.

Problems We Solve

  • Rule Mapping Connect definitions, jurisdictions, periods, and dependencies.
  • Eligibility Checking Evaluate exemptions and credits against explicit criteria.
  • Scenario Calculation Compare outcomes under representative rule combinations.
  • Consistency Review Detect conflicting treatments and missing evidence.
  • Decision Records Capture the rule path behind each placeholder result.

Domain portfolio

Application patterns

Compare two formal-assurance approaches, then explore the domain workflows as interactive state machines.

The Tax domain concerns jurisdiction, nexus, entity and transaction classification, filing periods, exemptions, credits, thresholds, supporting evidence, and the effect of rule changes. These applications use verified readback to make a tax professional’s proposed rule statement structurally explicit and reviewable. They support rule mapping, eligibility checking, scenario comparison, consistency review, and decision records; they do not determine authoritative tax treatment, validate source data, calculate a return, establish that evidence is sufficient, or replace professional judgment and required sign-off.
01 Indirect-tax nexus and registration assessment workbench Explore pattern

System/use case

A nexus workbench helps indirect-tax teams articulate when a combination of entity activity, transaction measures, presence indicators, jurisdiction, and period should trigger an assessment or registration-review workflow. Accepted propositions serve as controlled workpaper assertions linked to a source and period, not as autonomous conclusions that an obligation exists.

Operational setting

The workbench sits between enterprise resource planning, billing, order, location, legal-entity, and tax compliance systems. A tax data mart aggregates transactions using approved sourcing and entity mappings. Tax professionals select the jurisdiction, tax type, filing period, authority hierarchy, threshold version, and known exclusions represented by a curated setup. Registration status and filing obligations remain in the tax compliance system of record.

Decision/claim boundary

The checked claim is limited to a setup-scoped relationship such as: activity meeting a selected threshold plus a qualifying presence condition entails nexus review. It does not establish that transactions were sourced correctly, a threshold value is current, activities are attributable to the entity, nexus exists as a matter of law, registration is required, or tax is due. The responsible tax professional, with legal advice where appropriate, owns jurisdictional interpretation, effective-date selection, factual assumptions, and the final position.

Candidate checked statements

Illustrative controlled-English propositions for a future nexus setup could include:

  • “For every entity and filing period, if in-scope activity meets the approved jurisdictional threshold, the entity requires nexus review for that period.”
  • “If a qualifying exclusion applies to the measured activity, that activity is not included in the selected threshold test.”
  • “If nexus is approved and no active registration is recorded, a registration task is required.”

These examples do not claim that present setups implement the terms or that a specific entity meets any threshold.

Example architecture

Source systems publish transactions, customer and service locations, entity ownership, and presence signals to a governed tax data platform. A sourcing and classification layer produces versioned measures with lineage and reconciliation status. A tax-rule registry holds practitioner-curated definitions, threshold parameters, effective periods, inclusions, and exclusions. FF Scribe receives the selected setup and the professional’s natural-language assertion, checks the proposed type in an isolated session, and stores the type, deterministic readback candidates, source references, and acceptance status with the assessment workpaper. A separate rules evaluator may flag populations for review, but registration and filing actions require tax-owner approval.

Where verified readback fits

A tax analyst describes the intended nexus or workflow relationship. The model proposes one proposition using only the setup’s vocabulary, or asks for clarification when jurisdiction, period, entity, or threshold treatment is ambiguous. Agda checks syntax and type composition. If the checked structure lies within the partial readback slice, ff-readback produces its finite audited family; unsupported structure fails visibly without guessed prose. The tax professional compares a successful reading with the intended analysis, then accepts it or supplies feedback. Type correctness is not factual truth or an authoritative tax conclusion; practitioner acceptance confirms the meaning of the formalized assertion, not satisfaction of its premises.

Potential benefits

The workbench can make threshold assumptions and exclusions visible, reduce inconsistent analyses across entities, and improve traceability from transaction populations to assessment and registration tasks. Versioned statements support period-over-period review and identify which assessments depend on a changed definition or measure. Deterministic readback also helps reviewers challenge the actual checked structure without reading Agda or relying on model-authored summaries.

Limits/adoption considerations

Nexus analysis can involve several forms of presence, attribution, sourcing, marketplace or intermediary rules, local variations, and retroactive or transitional effects. Those require jurisdiction- and period-specific setup governance and may not fit a simple threshold proposition. Tax data needs reconciliation and provenance controls. Production adoption requires restricted access, preparer-reviewer segregation, documented overrides, source currency monitoring, audit retention, and procedures to reopen assessments when data or interpretation changes.
02 Exemption and certificate eligibility control Explore pattern

System/use case

An exemption control helps tax operations determine whether a transaction may enter an exemption-review or tax-treatment workflow based on purchaser status, product or service classification, use, jurisdiction, period, and documentary support. It formalizes the control logic around exemption consideration while leaving the substantive tax conclusion to qualified reviewers.

Operational setting

The service integrates with order-to-cash, procure-to-pay, exemption-certificate management, product taxability, and billing platforms. Inputs include transaction identifiers, seller and purchaser entities, jurisdictional sourcing results, item classifications, stated use, certificate metadata, validation results, effective dates, and revocation status. Tax owners approve the exemption categories and evidence states exposed by each setup.

Decision/claim boundary

A candidate proposition may state that a classified transaction with approved evidence is eligible for exemption treatment review, or that stale evidence requires remediation. The type checker does not authenticate a certificate, determine that the purchaser or use qualifies, validate product classification, choose the governing jurisdiction, or establish that non-collection is lawful. Tax professionals retain authority for technical interpretation, evidentiary sufficiency, exception approval, and return treatment.

Candidate checked statements

Possible illustrative candidates include:

  • “For every in-scope transaction, if the purchaser is classified as qualifying and valid supporting evidence covers the transaction date, the transaction is eligible for exemption review.”
  • “If required exemption evidence is expired or revoked, the transaction requires remediation before non-taxable treatment.”
  • “Every applied exemption must reference an approved category and supporting evidence record.”

Example architecture

The transaction platform sends normalized order lines to a tax determination service. A master-data layer supplies customer, item, and jurisdiction classifications with provenance. A certificate repository exposes validity metadata and document references while retaining protected files. The exemption-rule registry stores professional-approved predicates and effective versions. FF Scribe is used during rule authoring and exception review to check propositions and render them deterministically. Accepted propositions can be promoted into a controlled evaluation layer; the engine returns a review status and rule trace rather than silently changing an invoice. Exception approvals, tax calculation, posting, and return reporting remain in established systems with human controls.

Where verified readback fits

A tax professional states the desired relationship among classification, evidence, and exemption disposition. The model converts it to a setup-limited proposition. Agda verifies that the formal statement is type-correct; it does not inspect the certificate or prove the transaction qualifies. The partial readback stage then either exposes supported binders, premises, and conclusion through the audited family or reports unsupported structure. The practitioner accepts a successful reading or gives feedback. Only that explicit meaning confirmation completes the proposition workflow, and even then the result is not an authoritative tax opinion or confirmation of the underlying facts.

Potential benefits

The control can reduce undocumented exemptions, distinguish invalid evidence from substantive ineligibility, and make category, period, and certificate dependencies clear to reviewers. It improves remediation queues and supports consistent workpapers by preserving the setup version, checked proposition, readback ID, evidence reference, and approval. Change-impact analysis can target exemption decisions relying on a modified classification or documentary requirement.

Limits/adoption considerations

Certificates and exemption claims vary in form, scope, acceptance standards, and renewal treatment. Evidence metadata may be incomplete or fraudulent, and transaction facts can change after ordering. Setups require tax and legal approval, controlled effective dates, and exception routes. Organizations should independently validate document processing, classification, and tax engines; maintain customer correction workflows; and ensure readback never appears as a guarantee that an exemption will withstand examination.
03 Tax-credit and incentive qualification workpaper assistant Explore pattern

System/use case

A qualification assistant helps tax teams document the logical structure of a credit or incentive position across eligible entities, activities, expenditures, periods, elections, limitations, and evidence packages. It provides a checked, practitioner-readable assertion for the workpaper file without attempting to calculate or claim the credit.

Operational setting

The application supports tax provision, compliance, incentive management, and review teams. It may receive normalized project, payroll, ledger, asset, location, and activity data plus interviews, technical narratives, elections, prior positions, and evidence indexes. A tax professional chooses the exact credit program, claimant entity, period, and source version represented by the setup. Sensitive personnel, project, and financial data remain under existing tax and finance access controls.

Decision/claim boundary

The proposition can express that a qualifying activity and supported expenditure classification make an item eligible for inclusion in a candidate credit base, or that a missing approval prevents workpaper closure. Type checking does not prove that an activity satisfies a statutory test, that an expense was incurred or allocable, that documentation meets an authority’s standard, that a limitation was computed correctly, or that a credit may be claimed. Preparers, reviewers, signatories, and external advisers retain their respective professional responsibilities.

Candidate checked statements

Illustrative candidates for a dedicated setup could be:

  • “For every project cost, if the activity is approved as qualifying and the cost is supported and allocable, the cost is eligible for credit-base review.”
  • “If a required qualification condition is unresolved, the associated amount is excluded from the ready-for-computation population.”
  • “Every claimed credit component must have a linked evidence package and reviewer approval.”

Example architecture

A tax workpaper platform ingests reconciled ledger populations and links them to project and evidence indexes. Classification models or questionnaires can suggest categories, but their outputs are labeled and reviewed rather than treated as facts. A versioned qualification setup contains tax-owner-approved concepts and evidence states. FF Scribe forms and checks candidate propositions, then attaches accepted readbacks and provenance to workpaper controls. A separate calculation engine applies validated formulas, carryforward or limitation logic, and reconciliations. Workflow enforces preparer-reviewer separation, exception sign-off, and final return or provision approval outside FF Scribe.

Where verified readback fits

The preparer describes an intended qualification or workpaper-control assertion in familiar tax language. The model proposes a single Agda type within the selected setup. Type checking establishes only formal well-formedness; it neither supplies a proof of qualification nor tests source records. If the partial translator supports the checked structure, ff-readback deterministically renders its audited finite family; otherwise the workflow stops visibly. The tax professional accepts a successful reading or gives feedback. This explicit acceptance confirms user intent only. Authoritative interpretation, factual substantiation, calculation accuracy, and ultimate return-position approval remain separate.

Potential benefits

The assistant can make qualification premises and evidence dependencies explicit, reduce inconsistent project coding, and give reviewers a stable bridge between a technical memorandum and detailed workpaper populations. Unsupported items can be routed for investigation instead of silently included or rejected. A versioned record also improves roll-forward review and helps identify positions affected by changed program rules, entity structures, or evidence policies.

Limits/adoption considerations

Credit regimes often contain qualitative tests, aggregation rules, elections, interactions, caps, and recapture provisions that exceed a small formal vocabulary. Evidence quality and technical narratives require professional judgment. Setups and readback phrases should be reviewed for each program and period, and calculation logic must undergo separate validation. Tax confidentiality, financial-control requirements, documentation standards, model-risk controls, and examination readiness all shape adoption.
04 Tax rule-change and scenario-consistency review service Explore pattern

System/use case

A scenario-review service compares tax treatments under different professional-approved rule, period, entity, or transaction assumptions. It helps teams identify which classifications, calculations, filings, and prior workpaper assumptions may require reconsideration after a rule update or business change.

Operational setting

The service supports tax planning, compliance readiness, provision forecasting, acquisition integration, and controlled rule maintenance. It uses versioned setup pairs, representative transaction or entity scenarios, source-effective dates, prior accepted propositions, and downstream dependency mappings. Numerical models and tax engines remain separate and carry their own parameter, formula, and validation controls.

Decision/claim boundary

A checked proposition may say that a scenario satisfying revised conditions enters a different review category or that conflicting treatments require escalation. It does not establish which rule version legally applies, predict an authority’s position, validate a forecast, calculate liability, or conclude that a prior return was incorrect. The tax owner authorizes interpretations and assumptions; accounting, legal, finance, and governance approvals remain applicable.

Candidate checked statements

Illustrative comparison statements include:

  • “Under the proposed setup version, every transaction in the revised covered category requires reclassification review.”
  • “If an accepted prior-period position depends on a changed definition, that position requires tax-owner reassessment.”
  • “If two approved rules assign incompatible treatments to the same entity, transaction, jurisdiction, and period, the scenario requires escalation.”

Example architecture

A tax knowledge registry retains source versions, interpretations, setup releases, and their owners. A dependency graph links accepted propositions to entity mappings, product rules, workpapers, return lines, controls, and calculation modules. A scenario orchestrator runs representative assertions through FF Scribe under baseline and proposed setups, preserving compiler results and deterministic readbacks. A structural diff and impact dashboard identify changed predicates and dependent artifacts. Separate tax engines calculate approved scenarios, while reconciliation and review workflows assess financial consequences. No configuration, filing, or ledger entry changes automatically from a formalization result.

Where verified readback fits

A tax professional describes the expected consequence for one rule version or a comparison scenario. The model constructs a proposition from the setup-scoped vocabulary, and Agda checks its formal validity. For a supported structure, the audited readback family deterministically states what was checked; unsupported translation fails visibly. The professional explicitly accepts a successful reading or provides feedback. A completed cycle creates a reliable object for comparison, not proof that the rule is complete, applicable, factually satisfied, or legally correct. It does not confirm that the intended business scenario was modeled until the practitioner accepts the readback.

Potential benefits

The service can make hidden assumptions visible, reveal dependencies affected by new definitions or period rules, and support a prioritized change backlog. Teams can compare alternatives in stable language and preserve why a configuration or position was reconsidered. Consistency checks can surface mutually incompatible treatments for human resolution before they propagate into billing, provision, compliance, or reporting systems.

Limits/adoption considerations

Rule interactions, transitional provisions, retroactivity, tax-treaty questions, accounting-tax differences, and uncertain authority may require specialized models or narrative analysis. Impact completeness depends on the dependency graph and source inventory. Adoption requires semantic versioning, effective-date governance, dual review for high-risk changes, reproducible data snapshots, scenario labeling, audit retention, and explicit retirement or supersession of stale accepted propositions. Professional authority remains the final control.

Applicability frame

MLTTDB is plausible as an assurance layer for tax positions already translated into proof-assistant types and propositions. Agda, Lean, or Rocq source owns row types and table declarations. The SQLite term store owns ordered source-language records, UUIDs, projection values, language metadata, and table definitions. It may orchestrate verification, but only the proof assistant performs semantic checking. Agda currently offers finite known-UUID table lookup; Lean and Rocq preprocessors do not. Transaction ingestion, master-data stewardship, source reconciliation, tax research, identity and access, workflow, calculations, runtime determination, filings, payments, provenance, and formalization review remain external production capabilities.

Current data mode checks fetched rows as separate definitions; it does not expose a table to application proofs as an enumerable, first-class collection. Whenever an example below claims whole-snapshot coverage, uniqueness, graph acyclicity, or aggregate tax-rule coverage, the architecture therefore assumes either a finite domain declared in proof source or an external snapshot compiler that emits a reconciled aggregate manifest/certificate term. The proof assistant checks that aggregate term, while external reconciliation establishes that it represents the table export supplied for tax review.

01 Indirect-tax nexus and registration position assurance Explore pattern

Operational context

A group sells goods, digital products, and services through direct and marketplace channels. Its tax function periodically reviews whether activity in each operating territory has crossed a modeled economic, physical-presence, or transaction threshold and whether a registration position needs attention. Finance systems can aggregate sales and operational facts, but rule matrices are difficult to govern across entity, channel, supply type, place-of-supply assumption, period, and exception. The target system validates a proposed review packet before tax professionals approve a position; it does not determine nexus itself.

Why MLTTDB fits

Proof-assistant types can force each threshold rule to declare its measure, currency or count unit, aggregation period, entity scope, channel treatment, effective interval, and exception model. Reviewed activity summaries can be stored as terms with explicit completeness and reconciliation status. Propositions can prohibit comparing incompatible units, require marketplace-facilitated activity to receive an explicit inclusion treatment, and return NeedsProfessionalReview when the available facts do not satisfy modeled evidence prerequisites. Stable UUIDs make rule and scenario changes traceable between review cycles.

Example architecture

ERP/commerce/locations -> governed tax data mart -> reconciled activity summaries
tax research service -> counsel-reviewed formal model -> model repository
summaries -> MLTTDB -> proof-assistant verification -> tax review -> registration workflow

The tax data mart owns normalized transactions, entity mappings, locations, currency conversions, and reconciliation to ledgers. Tax researchers maintain authority sources outside MLTTDB, and qualified reviewers approve their formal translation. A snapshot adapter emits only the aggregates and categorical facts required by the model. Verification results populate a position-review workbench. A separate compliance platform manages registrations, returns, correspondence, and deadlines after authorized approval.

Representative typed artifacts

Tables might include jurisdictionProfiles :T: JurisdictionProfile, thresholdRules :T: ThresholdRule, activitySnapshots :T: ActivitySnapshot, and positionProposals :T: PositionProposal. MeasuredAmount carries unit, currency basis, conversion date policy, and period; transaction counts are a different type. ActivitySnapshot distinguishes sourced data, adjustments, exclusions, and unresolved reconciliation items. A TaxPositionManifest aggregate term, reconciled to rule and activity exports, materializes the supply/channel taxonomy, effective rules, exceptions, and proposal UUIDs for whole-snapshot checks. Propositions check scope compatibility, period alignment, effective rules, and whether a proposed outcome is supported by the modeled threshold path. Agda rows may refer to earlier profiles by UUID; Lean/Rocq designs must use ordinary generated associations.

Checks and evidence

Model checks cover exhaustiveness of supply and channel categories enumerated by the reconciled manifest, incompatible threshold units, overlapping effective rules, and missing exception dispositions. Snapshot checks reject incomplete entity mappings, stale exchange-rate assumptions, unbalanced adjustments, and unsupported outcome reasons. Boundary suites test amounts and counts around modeled thresholds, short periods, channel changes, registrations already held, and ambiguous sourcing. The external evidence package retains data lineage, rule/activity/manifest reconciliation approval, rule-source references, model commit, ordered row UUIDs, verifier transcript, reviewer sign-off, and downstream registration action.

Potential benefits

Tax teams can review a consistent position packet instead of reconstructing rule and data assumptions in spreadsheets. Typed units reduce threshold-comparison errors, explicit unknown states prevent silent defaults, and scenario regression highlights territories affected by a model or business change. The approach can improve repeatability and division of responsibilities while leaving authority research and judgment with professionals.

Deployment boundary

MLTTDB does not source transactions, establish place of supply, determine nexus, interpret thresholds, perform currency conversion, register an entity, calculate tax, file returns, or guarantee data completeness. A formal result is conditional on the approved model and supplied facts. Production requires controlled tax research, ledger reconciliation, entity and channel governance, reviewer independence, filing calendars, access controls, monitoring, and manual escalation. Qualified tax and legal professionals approve every position.
02 Exemption-certificate and transaction-treatment preflight Explore pattern

Operational context

A seller processes high-volume business transactions for which customer status, product classification, use, destination, and documentary evidence may affect indirect-tax treatment. Certificate management, ERP tax engines, and billing already execute the operational process. The assurance problem is ensuring that a proposed exemption or special-treatment decision uses a currently approved evidence state and a coherent combination of customer, product, and transaction facts before an invoice or retrospective correction is finalized.

Why MLTTDB fits

A typed model can distinguish a certificate’s existence from its validation status, scope, covered customer entity, applicable product or use category, territory, and effective period. Transaction projections can explicitly represent missing, disputed, expired, or not-required evidence. Proof obligations can require every proposed non-standard treatment to cite an eligible modeled basis and compatible evidence, while ensuring that unresolved mappings route to review. This is more expressive than validating independent ERP fields because the proof assistant checks their relationships.

Example architecture

customer master + certificate vault + order/ERP -> reconciliation service
approved treatment taxonomy -> proof model -----> MLTTDB review terms
preflight request -> verification service -> tax exception queue -> ERP tax engine

The certificate vault owns documents, validation events, and expiry monitoring. Master-data and product-taxonomy teams own customer and item mappings. A reconciliation service creates a versioned, minimal transaction projection and records source identifiers. MLTTDB stores the rendered source terms, and the proof-assistant path checks them against the reviewed model. An external exception service interprets pass/fail/indeterminate states under approved workflow controls; the ERP tax engine remains the runtime calculation and invoicing component.

Representative typed artifacts

Declarations could include evidenceProfiles :T: EvidenceProfile, treatmentRules :T: TreatmentRule, and transactionReviews :T: TransactionReview. A CertificateEvidence term includes validation disposition, covered party role, scope category, territory profile, and effective interval, but the underlying document remains in the vault. TransactionReview separates source-system assertions from tax-team-confirmed mappings. Propositions such as evidenceSupportsTreatment and treatmentMatchesSupply require compatible roles, periods, categories, and reason paths. Where Agda lookup is used, the evidence table must be declared before the dependent review table; same-table dependencies are topologically ordered, and cycles are invalid. Other backends need self-contained generated records.

Checks and evidence

Preflight rejects unknown certificate references, expired or out-of-scope evidence, mismatched customer entities, unsupported product/use combinations, and attempts to turn an indeterminate mapping into an exempt outcome. Regression fixtures cover partial exemptions, mixed orders, returns, credits, drop shipments, certificate replacement, and retrospective validation. A controlled evidence record combines transaction and master-data revisions, certificate-vault reference and status, model commit, ordered UUIDs, verifier output, tax reviewer disposition, and final ERP tax result. Periodic samples reconcile projections to invoices and documents.

Potential benefits

The design can reduce unsupported exemption overrides, make evidence assumptions visible, and focus tax reviewers on genuinely ambiguous transactions. Typed effective periods and party roles reduce common mismatches. Repeatable tests help teams assess rule, product-taxonomy, or certificate-workflow changes before release. Review evidence becomes easier to reconstruct without moving sensitive source documents into the term store.

Deployment boundary

MLTTDB does not authenticate certificates, determine exemption, classify products, validate customer identity, calculate tax, block an invoice, or establish that source facts are complete. It is not an immutable audit log or a certified tax engine. Document custody, electronic-signature checks, sanctions or fraud controls, retention, invoice workflow, calculation, reporting, and corrections remain external. Tax professionals approve treatment rules, exceptions, and material transaction positions.
03 Tax credit or incentive eligibility workpaper assurance Explore pattern

Operational context

A corporate tax team evaluates projects and expenditure pools for a statutory credit or investment incentive. Engineers, finance staff, payroll teams, and external advisers contribute evidence about activities, assets, costs, funding, related parties, and time periods. The final position depends on professional interpretation and substantiation, but the workpaper set also has structural requirements: claimed cost categories must be allowed by the selected modeled route, exclusions must be applied consistently, and caps or interactions must use compatible bases.

Why MLTTDB fits

The proof model can separate technical-activity findings, accounting classifications, evidence status, and tax conclusions instead of flattening them into spreadsheet flags. Typed monetary amounts carry currency, period, entity, and gross/net basis. Propositions can require every included expenditure row to refer to a reviewer-confirmed qualifying activity category, apply modeled exclusions before caps, and prevent the same cost from being allocated twice within the formal dataset. An explicit Unresolved constructor preserves questions for specialist review.

Example architecture

project tools/payroll/ledger -> controlled workpaper data mart -> cost projections
tax and technical reviewers -> approved incentive model -> MLTTDB typed schedules
proof-assistant check -> exception/remediation loop -> signed position -> filing system

The data mart owns transaction lineage, allocation methods, currency conversion, and reconciliation to accounts. Technical reviewers record activity findings in the workpaper platform. Tax specialists own the legal interpretation and formal model. A schedule generator emits source-language terms for reviewed activities, expenditure pools, interactions, and expected computations. Verification findings return to the workpaper review loop. Only after human approval does a conventional tax calculation and filing process consume the signed schedule.

Representative typed artifacts

Candidate declarations include activityFindings :T: ActivityFinding, costPools :T: CostPool, incentiveRules :T: IncentiveRule, and claimSchedules :T: ClaimSchedule. CostPool records accounting source, allocation basis, related activity, entity, period, amount basis, and evidence status. The schedule generator builds each aggregate ClaimSchedule to enumerate every represented cost-pool UUID as candidate, excluded, unresolved, or proposed eligible, then reconciles that enumeration and its source digest to the workpaper export. Propositions check modeled route eligibility, allocation totals, incompatible funding interactions, effective periods, and that derived totals are assembled only from permitted constructors. Agda may use earlier UUID-addressed rule or activity rows; portable variants should generate ordinary associations for Lean and Rocq.

Checks and evidence

Validation rejects unit or period mismatches, unreviewed activities used as qualifying facts, double allocation, missing exclusion treatment, out-of-scope entities, and modeled cap computations over the wrong base. Scenario suites include mixed-use costs, partial periods, shared personnel, grant funding, related-party charges, asset disposals, and amendments. Evidence includes ledger and payroll reconciliation identifiers, allocation-method approval, technical review references, authority research links, model commit, ordered UUIDs, checker transcript, adjustments, and final tax sign-off. Independent recalculation compares exported totals with the filing workpaper.

Potential benefits

Teams can find structural workpaper defects before final review, preserve a clear boundary between technical findings and tax conclusions, and rerun the same schedules after rule or allocation changes. Typed amounts reduce basis and period errors, while proof obligations make inclusion and exclusion assumptions inspectable. The resulting evidence can improve review efficiency and repeatability across entities and claim periods.

Deployment boundary

MLTTDB does not determine that an activity or expenditure qualifies, verify invoices or timesheets, choose an allocation method, calculate an authoritative credit, value an asset, prepare a return, or defend a position. It proves only modeled propositions about supplied terms. Production use requires source-document controls, ledger reconciliation, technical and tax interviews, materiality judgment, transfer-pricing and accounting review where relevant, filing controls, retention, and qualified professional approval.
04 Withholding and entity-classification position consistency Explore pattern

Operational context

A multinational accounts-payable or treasury function makes cross-border and domestic payments to vendors, investors, employees, and related entities. Payee classification, payment character, documentation, beneficial-owner assertions, exemptions or reduced-rate positions, and reporting obligations interact. Operational withholding engines apply configured rules, but tax teams need a pre-release consistency check that a reviewed payee/payment position and its documentation support the treatment configured for a payment stream.

Why MLTTDB fits

Formal types can keep legal entity classification, operational vendor type, payment character, documentation status, and proposed withholding treatment distinct. A proof assistant can enforce counsel-approved compatibility rules and require explicit escalation when classifications conflict or evidence is unavailable. Effective intervals and versioned rule profiles make it possible to replay representative payment positions after a policy update. MLTTDB’s ordered records and UUIDs support controlled reviewer evidence without pretending that the store validates documents or knows beneficial ownership.

Example architecture

vendor onboarding + entity master + payment hub -> tax-data reconciliation
tax research and position memos -> formal rule/profile repository
typed payment position -> MLTTDB verification -> tax approval -> withholding/reporting engine

Onboarding owns identity and documentation collection; the entity master owns party hierarchy and status; the payment hub owns instruments, amounts, and execution. A reconciliation adapter freezes the reviewed facts for a payment class or run and renders typed terms. Verification checks them under a pinned profile. Exceptions enter a tax work queue linked to source records and position memoranda. The existing withholding and reporting engine calculates, remits, reports, and corrects amounts only after its own approved controls.

Representative typed artifacts

Tables might include entityProfiles :T: EntityProfile, documentAssessments :T: DocumentAssessment, paymentClasses :T: PaymentClass, and withholdingPositions :T: WithholdingPosition. DocumentAssessment expresses reviewed status, claimed role, scope, effective interval, and source reference—not authenticity. WithholdingPosition records the selected rule profile, payment character, payee role, evidence basis, and proposed treatment category. A WithholdingPositionManifest aggregate term, reconciled to entity, document, payment-run, and row exports, enumerates the positions whose cross-payment consistency is checked. Propositions test classification consistency, document scope and currency, permitted position/reason combinations, and escalation for contradictory assertions. Agda can link earlier entity and document rows by UUID; Lean/Rocq deployments must not assume such lookup.

Checks and evidence

Checks flag mismatched legal and operational entities, incompatible payment character and position, expired or out-of-scope documentation, unresolved beneficial-owner assertions represented as facts, inconsistent treatment across the same reviewed payment class, and rule profiles outside their modeled period. Scenario suites cover split payments, intermediaries, entity changes, multiple documentation claims, refunds, corrections, and late evidence. External evidence combines master-data and payment-run revisions, document-vault references, position memo and authority links, model commit, ordered UUIDs, verifier output, reviewer approval, engine result, and reconciliation to reporting.

Potential benefits

The tax function gains a consistent vocabulary across onboarding, treasury, payables, and reporting. Contradictions can reach a reviewer before payment release or filing, and model changes can be tested against stable representative positions. Explicit unknown and disputed states reduce unsafe defaulting. The evidence bundle makes clear which data and approved assumptions supported a configuration decision.

Deployment boundary

MLTTDB does not classify an entity or payment under law, authenticate documentation, establish beneficial ownership, choose a rate, calculate or remit withholding, file information returns, or guarantee treaty or statutory eligibility. It is not a screening or payment-control system. Identity verification, sanctions controls, document custody, tax research, calculations, payment execution, reporting, corrections, appeals, access, and monitoring remain external. Qualified tax and legal professionals approve the formal model and every material position.

These read-only, pan-and-zoom models expose three abstraction levels for each workflow. They are explanatory examples, not live operational or decision systems.

01

Cross-Border VAT Treatment

About this workflow

This example represents the control path for determining and reporting VAT on a cross-border supply. It connects the commercial facts—supplier and customer status, goods or services, establishments, movement, consideration, and invoice jurisdiction—to the resulting place-of-supply analysis, rate or relief, invoicing, ledger posting, return disclosure, and input-tax recovery position.

The workflow starts with transaction intake because VAT treatment cannot be selected reliably from an invoice label alone. The relevant parties, movement or performance facts, jurisdictions, and period are captured before the supply is classified. Classification distinguishes goods from services, considers customer status and establishment, and handles composite supplies, chains, and intermediaries. Incorrect or incomplete facts return to intake. The tax-treatment review then applies the controlling jurisdictional rules to decide whether the supply is taxable, exempt, zero-rated, or subject to reverse charge, and verifies identifiers and transport or other supporting evidence.

An approved treatment moves to invoicing and the ledger, where mandated statements and tax fields are produced, output and recoverable input VAT are posted, and evidence is linked to the entry. Reporting assigns the transaction to the correct jurisdictional return fields and supplementary reports and reconciles invoice, ledger, and transport records. Conflicts in either posting or reporting open a treatment exception. A repair may correct the invoice or posting and return to that stage, or may require a fresh treatment analysis. Closure records the submitted treatment and recoverability outcome only after reporting is complete.

These controls matter because the same commercial supply can produce different VAT consequences when customer status, establishment, movement, evidence, or the rule period changes. A missing identifier or transport document may defeat a relief even when the commercial facts otherwise support it. Connecting the rule path to invoice, ledger, return, and evidence reduces inconsistent treatments, blocked recovery, duplicate taxation, and amendments that cannot be explained to auditors or authorities.

Layer 1 — VAT treatment lifecycle

This is the VAT lead’s end-to-end view: intake, classification, treatment decision, invoicing and posting, reporting, exception remediation, and period close. It exposes the principal decision gates and the paths back when facts or treatment change. It intentionally omits invoice fields, ledger accounts, return boxes, and individual evidence documents so the overall control status remains clear.

Layer 2 — Classification and reporting procedures

This layer is used by indirect-tax specialists and reporting teams. It covers supply classification, place-of-supply dependencies, customer and establishment analysis, relief and reverse-charge criteria, invoice requirements, ledger treatment, return allocation, reconciliation, and amendments. It includes the procedural handoffs between tax determination and reporting but excludes the atomic validation or posting actions performed for each transaction.

Layer 3 — Transaction evidence actions

This layer shows the auditable actions on a particular supply: capturing VAT identifiers and movement facts, testing transport evidence, generating invoice statements, linking documentation to ledger entries, reconciling transaction populations, and recording blocked recovery or corrected treatment. It intentionally excludes portfolio-level period management and policy ownership, which belong in the broader layers.
02

Research Credit Qualification and Substantiation

About this workflow

This example represents preparation of a research-credit claim in which qualification, cost capture, calculation, and substantiation remain tied together. It is organized around projects, activities, entities, and tax periods because a general statement that a company performs innovative work is not enough. The claim must show which work was evaluated, which qualifying conditions were met, which expenditures relate to that work, and what evidence supports those conclusions.

The cycle starts with a project inventory. Candidate projects are associated with technical objectives and responsible substantiation owners. Activity qualification then maps the actual work to each applicable condition, separates routine or excluded activity, and records the technological uncertainty and process of experimentation. An incomplete inventory loops back for correction before costs are classified, preventing payroll or contractor amounts from driving qualification after the fact.

Cost classification associates wages, supplies, and contracted research with qualified activities, applies allocation and related-party rules, and removes amounts outside the qualifying period. The claim calculation aggregates those costs using the selected method and applicable limitations, then reconciles the result to return workpapers. Substantiation review samples costs back to project evidence, checks that the correct rule and period assumptions were used, and resolves unsupported amounts. A finding opens a claim exception with a named owner and explicit treatment. Depending on the gap, remediation returns to activity qualification or cost classification; changed amounts are recalculated before approval. Finalization occurs only when the supported amount and disclosures are approved and the evidence trail is archived.

The controls matter because research-credit exposure usually arises at the seams: a technically credible project with weak contemporaneous evidence, an eligible activity with an unsupported allocation, or a correct calculation built from an overstated cost pool. Keeping every amount connected to qualification and evidence supports review, reduces inconsistent treatment across business units, and makes exclusions and revisions as traceable as the claimed benefit.

Layer 1 — Credit claim lifecycle

This is the tax provision and claim-governance view. It follows the claim from project population through qualification, cost classification, calculation, review, exception resolution, and final approval. It highlights readiness and major rework loops across entities and periods. It deliberately excludes individual time records, invoices, test artifacts, and formula cells so reviewers can see whether the claim as a whole has reached a defensible stage.

Layer 2 — Qualification and substantiation procedures

This is the procedure-level view used by tax specialists, technical interviewers, finance owners, and reviewers. It covers project scoping, activity-by-activity analysis, allocation methods, calculation controls, sampling, review findings, and routed remediation. It includes who must resolve a gap and which earlier decision must be revisited, while excluding the atomic evidence checks performed on each source record.

Layer 3 — Evidence-level actions

This layer represents the workpaper and source-evidence actions: linking objectives to technical records, documenting uncertainty and experimentation, tracing wages and supplies, applying period and related-party tests, retaining calculation inputs, and recording reviewer dispositions. It is detailed enough to reproduce an included or excluded amount. It intentionally leaves claim-wide approval and portfolio status to the higher layers.
03

Multi-State Sales-Tax Nexus and Filing

About this workflow

This example represents the operating cycle a tax department uses to decide where a business has a sales-tax obligation and then carry that decision through registration, collection, return preparation, and period close. It is deliberately jurisdiction- and period-aware: a threshold, exclusion, marketplace-facilitator provision, or product treatment may be correct in one state and filing period but wrong in another.

The workflow begins with activity monitoring. Direct and marketplace sales, transaction counts, and physical-presence events are accumulated by jurisdiction and effective period. A nexus review applies the relevant definition and threshold rather than treating a national sales total as the deciding fact. Activity below the applicable threshold returns to monitoring; established nexus moves into registration. Registration status and effective dates then govern when collection can be activated. Once collection is active, the tax engine’s rates and product mappings, exemption certificates, and collected-tax totals must stay aligned with the approved posture.

At filing time, transaction sources and collected tax are reconciled, adjustments and exemptions are assigned to the correct return lines, and the return and remittance are prepared. Missing transaction data, a rejected return, or a payment variance opens a filing exception instead of being hidden in the close process. A repair may return the case to filing preparation, while evidence that the underlying activity was classified incorrectly sends it back to activity monitoring and nexus analysis. The period closes only after acceptance and remittance reconciliation, with the jurisdictional posture carried into the next monitoring period.

These controls matter because nexus and collection failures can create uncollected liabilities, customer overcharges, late registrations, penalties, and inconsistent positions across jurisdictions. The model keeps the rule version, activity facts, exemption support, return treatment, and remediation path connected so reviewers can reproduce why the business registered, collected, filed, amended, or remained below threshold.

Layer 1 — Tax posture lifecycle

This layer is the tax director’s portfolio view: monitoring, nexus determination, registration, active collection, filing, exception handling, and period close. It answers where each jurisdiction stands and what major obligation comes next. It intentionally excludes individual return lines, certificate checks, and transaction calculations so the end-to-end posture and escalation routes remain readable.

Layer 2 — Nexus and filing procedures

This layer is the working view for state-and-local tax and compliance teams. It covers threshold testing, marketplace and physical-presence classification, registration effective dates, collection configuration, return reconciliation, amendments, extensions, and reassessment. It includes the handoffs and control decisions that move a jurisdiction between stages, but excludes the lowest-level source-system commands and field-by-field execution.

Layer 3 — Transaction-level actions

This layer shows the evidence-bearing work behind each procedure: aggregating jurisdictional sales and counts, checking exclusions, validating exemption certificates, assigning adjustments to return lines, reconciling tax collected, and documenting corrections. Its scope is an auditable transaction or filing action. It intentionally does not restate enterprise tax policy or summarize the overall jurisdiction portfolio; those decisions are represented in the higher layers.
Interactive state machine

Workflow demo

Skip to content

Domains

Tax

Placeholder domain page for tax rules involving exemptions, nexus, and credits.

  • exemptions
  • nexus
  • credits

Problems we solve

Checked boundaries and evidence

  • Rules vary across jurisdictions, filing periods, entities, and transaction types.
  • Exemptions and credits depend on detailed conditions and supporting evidence.
  • Nexus determinations combine thresholds with changing business activity.
  • Rule updates can alter calculations and prior decision assumptions.
Rule Mapping

Connect definitions, jurisdictions, periods, and dependencies.

Eligibility Checking

Evaluate exemptions and credits against explicit criteria.

Scenario Calculation

Compare outcomes under representative rule combinations.

Consistency Review

Detect conflicting treatments and missing evidence.

Decision Records

Capture the rule path behind each placeholder result.

Application patterns

Imported product records

These panels use the same generated application portfolio as the desktop workbench.

FF Scribe4 patterns
The Tax domain concerns jurisdiction, nexus, entity and transaction classification, filing periods, exemptions, credits, thresholds, supporting evidence, and the effect of rule changes. These applications use verified readback to make a tax professional’s proposed rule statement structurally explicit and reviewable. They support rule mapping, eligibility checking, scenario comparison, consistency review, and decision records; they do not determine authoritative tax treatment, validate source data, calculate a return, establish that evidence is sufficient, or replace professional judgment and required sign-off.
01Indirect-tax nexus and registration assessment workbench

System/use case

A nexus workbench helps indirect-tax teams articulate when a combination of entity activity, transaction measures, presence indicators, jurisdiction, and period should trigger an assessment or registration-review workflow. Accepted propositions serve as controlled workpaper assertions linked to a source and period, not as autonomous conclusions that an obligation exists.

Operational setting

The workbench sits between enterprise resource planning, billing, order, location, legal-entity, and tax compliance systems. A tax data mart aggregates transactions using approved sourcing and entity mappings. Tax professionals select the jurisdiction, tax type, filing period, authority hierarchy, threshold version, and known exclusions represented by a curated setup. Registration status and filing obligations remain in the tax compliance system of record.

Decision/claim boundary

The checked claim is limited to a setup-scoped relationship such as: activity meeting a selected threshold plus a qualifying presence condition entails nexus review. It does not establish that transactions were sourced correctly, a threshold value is current, activities are attributable to the entity, nexus exists as a matter of law, registration is required, or tax is due. The responsible tax professional, with legal advice where appropriate, owns jurisdictional interpretation, effective-date selection, factual assumptions, and the final position.

Candidate checked statements

Illustrative controlled-English propositions for a future nexus setup could include:

  • “For every entity and filing period, if in-scope activity meets the approved jurisdictional threshold, the entity requires nexus review for that period.”
  • “If a qualifying exclusion applies to the measured activity, that activity is not included in the selected threshold test.”
  • “If nexus is approved and no active registration is recorded, a registration task is required.”

These examples do not claim that present setups implement the terms or that a specific entity meets any threshold.

Example architecture

Source systems publish transactions, customer and service locations, entity ownership, and presence signals to a governed tax data platform. A sourcing and classification layer produces versioned measures with lineage and reconciliation status. A tax-rule registry holds practitioner-curated definitions, threshold parameters, effective periods, inclusions, and exclusions. FF Scribe receives the selected setup and the professional’s natural-language assertion, checks the proposed type in an isolated session, and stores the type, deterministic readback candidates, source references, and acceptance status with the assessment workpaper. A separate rules evaluator may flag populations for review, but registration and filing actions require tax-owner approval.

Where verified readback fits

A tax analyst describes the intended nexus or workflow relationship. The model proposes one proposition using only the setup’s vocabulary, or asks for clarification when jurisdiction, period, entity, or threshold treatment is ambiguous. Agda checks syntax and type composition. If the checked structure lies within the partial readback slice, ff-readback produces its finite audited family; unsupported structure fails visibly without guessed prose. The tax professional compares a successful reading with the intended analysis, then accepts it or supplies feedback. Type correctness is not factual truth or an authoritative tax conclusion; practitioner acceptance confirms the meaning of the formalized assertion, not satisfaction of its premises.

Potential benefits

The workbench can make threshold assumptions and exclusions visible, reduce inconsistent analyses across entities, and improve traceability from transaction populations to assessment and registration tasks. Versioned statements support period-over-period review and identify which assessments depend on a changed definition or measure. Deterministic readback also helps reviewers challenge the actual checked structure without reading Agda or relying on model-authored summaries.

Limits/adoption considerations

Nexus analysis can involve several forms of presence, attribution, sourcing, marketplace or intermediary rules, local variations, and retroactive or transitional effects. Those require jurisdiction- and period-specific setup governance and may not fit a simple threshold proposition. Tax data needs reconciliation and provenance controls. Production adoption requires restricted access, preparer-reviewer segregation, documented overrides, source currency monitoring, audit retention, and procedures to reopen assessments when data or interpretation changes.
02Exemption and certificate eligibility control

System/use case

An exemption control helps tax operations determine whether a transaction may enter an exemption-review or tax-treatment workflow based on purchaser status, product or service classification, use, jurisdiction, period, and documentary support. It formalizes the control logic around exemption consideration while leaving the substantive tax conclusion to qualified reviewers.

Operational setting

The service integrates with order-to-cash, procure-to-pay, exemption-certificate management, product taxability, and billing platforms. Inputs include transaction identifiers, seller and purchaser entities, jurisdictional sourcing results, item classifications, stated use, certificate metadata, validation results, effective dates, and revocation status. Tax owners approve the exemption categories and evidence states exposed by each setup.

Decision/claim boundary

A candidate proposition may state that a classified transaction with approved evidence is eligible for exemption treatment review, or that stale evidence requires remediation. The type checker does not authenticate a certificate, determine that the purchaser or use qualifies, validate product classification, choose the governing jurisdiction, or establish that non-collection is lawful. Tax professionals retain authority for technical interpretation, evidentiary sufficiency, exception approval, and return treatment.

Candidate checked statements

Possible illustrative candidates include:

  • “For every in-scope transaction, if the purchaser is classified as qualifying and valid supporting evidence covers the transaction date, the transaction is eligible for exemption review.”
  • “If required exemption evidence is expired or revoked, the transaction requires remediation before non-taxable treatment.”
  • “Every applied exemption must reference an approved category and supporting evidence record.”

Example architecture

The transaction platform sends normalized order lines to a tax determination service. A master-data layer supplies customer, item, and jurisdiction classifications with provenance. A certificate repository exposes validity metadata and document references while retaining protected files. The exemption-rule registry stores professional-approved predicates and effective versions. FF Scribe is used during rule authoring and exception review to check propositions and render them deterministically. Accepted propositions can be promoted into a controlled evaluation layer; the engine returns a review status and rule trace rather than silently changing an invoice. Exception approvals, tax calculation, posting, and return reporting remain in established systems with human controls.

Where verified readback fits

A tax professional states the desired relationship among classification, evidence, and exemption disposition. The model converts it to a setup-limited proposition. Agda verifies that the formal statement is type-correct; it does not inspect the certificate or prove the transaction qualifies. The partial readback stage then either exposes supported binders, premises, and conclusion through the audited family or reports unsupported structure. The practitioner accepts a successful reading or gives feedback. Only that explicit meaning confirmation completes the proposition workflow, and even then the result is not an authoritative tax opinion or confirmation of the underlying facts.

Potential benefits

The control can reduce undocumented exemptions, distinguish invalid evidence from substantive ineligibility, and make category, period, and certificate dependencies clear to reviewers. It improves remediation queues and supports consistent workpapers by preserving the setup version, checked proposition, readback ID, evidence reference, and approval. Change-impact analysis can target exemption decisions relying on a modified classification or documentary requirement.

Limits/adoption considerations

Certificates and exemption claims vary in form, scope, acceptance standards, and renewal treatment. Evidence metadata may be incomplete or fraudulent, and transaction facts can change after ordering. Setups require tax and legal approval, controlled effective dates, and exception routes. Organizations should independently validate document processing, classification, and tax engines; maintain customer correction workflows; and ensure readback never appears as a guarantee that an exemption will withstand examination.
03Tax-credit and incentive qualification workpaper assistant

System/use case

A qualification assistant helps tax teams document the logical structure of a credit or incentive position across eligible entities, activities, expenditures, periods, elections, limitations, and evidence packages. It provides a checked, practitioner-readable assertion for the workpaper file without attempting to calculate or claim the credit.

Operational setting

The application supports tax provision, compliance, incentive management, and review teams. It may receive normalized project, payroll, ledger, asset, location, and activity data plus interviews, technical narratives, elections, prior positions, and evidence indexes. A tax professional chooses the exact credit program, claimant entity, period, and source version represented by the setup. Sensitive personnel, project, and financial data remain under existing tax and finance access controls.

Decision/claim boundary

The proposition can express that a qualifying activity and supported expenditure classification make an item eligible for inclusion in a candidate credit base, or that a missing approval prevents workpaper closure. Type checking does not prove that an activity satisfies a statutory test, that an expense was incurred or allocable, that documentation meets an authority’s standard, that a limitation was computed correctly, or that a credit may be claimed. Preparers, reviewers, signatories, and external advisers retain their respective professional responsibilities.

Candidate checked statements

Illustrative candidates for a dedicated setup could be:

  • “For every project cost, if the activity is approved as qualifying and the cost is supported and allocable, the cost is eligible for credit-base review.”
  • “If a required qualification condition is unresolved, the associated amount is excluded from the ready-for-computation population.”
  • “Every claimed credit component must have a linked evidence package and reviewer approval.”

Example architecture

A tax workpaper platform ingests reconciled ledger populations and links them to project and evidence indexes. Classification models or questionnaires can suggest categories, but their outputs are labeled and reviewed rather than treated as facts. A versioned qualification setup contains tax-owner-approved concepts and evidence states. FF Scribe forms and checks candidate propositions, then attaches accepted readbacks and provenance to workpaper controls. A separate calculation engine applies validated formulas, carryforward or limitation logic, and reconciliations. Workflow enforces preparer-reviewer separation, exception sign-off, and final return or provision approval outside FF Scribe.

Where verified readback fits

The preparer describes an intended qualification or workpaper-control assertion in familiar tax language. The model proposes a single Agda type within the selected setup. Type checking establishes only formal well-formedness; it neither supplies a proof of qualification nor tests source records. If the partial translator supports the checked structure, ff-readback deterministically renders its audited finite family; otherwise the workflow stops visibly. The tax professional accepts a successful reading or gives feedback. This explicit acceptance confirms user intent only. Authoritative interpretation, factual substantiation, calculation accuracy, and ultimate return-position approval remain separate.

Potential benefits

The assistant can make qualification premises and evidence dependencies explicit, reduce inconsistent project coding, and give reviewers a stable bridge between a technical memorandum and detailed workpaper populations. Unsupported items can be routed for investigation instead of silently included or rejected. A versioned record also improves roll-forward review and helps identify positions affected by changed program rules, entity structures, or evidence policies.

Limits/adoption considerations

Credit regimes often contain qualitative tests, aggregation rules, elections, interactions, caps, and recapture provisions that exceed a small formal vocabulary. Evidence quality and technical narratives require professional judgment. Setups and readback phrases should be reviewed for each program and period, and calculation logic must undergo separate validation. Tax confidentiality, financial-control requirements, documentation standards, model-risk controls, and examination readiness all shape adoption.
04Tax rule-change and scenario-consistency review service

System/use case

A scenario-review service compares tax treatments under different professional-approved rule, period, entity, or transaction assumptions. It helps teams identify which classifications, calculations, filings, and prior workpaper assumptions may require reconsideration after a rule update or business change.

Operational setting

The service supports tax planning, compliance readiness, provision forecasting, acquisition integration, and controlled rule maintenance. It uses versioned setup pairs, representative transaction or entity scenarios, source-effective dates, prior accepted propositions, and downstream dependency mappings. Numerical models and tax engines remain separate and carry their own parameter, formula, and validation controls.

Decision/claim boundary

A checked proposition may say that a scenario satisfying revised conditions enters a different review category or that conflicting treatments require escalation. It does not establish which rule version legally applies, predict an authority’s position, validate a forecast, calculate liability, or conclude that a prior return was incorrect. The tax owner authorizes interpretations and assumptions; accounting, legal, finance, and governance approvals remain applicable.

Candidate checked statements

Illustrative comparison statements include:

  • “Under the proposed setup version, every transaction in the revised covered category requires reclassification review.”
  • “If an accepted prior-period position depends on a changed definition, that position requires tax-owner reassessment.”
  • “If two approved rules assign incompatible treatments to the same entity, transaction, jurisdiction, and period, the scenario requires escalation.”

Example architecture

A tax knowledge registry retains source versions, interpretations, setup releases, and their owners. A dependency graph links accepted propositions to entity mappings, product rules, workpapers, return lines, controls, and calculation modules. A scenario orchestrator runs representative assertions through FF Scribe under baseline and proposed setups, preserving compiler results and deterministic readbacks. A structural diff and impact dashboard identify changed predicates and dependent artifacts. Separate tax engines calculate approved scenarios, while reconciliation and review workflows assess financial consequences. No configuration, filing, or ledger entry changes automatically from a formalization result.

Where verified readback fits

A tax professional describes the expected consequence for one rule version or a comparison scenario. The model constructs a proposition from the setup-scoped vocabulary, and Agda checks its formal validity. For a supported structure, the audited readback family deterministically states what was checked; unsupported translation fails visibly. The professional explicitly accepts a successful reading or provides feedback. A completed cycle creates a reliable object for comparison, not proof that the rule is complete, applicable, factually satisfied, or legally correct. It does not confirm that the intended business scenario was modeled until the practitioner accepts the readback.

Potential benefits

The service can make hidden assumptions visible, reveal dependencies affected by new definitions or period rules, and support a prioritized change backlog. Teams can compare alternatives in stable language and preserve why a configuration or position was reconsidered. Consistency checks can surface mutually incompatible treatments for human resolution before they propagate into billing, provision, compliance, or reporting systems.

Limits/adoption considerations

Rule interactions, transitional provisions, retroactivity, tax-treaty questions, accounting-tax differences, and uncertain authority may require specialized models or narrative analysis. Impact completeness depends on the dependency graph and source inventory. Adoption requires semantic versioning, effective-date governance, dual review for high-risk changes, reproducible data snapshots, scenario labeling, audit retention, and explicit retirement or supersession of stale accepted propositions. Professional authority remains the final control.
MLTTDB4 patterns
This catalogue expands the exemptions, nexus, credits, rule-mapping, and consistency themes in ~/nn-ff-web/content/domains/tax.md. It is illustrative and jurisdiction-neutral, with no assertion about current tax law, rates, thresholds, or filing obligations. Every model, scenario, and filing-related conclusion requires review by appropriately qualified tax and legal professionals.
01Indirect-tax nexus and registration position assurance

Operational context

A group sells goods, digital products, and services through direct and marketplace channels. Its tax function periodically reviews whether activity in each operating territory has crossed a modeled economic, physical-presence, or transaction threshold and whether a registration position needs attention. Finance systems can aggregate sales and operational facts, but rule matrices are difficult to govern across entity, channel, supply type, place-of-supply assumption, period, and exception. The target system validates a proposed review packet before tax professionals approve a position; it does not determine nexus itself.

Why MLTTDB fits

Proof-assistant types can force each threshold rule to declare its measure, currency or count unit, aggregation period, entity scope, channel treatment, effective interval, and exception model. Reviewed activity summaries can be stored as terms with explicit completeness and reconciliation status. Propositions can prohibit comparing incompatible units, require marketplace-facilitated activity to receive an explicit inclusion treatment, and return NeedsProfessionalReview when the available facts do not satisfy modeled evidence prerequisites. Stable UUIDs make rule and scenario changes traceable between review cycles.

Example architecture

ERP/commerce/locations -> governed tax data mart -> reconciled activity summaries
tax research service -> counsel-reviewed formal model -> model repository
summaries -> MLTTDB -> proof-assistant verification -> tax review -> registration workflow

The tax data mart owns normalized transactions, entity mappings, locations, currency conversions, and reconciliation to ledgers. Tax researchers maintain authority sources outside MLTTDB, and qualified reviewers approve their formal translation. A snapshot adapter emits only the aggregates and categorical facts required by the model. Verification results populate a position-review workbench. A separate compliance platform manages registrations, returns, correspondence, and deadlines after authorized approval.

Representative typed artifacts

Tables might include jurisdictionProfiles :T: JurisdictionProfile, thresholdRules :T: ThresholdRule, activitySnapshots :T: ActivitySnapshot, and positionProposals :T: PositionProposal. MeasuredAmount carries unit, currency basis, conversion date policy, and period; transaction counts are a different type. ActivitySnapshot distinguishes sourced data, adjustments, exclusions, and unresolved reconciliation items. A TaxPositionManifest aggregate term, reconciled to rule and activity exports, materializes the supply/channel taxonomy, effective rules, exceptions, and proposal UUIDs for whole-snapshot checks. Propositions check scope compatibility, period alignment, effective rules, and whether a proposed outcome is supported by the modeled threshold path. Agda rows may refer to earlier profiles by UUID; Lean/Rocq designs must use ordinary generated associations.

Checks and evidence

Model checks cover exhaustiveness of supply and channel categories enumerated by the reconciled manifest, incompatible threshold units, overlapping effective rules, and missing exception dispositions. Snapshot checks reject incomplete entity mappings, stale exchange-rate assumptions, unbalanced adjustments, and unsupported outcome reasons. Boundary suites test amounts and counts around modeled thresholds, short periods, channel changes, registrations already held, and ambiguous sourcing. The external evidence package retains data lineage, rule/activity/manifest reconciliation approval, rule-source references, model commit, ordered row UUIDs, verifier transcript, reviewer sign-off, and downstream registration action.

Potential benefits

Tax teams can review a consistent position packet instead of reconstructing rule and data assumptions in spreadsheets. Typed units reduce threshold-comparison errors, explicit unknown states prevent silent defaults, and scenario regression highlights territories affected by a model or business change. The approach can improve repeatability and division of responsibilities while leaving authority research and judgment with professionals.

Deployment boundary

MLTTDB does not source transactions, establish place of supply, determine nexus, interpret thresholds, perform currency conversion, register an entity, calculate tax, file returns, or guarantee data completeness. A formal result is conditional on the approved model and supplied facts. Production requires controlled tax research, ledger reconciliation, entity and channel governance, reviewer independence, filing calendars, access controls, monitoring, and manual escalation. Qualified tax and legal professionals approve every position.
02Exemption-certificate and transaction-treatment preflight

Operational context

A seller processes high-volume business transactions for which customer status, product classification, use, destination, and documentary evidence may affect indirect-tax treatment. Certificate management, ERP tax engines, and billing already execute the operational process. The assurance problem is ensuring that a proposed exemption or special-treatment decision uses a currently approved evidence state and a coherent combination of customer, product, and transaction facts before an invoice or retrospective correction is finalized.

Why MLTTDB fits

A typed model can distinguish a certificate’s existence from its validation status, scope, covered customer entity, applicable product or use category, territory, and effective period. Transaction projections can explicitly represent missing, disputed, expired, or not-required evidence. Proof obligations can require every proposed non-standard treatment to cite an eligible modeled basis and compatible evidence, while ensuring that unresolved mappings route to review. This is more expressive than validating independent ERP fields because the proof assistant checks their relationships.

Example architecture

customer master + certificate vault + order/ERP -> reconciliation service
approved treatment taxonomy -> proof model -----> MLTTDB review terms
preflight request -> verification service -> tax exception queue -> ERP tax engine

The certificate vault owns documents, validation events, and expiry monitoring. Master-data and product-taxonomy teams own customer and item mappings. A reconciliation service creates a versioned, minimal transaction projection and records source identifiers. MLTTDB stores the rendered source terms, and the proof-assistant path checks them against the reviewed model. An external exception service interprets pass/fail/indeterminate states under approved workflow controls; the ERP tax engine remains the runtime calculation and invoicing component.

Representative typed artifacts

Declarations could include evidenceProfiles :T: EvidenceProfile, treatmentRules :T: TreatmentRule, and transactionReviews :T: TransactionReview. A CertificateEvidence term includes validation disposition, covered party role, scope category, territory profile, and effective interval, but the underlying document remains in the vault. TransactionReview separates source-system assertions from tax-team-confirmed mappings. Propositions such as evidenceSupportsTreatment and treatmentMatchesSupply require compatible roles, periods, categories, and reason paths. Where Agda lookup is used, the evidence table must be declared before the dependent review table; same-table dependencies are topologically ordered, and cycles are invalid. Other backends need self-contained generated records.

Checks and evidence

Preflight rejects unknown certificate references, expired or out-of-scope evidence, mismatched customer entities, unsupported product/use combinations, and attempts to turn an indeterminate mapping into an exempt outcome. Regression fixtures cover partial exemptions, mixed orders, returns, credits, drop shipments, certificate replacement, and retrospective validation. A controlled evidence record combines transaction and master-data revisions, certificate-vault reference and status, model commit, ordered UUIDs, verifier output, tax reviewer disposition, and final ERP tax result. Periodic samples reconcile projections to invoices and documents.

Potential benefits

The design can reduce unsupported exemption overrides, make evidence assumptions visible, and focus tax reviewers on genuinely ambiguous transactions. Typed effective periods and party roles reduce common mismatches. Repeatable tests help teams assess rule, product-taxonomy, or certificate-workflow changes before release. Review evidence becomes easier to reconstruct without moving sensitive source documents into the term store.

Deployment boundary

MLTTDB does not authenticate certificates, determine exemption, classify products, validate customer identity, calculate tax, block an invoice, or establish that source facts are complete. It is not an immutable audit log or a certified tax engine. Document custody, electronic-signature checks, sanctions or fraud controls, retention, invoice workflow, calculation, reporting, and corrections remain external. Tax professionals approve treatment rules, exceptions, and material transaction positions.
03Tax credit or incentive eligibility workpaper assurance

Operational context

A corporate tax team evaluates projects and expenditure pools for a statutory credit or investment incentive. Engineers, finance staff, payroll teams, and external advisers contribute evidence about activities, assets, costs, funding, related parties, and time periods. The final position depends on professional interpretation and substantiation, but the workpaper set also has structural requirements: claimed cost categories must be allowed by the selected modeled route, exclusions must be applied consistently, and caps or interactions must use compatible bases.

Why MLTTDB fits

The proof model can separate technical-activity findings, accounting classifications, evidence status, and tax conclusions instead of flattening them into spreadsheet flags. Typed monetary amounts carry currency, period, entity, and gross/net basis. Propositions can require every included expenditure row to refer to a reviewer-confirmed qualifying activity category, apply modeled exclusions before caps, and prevent the same cost from being allocated twice within the formal dataset. An explicit Unresolved constructor preserves questions for specialist review.

Example architecture

project tools/payroll/ledger -> controlled workpaper data mart -> cost projections
tax and technical reviewers -> approved incentive model -> MLTTDB typed schedules
proof-assistant check -> exception/remediation loop -> signed position -> filing system

The data mart owns transaction lineage, allocation methods, currency conversion, and reconciliation to accounts. Technical reviewers record activity findings in the workpaper platform. Tax specialists own the legal interpretation and formal model. A schedule generator emits source-language terms for reviewed activities, expenditure pools, interactions, and expected computations. Verification findings return to the workpaper review loop. Only after human approval does a conventional tax calculation and filing process consume the signed schedule.

Representative typed artifacts

Candidate declarations include activityFindings :T: ActivityFinding, costPools :T: CostPool, incentiveRules :T: IncentiveRule, and claimSchedules :T: ClaimSchedule. CostPool records accounting source, allocation basis, related activity, entity, period, amount basis, and evidence status. The schedule generator builds each aggregate ClaimSchedule to enumerate every represented cost-pool UUID as candidate, excluded, unresolved, or proposed eligible, then reconciles that enumeration and its source digest to the workpaper export. Propositions check modeled route eligibility, allocation totals, incompatible funding interactions, effective periods, and that derived totals are assembled only from permitted constructors. Agda may use earlier UUID-addressed rule or activity rows; portable variants should generate ordinary associations for Lean and Rocq.

Checks and evidence

Validation rejects unit or period mismatches, unreviewed activities used as qualifying facts, double allocation, missing exclusion treatment, out-of-scope entities, and modeled cap computations over the wrong base. Scenario suites include mixed-use costs, partial periods, shared personnel, grant funding, related-party charges, asset disposals, and amendments. Evidence includes ledger and payroll reconciliation identifiers, allocation-method approval, technical review references, authority research links, model commit, ordered UUIDs, checker transcript, adjustments, and final tax sign-off. Independent recalculation compares exported totals with the filing workpaper.

Potential benefits

Teams can find structural workpaper defects before final review, preserve a clear boundary between technical findings and tax conclusions, and rerun the same schedules after rule or allocation changes. Typed amounts reduce basis and period errors, while proof obligations make inclusion and exclusion assumptions inspectable. The resulting evidence can improve review efficiency and repeatability across entities and claim periods.

Deployment boundary

MLTTDB does not determine that an activity or expenditure qualifies, verify invoices or timesheets, choose an allocation method, calculate an authoritative credit, value an asset, prepare a return, or defend a position. It proves only modeled propositions about supplied terms. Production use requires source-document controls, ledger reconciliation, technical and tax interviews, materiality judgment, transfer-pricing and accounting review where relevant, filing controls, retention, and qualified professional approval.
04Withholding and entity-classification position consistency

Operational context

A multinational accounts-payable or treasury function makes cross-border and domestic payments to vendors, investors, employees, and related entities. Payee classification, payment character, documentation, beneficial-owner assertions, exemptions or reduced-rate positions, and reporting obligations interact. Operational withholding engines apply configured rules, but tax teams need a pre-release consistency check that a reviewed payee/payment position and its documentation support the treatment configured for a payment stream.

Why MLTTDB fits

Formal types can keep legal entity classification, operational vendor type, payment character, documentation status, and proposed withholding treatment distinct. A proof assistant can enforce counsel-approved compatibility rules and require explicit escalation when classifications conflict or evidence is unavailable. Effective intervals and versioned rule profiles make it possible to replay representative payment positions after a policy update. MLTTDB’s ordered records and UUIDs support controlled reviewer evidence without pretending that the store validates documents or knows beneficial ownership.

Example architecture

vendor onboarding + entity master + payment hub -> tax-data reconciliation
tax research and position memos -> formal rule/profile repository
typed payment position -> MLTTDB verification -> tax approval -> withholding/reporting engine

Onboarding owns identity and documentation collection; the entity master owns party hierarchy and status; the payment hub owns instruments, amounts, and execution. A reconciliation adapter freezes the reviewed facts for a payment class or run and renders typed terms. Verification checks them under a pinned profile. Exceptions enter a tax work queue linked to source records and position memoranda. The existing withholding and reporting engine calculates, remits, reports, and corrects amounts only after its own approved controls.

Representative typed artifacts

Tables might include entityProfiles :T: EntityProfile, documentAssessments :T: DocumentAssessment, paymentClasses :T: PaymentClass, and withholdingPositions :T: WithholdingPosition. DocumentAssessment expresses reviewed status, claimed role, scope, effective interval, and source reference—not authenticity. WithholdingPosition records the selected rule profile, payment character, payee role, evidence basis, and proposed treatment category. A WithholdingPositionManifest aggregate term, reconciled to entity, document, payment-run, and row exports, enumerates the positions whose cross-payment consistency is checked. Propositions test classification consistency, document scope and currency, permitted position/reason combinations, and escalation for contradictory assertions. Agda can link earlier entity and document rows by UUID; Lean/Rocq deployments must not assume such lookup.

Checks and evidence

Checks flag mismatched legal and operational entities, incompatible payment character and position, expired or out-of-scope documentation, unresolved beneficial-owner assertions represented as facts, inconsistent treatment across the same reviewed payment class, and rule profiles outside their modeled period. Scenario suites cover split payments, intermediaries, entity changes, multiple documentation claims, refunds, corrections, and late evidence. External evidence combines master-data and payment-run revisions, document-vault references, position memo and authority links, model commit, ordered UUIDs, verifier output, reviewer approval, engine result, and reconciliation to reporting.

Potential benefits

The tax function gains a consistent vocabulary across onboarding, treasury, payables, and reporting. Contradictions can reach a reviewer before payment release or filing, and model changes can be tested against stable representative positions. Explicit unknown and disputed states reduce unsafe defaulting. The evidence bundle makes clear which data and approved assumptions supported a configuration decision.

Deployment boundary

MLTTDB does not classify an entity or payment under law, authenticate documentation, establish beneficial ownership, choose a rate, calculate or remit withholding, file information returns, or guarantee treaty or statutory eligibility. It is not a screening or payment-control system. Identity verification, sanctions controls, document custody, tax research, calculations, payment execution, reporting, corrections, appeals, access, and monitoring remain external. Qualified tax and legal professionals approve the formal model and every material position.
State Machine Studio3 demos
SMCross-Border VAT Treatment

This example represents the control path for determining and reporting VAT on a cross-border supply. It connects the commercial facts—supplier and customer status, goods or services, establishments, movement, consideration, and invoice jurisdiction—to the resulting place-of-supply analysis, rate or relief, invoicing, ledger posting, return disclosure, and input-tax recovery position.

The workflow starts with transaction intake because VAT treatment cannot be selected reliably from an invoice label alone. The relevant parties, movement or performance facts, jurisdictions, and period are captured before the supply is classified. Classification distinguishes goods from services, considers customer status and establishment, and handles composite supplies, chains, and intermediaries. Incorrect or incomplete facts return to intake. The tax-treatment review then applies the controlling jurisdictional rules to decide whether the supply is taxable, exempt, zero-rated, or subject to reverse charge, and verifies identifiers and transport or other supporting evidence.

An approved treatment moves to invoicing and the ledger, where mandated statements and tax fields are produced, output and recoverable input VAT are posted, and evidence is linked to the entry. Reporting assigns the transaction to the correct jurisdictional return fields and supplementary reports and reconciles invoice, ledger, and transport records. Conflicts in either posting or reporting open a treatment exception. A repair may correct the invoice or posting and return to that stage, or may require a fresh treatment analysis. Closure records the submitted treatment and recoverability outcome only after reporting is complete.

These controls matter because the same commercial supply can produce different VAT consequences when customer status, establishment, movement, evidence, or the rule period changes. A missing identifier or transport document may defeat a relief even when the commercial facts otherwise support it. Connecting the rule path to invoice, ledger, return, and evidence reduces inconsistent treatments, blocked recovery, duplicate taxation, and amendments that cannot be explained to auditors or authorities.

Layer 1 — VAT treatment lifecycle

This is the VAT lead’s end-to-end view: intake, classification, treatment decision, invoicing and posting, reporting, exception remediation, and period close. It exposes the principal decision gates and the paths back when facts or treatment change. It intentionally omits invoice fields, ledger accounts, return boxes, and individual evidence documents so the overall control status remains clear.

Layer 2 — Classification and reporting procedures

This layer is used by indirect-tax specialists and reporting teams. It covers supply classification, place-of-supply dependencies, customer and establishment analysis, relief and reverse-charge criteria, invoice requirements, ledger treatment, return allocation, reconciliation, and amendments. It includes the procedural handoffs between tax determination and reporting but excludes the atomic validation or posting actions performed for each transaction.

Layer 3 — Transaction evidence actions

This layer shows the auditable actions on a particular supply: capturing VAT identifiers and movement facts, testing transport evidence, generating invoice statements, linking documentation to ledger entries, reconciling transaction populations, and recording blocked recovery or corrected treatment. It intentionally excludes portfolio-level period management and policy ownership, which belong in the broader layers.
Open interactive model
SMResearch Credit Qualification and Substantiation

This example represents preparation of a research-credit claim in which qualification, cost capture, calculation, and substantiation remain tied together. It is organized around projects, activities, entities, and tax periods because a general statement that a company performs innovative work is not enough. The claim must show which work was evaluated, which qualifying conditions were met, which expenditures relate to that work, and what evidence supports those conclusions.

The cycle starts with a project inventory. Candidate projects are associated with technical objectives and responsible substantiation owners. Activity qualification then maps the actual work to each applicable condition, separates routine or excluded activity, and records the technological uncertainty and process of experimentation. An incomplete inventory loops back for correction before costs are classified, preventing payroll or contractor amounts from driving qualification after the fact.

Cost classification associates wages, supplies, and contracted research with qualified activities, applies allocation and related-party rules, and removes amounts outside the qualifying period. The claim calculation aggregates those costs using the selected method and applicable limitations, then reconciles the result to return workpapers. Substantiation review samples costs back to project evidence, checks that the correct rule and period assumptions were used, and resolves unsupported amounts. A finding opens a claim exception with a named owner and explicit treatment. Depending on the gap, remediation returns to activity qualification or cost classification; changed amounts are recalculated before approval. Finalization occurs only when the supported amount and disclosures are approved and the evidence trail is archived.

The controls matter because research-credit exposure usually arises at the seams: a technically credible project with weak contemporaneous evidence, an eligible activity with an unsupported allocation, or a correct calculation built from an overstated cost pool. Keeping every amount connected to qualification and evidence supports review, reduces inconsistent treatment across business units, and makes exclusions and revisions as traceable as the claimed benefit.

Layer 1 — Credit claim lifecycle

This is the tax provision and claim-governance view. It follows the claim from project population through qualification, cost classification, calculation, review, exception resolution, and final approval. It highlights readiness and major rework loops across entities and periods. It deliberately excludes individual time records, invoices, test artifacts, and formula cells so reviewers can see whether the claim as a whole has reached a defensible stage.

Layer 2 — Qualification and substantiation procedures

This is the procedure-level view used by tax specialists, technical interviewers, finance owners, and reviewers. It covers project scoping, activity-by-activity analysis, allocation methods, calculation controls, sampling, review findings, and routed remediation. It includes who must resolve a gap and which earlier decision must be revisited, while excluding the atomic evidence checks performed on each source record.

Layer 3 — Evidence-level actions

This layer represents the workpaper and source-evidence actions: linking objectives to technical records, documenting uncertainty and experimentation, tracing wages and supplies, applying period and related-party tests, retaining calculation inputs, and recording reviewer dispositions. It is detailed enough to reproduce an included or excluded amount. It intentionally leaves claim-wide approval and portfolio status to the higher layers.
Open interactive model
SMMulti-State Sales-Tax Nexus and Filing

This example represents the operating cycle a tax department uses to decide where a business has a sales-tax obligation and then carry that decision through registration, collection, return preparation, and period close. It is deliberately jurisdiction- and period-aware: a threshold, exclusion, marketplace-facilitator provision, or product treatment may be correct in one state and filing period but wrong in another.

The workflow begins with activity monitoring. Direct and marketplace sales, transaction counts, and physical-presence events are accumulated by jurisdiction and effective period. A nexus review applies the relevant definition and threshold rather than treating a national sales total as the deciding fact. Activity below the applicable threshold returns to monitoring; established nexus moves into registration. Registration status and effective dates then govern when collection can be activated. Once collection is active, the tax engine’s rates and product mappings, exemption certificates, and collected-tax totals must stay aligned with the approved posture.

At filing time, transaction sources and collected tax are reconciled, adjustments and exemptions are assigned to the correct return lines, and the return and remittance are prepared. Missing transaction data, a rejected return, or a payment variance opens a filing exception instead of being hidden in the close process. A repair may return the case to filing preparation, while evidence that the underlying activity was classified incorrectly sends it back to activity monitoring and nexus analysis. The period closes only after acceptance and remittance reconciliation, with the jurisdictional posture carried into the next monitoring period.

These controls matter because nexus and collection failures can create uncollected liabilities, customer overcharges, late registrations, penalties, and inconsistent positions across jurisdictions. The model keeps the rule version, activity facts, exemption support, return treatment, and remediation path connected so reviewers can reproduce why the business registered, collected, filed, amended, or remained below threshold.

Layer 1 — Tax posture lifecycle

This layer is the tax director’s portfolio view: monitoring, nexus determination, registration, active collection, filing, exception handling, and period close. It answers where each jurisdiction stands and what major obligation comes next. It intentionally excludes individual return lines, certificate checks, and transaction calculations so the end-to-end posture and escalation routes remain readable.

Layer 2 — Nexus and filing procedures

This layer is the working view for state-and-local tax and compliance teams. It covers threshold testing, marketplace and physical-presence classification, registration effective dates, collection configuration, return reconciliation, amendments, extensions, and reassessment. It includes the handoffs and control decisions that move a jurisdiction between stages, but excludes the lowest-level source-system commands and field-by-field execution.

Layer 3 — Transaction-level actions

This layer shows the evidence-bearing work behind each procedure: aggregating jurisdictional sales and counts, checking exclusions, validating exemption certificates, assigning adjustments to return lines, reconciling tax collected, and documenting corrections. Its scope is an auditable transaction or filing action. It intentionally does not restate enterprise tax policy or summarize the overall jurisdiction portfolio; those decisions are represented in the higher layers.
Open interactive model
Explore patternsReview product applications

Cabinet index

Explore Formal Foundry

Search the archive

Find a page

Type to search the published content.