Federal civilian · Moraph software

Tax Code "Rule-as-Code" Engine

Draft tax rules once, in a form people can review and processing systems can run

Book a demonstrationRequest a technical briefingFactsheet

Overview

What you are buying

The Tax Code Rule-as-Code Engine lets tax law specialists write rules in a structured, readable format that is tied clause by clause to the statute, regulation or guidance it implements. Each rule is tested against worked examples, reviewed by counsel and released as a versioned, machine-readable package that downstream processing systems consume. The link from legal text to running logic stays visible for every version, so reviewers can see what changed and why.

The problem it solves

When tax law changes, policy specialists describe the change in documents, developers interpret those documents into code in several processing systems, and testers try to confirm the result matches the law. Each hand-off is a chance for the meaning to drift. The same rule can be implemented differently in different systems, effective dates are tracked separately from the logic, and when a question arises about why a calculation behaves as it does, tracing it back to the legal text means reading code and old requirement documents side by side.

  • Legal text is re-interpreted by hand at each hand-off from policy to code
  • The same provision can be implemented differently in different systems
  • Effective dates and transition rules are tracked separately from the logic
  • Tracing a calculation back to the clause that requires it is slow and uncertain

Who uses it

  • Tax administration agencies implementing changes to tax law and guidance
  • Tax law specialists and policy analysts who interpret new provisions
  • Counsel who review the legal reading of each rule
  • Engineering teams who maintain tax processing and forms systems
  • Testing, audit and oversight staff who need to trace logic to law

Requirements it supports

Internal Revenue Code (Title 26, U.S. Code)Treasury Regulations (26 CFR)Confidentiality of returns and return information (26 U.S.C. 6103)Taxpayer Bill of Rights (26 U.S.C. 7803(a)(3))Federal Information Security Modernization Act of 2014 (FISMA)Section 508 of the Rehabilitation Act

The product supports these requirements; meeting them remains your organization’s responsibility.

See how it works

A short walkthrough

Illustrative screens with fictional sample data. They show the workflow, not any client’s data or configuration, and the layout of the product itself differs. A live demonstration uses the product with sample data.

  1. Step 1

    Rules in progress

    Specialists and reviewers start from a list of rules by provision, status and effective date.

    RuleProvisionVersionEffective fromStatusOpen questions
    R-1042 Sample credit phase-outExample section 101(a) (fictional)v3Tax year 20X6In legal review1
    R-1038 Sample dependent definitionExample section 152 (fictional)v5Tax year 20X6Approved0
    R-1051 Sample deduction limitExample section 210(b) (fictional)v1Tax year 20X7Drafting3
    R-0977 Sample filing thresholdExample section 60(c) (fictional)v8Tax year 20X5Released0
    R-1047 Sample transition reliefExample act section 4 (fictional)v2Tax year 20X6Tests failing0
    Specialists and reviewers start from a list of rules by provision, status and effective date.

  2. Step 2

    A rule beside its source

    Each part of the rule sits beside the clause it implements, so reviewers read the law and the logic together.

    R-1042 · Sample credit phase-out (fictional provision)

    Source
    Example section 101(a) (fictional)
    Effective from
    Tax year 20X6
    Inputs
    Filing status, modified income, number of qualifying persons
    Uses definitions
    Qualifying person (R-1038 v5), modified income (R-0912 v2)
    Output
    Credit amount after phase-out

    Rule steps

    • Base amount per qualifying person (clause (1))
    • Threshold by filing status (clause (2))
    • Reduction per increment of income above threshold (clause (3))
    • Credit not reduced below zero (clause (4))
    Each part of the rule sits beside the clause it implements, so reviewers read the law and the logic together.

  3. Step 3

    Testing against worked examples

    Every change is run against the example set, and any example with a different result is shown with the step where it diverged.

    ExampleScenarioExpectedResultStatus
    EX-01Single filer, income below threshold (synthetic)$1,200$1,200Pass
    EX-02Joint filers, income at threshold (synthetic)$2,400$2,400Pass
    EX-03Joint filers, period spanning transition date (synthetic)$1,800$2,400Fail at step 2
    EX-04Head of household, no qualifying person (synthetic)$0$0Pass
    Every change is run against the example set, and any example with a different result is shown with the step where it diverged.

  4. Step 4

    Explaining a result

    Any result can be traced step by step, with the values used and the clause behind each step.

    EX-03 · R-1047 v2 (synthetic example)

    1. Filing status: joint (input)Example data
    2. Transition provision applies to periods beginning before the change dateClause 4(a)
    3. !Period start date not compared with change date; full amount usedStep 2
    4. Base amount $2,400 appliedClause 4(b)
    5. Result $2,400; expected $1,800Test
    Any result can be traced step by step, with the values used and the clause behind each step.

  5. Step 5

    Legal review

    Counsel reviews the reading of the law with comments on specific clauses, and interpretation questions are answered on the record.

    R-1042 v3 · Legal review

    Drafted by
    Tax law specialist (sample user)
    Second specialist review
    Complete
    Examples
    24, all passing
    Changes from v2
    Threshold amounts, rounding rule
    Legal reviewer
    Assigned

    Open interpretation question

    • Clause (3): is the reduction rounded per increment or on the total?
    • Specialist reading: on the total, per example guidance (fictional)
    • Example EX-17 depends on the answer
    Counsel reviews the reading of the law with comments on specific clauses, and interpretation questions are answered on the record.

  6. Step 6

    Preparing a release

    Approved versions are grouped into a release, published to a test channel, and promoted once consuming teams confirm their tests.

    RuleVersionChangeConsuming systemsTheir testsStatus
    R-1042 Sample credit phase-outv3Threshold amounts2PassedReady
    R-1038 Sample dependent definitionv5Age test wording41 of 4 pendingWaiting
    R-0912 Sample modified incomev2No change3PassedReady
    Approved versions are grouped into a release, published to a test channel, and promoted once consuming teams confirm their tests.

