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.
01 Indirect-tax nexus and registration assessment workbench Explore pattern
System/use case
Operational setting
Decision/claim boundary
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
Where verified readback fits
Potential benefits
Limits/adoption considerations
02 Exemption and certificate eligibility control Explore pattern
System/use case
Operational setting
Decision/claim boundary
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
Where verified readback fits
Potential benefits
Limits/adoption considerations
03 Tax-credit and incentive qualification workpaper assistant Explore pattern
System/use case
Operational setting
Decision/claim boundary
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
Where verified readback fits
Potential benefits
Limits/adoption considerations
04 Tax rule-change and scenario-consistency review service Explore pattern
System/use case
Operational setting
Decision/claim boundary
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
Where verified readback fits
Potential benefits
Limits/adoption considerations
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
Why MLTTDB fits
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
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
Potential benefits
Deployment boundary
02 Exemption-certificate and transaction-treatment preflight Explore pattern
Operational context
Why MLTTDB fits
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
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
Potential benefits
Deployment boundary
03 Tax credit or incentive eligibility workpaper assurance Explore pattern
Operational context
Why MLTTDB fits
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
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
Potential benefits
Deployment boundary
04 Withholding and entity-classification position consistency Explore pattern
Operational context
Why MLTTDB fits
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
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
Potential benefits
Deployment boundary
These read-only, pan-and-zoom models expose three abstraction levels for each workflow. They are explanatory examples, not live operational or decision systems.
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
Layer 2 — Classification and reporting procedures
Layer 3 — Transaction evidence actions
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
Layer 2 — Qualification and substantiation procedures
Layer 3 — Evidence-level actions
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.