TEN PRACTICAL COMMITMENTS
Principles that show up in the work.
These ideas are useful only if they change how the software behaves: what it asks, what it preserves, what it calculates and what it lets the professional control.
Built inside a tax practice.
Designed around the work.
Accountable to the preparer.
Build for the straightforward majority.
Conventional returns can be substantial. Multiple owners, payroll, fixed assets, distributions, shareholder debt and inventory do not automatically make a business exotic. The workflow should respect that complexity without making every return carry every rare-case branch.
The straightforward 90% is a design ambition, not a measured coverage statistic. Define the intended universe, make it work coherently, and expand it deliberately.
Define straightforwardStart with the evidence.
Preparation begins with documents, financial information, history and facts established by the professional. When useful information is already present, the next task should be reviewing it rather than typing it again.
Evidence does not have to be a perfectly parseable attachment. A supported manual workpaper can establish information too. The system should make the origin clear and ask for the decisions the evidence cannot supply.
Follow the preparation pathNever erase provenance.
The original source, the software’s interpretation and the preparer’s established fact have different meanings. A correction should preserve those differences, with a reason and a history.
Repairing a parser reading is different from correcting the underlying books. Replacing a source should not silently erase later professional work. Where authority conflicts, the disagreement deserves an explicit resolution.
Explore the evidence modelEvery number needs a story.
A reviewer should be able to understand the support, treatment and calculation behind an important amount. A form line is an entry point into that explanation, not the end of it.
The explanation also needs to belong to the right preparation. Forms, workpapers and diagnostics should describe the same saved result; earlier output should remain recognizable as history after a later change.
Read the argumentTax calculations should be deterministic.
The same established facts and rule version should produce the same result. Money handling, rounding, allocations and cross-form relationships need explicit behavior that can be reproduced and tested.
Reproducible does not mean infallible. It gives research, independent expectations, regression tests and professional review a stable calculation to challenge. AI can help build and examine the software without improvising the return’s arithmetic.
Why determinism mattersProfessional judgment stays professional.
Automation can propose a classification, identify a discrepancy or ask a useful question. It should not blur the difference between a suggestion and a professional determination.
Preparers need direct access to facts, workpapers and forms alongside Guided Preparation. They should be able to investigate a number, revisit a decision and understand what a change will affect. The product serves their judgment.
See the professional workspaceUnknown is not zero.
A blank opening balance is not a known zero. An unavailable payroll report does not establish that no payroll was run. Convenient defaults can turn uncertainty into a false statement.
Missing, zero, not applicable, conflicting, deferred and unsupported states call for different actions. The software should keep them distinct and direct attention toward the fact or decision still needed.
Understand explicit unknownsQualification before expansion.
A new capability needs more than a field or a form template. Its supported facts, rules, interactions, workpapers and output need to work together through a complete preparation path.
As scope grows, old behavior becomes a regression obligation. Synthetic cases, independent expectations, browser inspection, actual PDF review and practitioner testing each ask a different useful question. None should be inflated into a universal guarantee.
See the cumulative engineeringInteroperability is expected.
A tax practice works across accounting, payroll, documents, preparation and delivery. Useful software should make those boundaries easier to cross while preserving the information’s meaning.
The intended integration direction is to carry source context, review state and preparation identity along with values. Public APIs and engine-to-engine connections remain future work, but they belong in the architectural conversation from the beginning.
The case for real APIsUsers should be able to shape their tools.
Practitioners understand their workflows. They should have a meaningful way to improve them, whether through clear product feedback, useful integration boundaries or the ability to change software themselves.
PrepReturns is private today, with open source as the intended direction. A future release could allow inspection, modification, contribution and maintained forks under its eventual license. Changes to tax logic would still require tests, review and professional responsibility.
The open-source direction
THE STANDARD
“A return you can explain.”
Evidence, judgment, calculation and output should form a coherent whole. That is the product we are building toward, one supported preparation path at a time.
See what these principles look like in practice.
Explore the S-Corp Engine, from reviewed source material to the actual return package.