Workflows

The principal workflows

  1. Draft

    A tax law specialist opens the provision being implemented and writes the rule in a structured format of definitions, conditions, calculations and effective dates, with each part linked to the clause it comes from.

    • Legal source loaded: statute, regulation, notice or internal guidance
    • Specialist marks the clauses the rule implements
    • Definitions, conditions and calculations written in the rule format
    • Effective dates and transition provisions recorded on the rule
    • Open questions on interpretation raised for counsel

  2. Test

    Each rule is run against worked examples written by the specialist, including edge cases and examples from published guidance, so the logic is checked before anyone downstream relies on it.

    • Specialist writes worked examples with the expected result
    • Engine runs the rule against every example
    • Failures shown with the step where the result diverged
    • Examples from earlier versions re-run to show what changed
    • Test set saved with the version as evidence

  3. Review

    Counsel and a second specialist review the rule beside its legal source, the interpretation notes and the test results, and approve or return it.

    • Rule, source text and examples shown side by side
    • Reviewer comments on specific clauses or conditions
    • Interpretation questions answered and recorded
    • Legal reviewer approves the reading of the law
    • Release manager approves the version for publication

  4. Publish

    Approved rule versions are released as a versioned, machine-readable package that processing systems consume through an API or file export, with release notes describing what changed.

    • Approved versions grouped into a release
    • Release notes generated from the changes and edited by the release manager
    • Package published to a test channel for consuming systems
    • Consuming teams confirm their tests pass
    • Release promoted to production with its effective dates

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Tax law specialist

Tax law specialist, policy analyst, technical writer for tax rules

Turns legal text into rules, with the reading, examples and citations written down.

Sees

  • Rules assigned to them or their team, with their source text
  • Worked examples and test results
  • Comments and interpretation questions on their rules
  • Shared definitions and where they are used

Does

  • Drafts and edits rules in the structured format
  • Links each part of a rule to its clause
  • Writes worked examples with expected results
  • Runs tests and fixes failures
  • Raises interpretation questions for counsel

Cannot

  • Approve the legal reading of their own rule
  • Publish or promote a release
  • Change shared definitions without review
Approvals
Every rule version they draft is reviewed by a second specialist and approved by a legal reviewer.
Notified about
Comments on their rules, answered questions, failing tests and rules returned for changes.

Legal reviewer

Attorney, counsel, senior technical reviewer

Confirms that each rule reads the law correctly before it is released.

Sees

  • Rules sent for legal review, with source text, examples and test results
  • Interpretation questions and the specialist's proposed answers
  • Earlier versions and their approvals

Does

  • Comments on specific clauses and steps
  • Answers interpretation questions on the record
  • Approves the legal reading or returns the rule
  • Requests additional examples

Cannot

  • Edit the rule directly; changes go back to the specialist
  • Approve a rule they drafted
  • Publish a release
Approvals
Their approval is required before a rule version can be included in a release.
Notified about
Rules waiting for legal review and questions assigned to them.

Rules engineer

Rules engineer, software engineer, technical architect

Maintains the shared structures and integrations that rules depend on.

Sees

  • All rules and shared definitions
  • Dependencies between rules, forms and consuming systems
  • Package formats and integration logs

Does

  • Builds and maintains shared definitions and reusable structures
  • Helps specialists model complex provisions
  • Maintains package formats and integrations with consuming systems
  • Investigates test failures with specialists

Cannot

  • Approve a legal reading
  • Promote a release to production
  • Change an approved rule version; a new version is required
Approvals
Changes to shared definitions go through the same review and legal approval as rules.
Notified about
Integration failures, test failures in shared definitions and requests for help from specialists.

Release manager

Release manager, implementation program manager

Decides what goes into each release and when it is promoted to consuming systems.

Sees

  • Approved rule versions waiting for release
  • Consuming systems and their test status for each release
  • Release history and notes

Does

  • Groups approved versions into releases
  • Edits release notes
  • Publishes releases to the test channel
  • Promotes releases to production once consuming teams confirm
  • Withdraws a release from the test channel when needed

Cannot

  • Include a rule version without legal approval
  • Edit rules
  • Promote a release they drafted rules in without a second release approver
Approvals
Promotion to production is recorded with the release manager's approval and, where your agency requires it, a second approver.
Notified about
Rule versions approved and ready for release, and consuming teams' test results.

Consuming system team

Processing system developer, test lead, system owner

Brings released rules into the systems that apply them to returns and accounts.

Sees

  • Released and test-channel packages
  • Release notes and version comparisons
  • Rule text and traces for the rules their system uses

Does

  • Downloads or subscribes to packages
  • Runs their own tests and records the result
  • Raises questions on rule behavior
  • Confirms readiness for promotion

Cannot

  • Edit or approve rules
  • See rules still in drafting unless granted
  • Promote releases
Approvals
Their confirmation is one input to the release manager's decision to promote.
Notified about
New test-channel releases and answers to their questions.

Auditor or oversight reviewer (read-only)

Internal auditor, inspector general staff, oversight reviewer (under temporary access)

Reviews how rules were drafted, tested, approved and released without being able to change anything.

Sees

  • Rules, versions and their source citations within scope
  • Tests, comments and approvals
  • Release history
  • The audit trail

Does

  • Searches and reads records within their scope
  • Exports records and reports, with each export logged
  • Leaves review notes where enabled

Cannot

  • Change, approve or release anything
  • See records outside the scope and dates granted
  • Keep access after it expires
Approvals
Their access is approved by an agency official and an administrator, with a scope and an end date.
Notified about
Nothing by default; access granted and expiring is confirmed to the person who approved it.

Administrator

Application administrator, IT systems administrator

Manages users, roles and configuration.

Sees

  • Users, roles and teams
  • Review step and approver settings
  • The record of permission changes

Does

  • Adds and removes users, or maps them from single sign-on groups
  • Assigns roles and teams
  • Maintains review steps and approver lists
  • Runs access review reports

Cannot

  • Edit or approve rules
  • Grant themselves an approver role without a second administrator
  • Promote releases
Approvals
Changes to approver lists are approved by the program owner your agency designates.
Notified about
Access reviews due and accounts unused for a period your policy sets.

Permissions at a glance

ActionSpecialistLegal reviewerRules eng.Release mgrConsumer teamAuditorAdmin
Draft and edit rulesOwn work onlyNo accessFullNo accessNo accessNo accessNo access
Write worked examples and run testsOwn work onlyView onlyFullView onlyView onlyView onlyNo access
Comment and raise interpretation questionsFullFullFullView onlyFullView onlyNo access
Answer interpretation questionsNo accessFullNo accessNo accessNo accessView onlyNo access
Approve the legal readingNo accessApprovesNo accessNo accessNo accessNo accessNo access
Change shared definitionsNo accessApprovesFullNo accessNo accessNo accessNo access
Publish to the test channelNo accessNo accessNo accessFullNo accessNo accessNo access
Promote a release to productionNo accessNo accessNo accessApprovesNo accessNo accessNo access
Record consuming system test resultsNo accessNo accessNo accessView onlyOwn work onlyView onlyNo access
View audit trailNo accessView onlyView onlyView onlyNo accessView onlyView only
Manage users and rolesNo accessNo accessNo accessNo accessNo accessNo accessFull
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Separation is built in: nobody approves the legal reading of a rule they drafted, and a rule cannot be released without legal approval.
  • Unreleased rules can be limited to the specialists, reviewers and engineers working on them, while released rules are visible to consuming teams.
  • Every change to a user's role or access is recorded in the audit trail, and access review reports list each person's roles for periodic certification.
  • Staff sign in through your agency's identity provider, and roles can follow its groups. Auditors and oversight reviewers get temporary read-only access with a defined scope and an end date.

Features

What it does

Structured rule format

Rules are written as definitions, conditions, calculations and effective dates in a format specialists can read and processing systems can run.

Clause-level citations

Every part of a rule links to the clause of statute, regulation or guidance it implements, and the link is kept across versions.

Effective dating

Rules carry effective and end dates, and transition provisions are modeled explicitly, so the right version applies to each tax period.

Worked-example testing

Specialists write examples with expected results, and every rule change is run against the full example set.

Step-by-step trace

Each result can be explained step by step, showing the conditions met, values used and the clause behind each step.

Version comparison

Compare two versions of a rule to see changed conditions, calculations, dates and citations, and which examples now give a different result.

Review and approval

Clause-level comments, recorded interpretation questions and answers, and separate approvals for the legal reading and for release.

Shared definitions

Terms used across many provisions are defined once and referenced, so a change to a definition shows every rule it affects.

Release packages

Approved versions published as versioned packages with release notes, for consumption by API or file export.

Impact view

Before release, see which rules, forms and consuming systems a change touches, from the dependencies recorded in the engine.

Synthetic test data

Worked examples use constructed scenarios rather than real return information, so testing does not require access to taxpayer data.

Audit trail

Every edit, test run, comment, approval and release recorded with the person and time.

Integrations

How it connects to your systems

Connects toHowWhat flows
Tax processing systemsReleased rule packages are consumed by your processing systems through the engine's API or a scheduled file export, in a format agreed during implementation.Out: versioned rule packages and release notes.
Legal source libraryStatutory, regulatory and guidance text loaded from the sources your agency uses, with versions kept as the text changes.In: legal text and its publication dates.
Source control and build pipelinesRule packages can be exported to your source control and continuous integration tools so consuming teams test them like any other dependency.Out: rule packages and example sets. In: test results from consuming teams.
Requirements and work trackingRule changes can be linked to the work items your agency uses to manage legislative implementation.Out: rule status and release links. In: work item references.
Forms and instructionsRule references can be shared with the teams that produce forms and instructions, so they can check that the published guidance and the logic agree.Out: rule summaries and citations by form line, where mapped.
Single sign-onStaff sign in through your agency's identity provider, including PIV-based authentication where your provider supports it.In: user identity and group membership for role assignment.
Work APIRule, version, test and approval data available to your reporting tools through the Moraph Work API.Out: rule status, test results, approvals and releases.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

Hosted in the United States

Rules, examples and review records are hosted in the United States region.

Cleared support lane

Support tickets from federal clients are routed only to US citizens with active security clearances.

Access by role

Drafting, legal approval and release are separate permissions, and unreleased rules can be limited to the people working on them.

Encryption under controlled keys

Client data is encrypted with keys our staff cannot access without explicit, time-bound authorization.

Complete audit trail

Every edit, test, approval and release is recorded with the user and time, and cannot be edited.

Independent audits

Moraph's controls are covered by its SOC 2 Type II report and ISO/IEC 27001 certification, available through the Trust Center.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

10 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Operational

Rules by status

For specialists, team leads and release managers

Every rule and version with its status, owner, effective date and open questions.

Break down by
Status, Provision, Team, Effective date
Delivered as
Live dashboard; CSV export
Used for
Seeing what is ready, what is blocked and what is due for an upcoming tax period.

Open interpretation questions

For legal reviewers and team leads

Questions raised on rules, who they are with and how long they have been open.

Break down by
Rule, Assignee, Age, Provision
Delivered as
Live dashboard; scheduled email
Used for
Keeping legal questions from holding up implementation.

Test status

For specialists and rules engineers

Example results for every rule version, with failures and the step where each diverged.

Break down by
Rule, Version, Result, Run date
Delivered as
Live dashboard
Used for
Fixing failures before review.

Release

Release readiness

For release managers and consuming teams

Each release with its rule versions, approvals and consuming systems' test results.

Break down by
Release, Rule, Consuming system, Status
Delivered as
Live dashboard; PDF
Used for
Deciding whether a release can be promoted.

Adoption by consuming system

For release managers and program leadership

Which release each consuming system is using and which systems are behind.

Break down by
Consuming system, Release, Date adopted
Delivered as
Live dashboard; CSV export
Used for
Making sure every system applies the same version of the law.

Release notes

For consuming teams, forms teams and leadership

What changed in each release, by rule, with citations and effective dates.

Break down by
Release, Provision, Change type
Delivered as
PDF; in product
Used for
Communicating changes to everyone who depends on the rules.

Program

Clause coverage

For program leadership and policy managers

Which clauses of the provisions in scope have rules linked to them and which do not.

Break down by
Provision, Coverage status, Team
Delivered as
Live dashboard; CSV export
Used for
Planning which provisions to model next and showing implementation progress.

Implementation progress for a law change

For program leadership

For a selected act or set of provisions, the rules drafted, reviewed, approved and released.

Break down by
Provision, Status, Effective date
Delivered as
Live dashboard; PDF
Used for
Reporting on implementation of new legislation.

Audit and oversight

Rule change history

For auditors, oversight reviewers and counsel

Every version of a rule with its changes, tests, reviewers, legal approver and release.

Break down by
Rule, Version, Approver, Date
Delivered as
Live view; PDF and CSV export
Used for
Showing how and why logic changed and who approved it.

Audit trail extract

For auditors and oversight reviewers

Who did what, when and why for a selected rule, release or period.

Break down by
Record, User, Action, Date range
Delivered as
On request in the product; CSV and PDF export
Used for
Answering audit requests without assembling evidence by hand.

Exports, access and evidence

  • Any report can be exported to CSV, and summary and evidence reports to PDF; reports can be scheduled to arrive by email for the people entitled to see them.
  • Filters can be saved as personal or team views, and reports that need a different shape can be built in your own tools from the data described below.
  • Rule, test, approval and release data is available through the Moraph Work API for your agency's reporting and work-tracking tools.
  • Reports follow each person's role: unreleased rules appear only to people working on them, and consuming teams see released rules and their own test results.
  • Audit reports can be run as of a past date and give the same result each time, and every report run and export is recorded in the audit trail.

Deployment

Where and how it runs

Moraph cloud, United States

Hosted in the United States region, with data kept in the US.

Dedicated environment

A single-tenant environment for agencies that require isolation, scoped in the proposal.

Rule packages run in your systems

Released packages are executed by your own processing systems or by an execution component installed in your environment, so production calculations do not depend on Moraph's cloud.

With a managed service

Optionally run alongside a Moraph managed service for administration, rule-engineering support and integration support.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

Scope and pilot provisions

We agree with your policy and engineering leads which provisions to model first, usually a recent change with known expected results.

Rule format and conventions

Drafting conventions, shared definitions and citation styles are agreed with your specialists and counsel, and documented.

Legal source loading

The statutory, regulatory and guidance text in scope is loaded and versioned, with your team confirming the sources.

Consuming system integration

The package format and delivery method are agreed with one consuming system team, and their tests are run against the first release.

Roles and approvals

Roles, review steps and approvers are configured to match your agency's procedures for legal review and release.

Training and handover

Specialists, reviewers and engineers are trained on drafting, testing and release, and Moraph works alongside your team on the first provisions.

Limitations

What it does not do

Worth knowing before you evaluate it.

  • It does not interpret the law for your agency. Every rule reflects the reading of your specialists and counsel, and Moraph does not provide tax or legal advice.
  • It does not process returns or hold taxpayer accounts. Your processing systems run the released rules.
  • Some provisions depend on judgment, facts and circumstances that cannot be reduced to conditions and calculations; these are recorded as inputs a person or system must supply, not decided by the engine.
  • A rule is only as reliable as its worked examples. Testing shows the rule matches the examples written, not that the examples cover every case.
  • Moraph holds no FedRAMP authorization for this product. We provide control documentation to support your agency's own authorization decision.
  • Existing logic in legacy processing systems is not converted automatically; provisions are modeled in the engine as your agency chooses to bring them across.
  • Consuming systems must be changed to read the released packages, and that work sits with the teams that own them.
  • It is designed for tax provisions. Other areas of law can be modeled but are outside the conventions delivered at implementation.

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

  1. Ask a specialist to model a recent provision and judge whether counsel could review it without help
  2. Check that every step of a rule traces to a specific clause
  3. Write edge-case examples, including a transition period, and review how failures are explained
  4. Compare two versions of a rule and confirm the differences shown are complete
  5. Have an engineering team consume a test release in a non-production system
  6. Confirm role separation: who can draft, approve the legal reading and release

Questions

Frequently asked questions

Do policy specialists need to write code?

No. Rules are written in a structured format of definitions, conditions and calculations that specialists can learn without programming. Rules engineers support more complex structures.

Does the engine decide how the law should be read?

No. Your specialists draft the reading and your counsel approves it. The engine records the reading, tests it and keeps the link to the legal text.

Do we need taxpayer data to test rules?

No. Worked examples are built from constructed scenarios. If your agency chooses to test against return information, that happens within your own systems and under your own controls.

How do our processing systems use the rules?

They consume released packages through an API or file export, or through an execution component installed in your environment. The format is agreed with your engineering teams during implementation.

Is it FedRAMP authorized?

No. Moraph holds no FedRAMP authorization for this product. We provide control documentation to support your agency's own authorization decision.

How do we try it before buying?

A demonstration uses fictional provisions. For a deeper evaluation, your specialists can model a recent provision with known expected results and compare the engine's output with your current implementation.

Next steps

Evaluate Tax Code "Rule-as-Code" Engine

Book a demonstration

See the product working with sample data, focused on your workflows.

Request a demonstration

Request a technical briefing

Architecture, integrations, security and hosting, with our engineers and your technical team.

Request a briefing

Factsheet

This page on two sides, to share with colleagues or add to your evaluation file.

Open the factsheet

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Tax Code "Rule-as-Code" Engine guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Tax Code "Rule-as-Code" Engine support guide.

Related products