Now taking pilot teams
SpecTrail reads your repository, writes the specification in plain language, and tells you the moment code stops matching it. You decide what stays.
Storefront / SpecificationAsk, or jump to anythingAllWaiting for you 1Checkout and payments
A customer can apply one discount code to an order.
A discount never takes an order below zero.
A code stops working at the end of the day it names, in the store’s time zone.
Free shipping applies to orders of $50 or more.
Orders to another country show the shipping cost before payment.
A customer can choose a pickup point instead of home delivery.
Nobody means to change the product. A cleanup here, a simpler rule there. The specification still says what it said in March, and you find out from a customer.
How it works
SpecTrail turns code into user stories with acceptance criteria, grouped by epic and feature, in the words your team uses.
Every statement carries small marks for what backs it: the code that does it, the tests that check it, the last change to it.
Each merged pull request is compared with the specification. Refactors pass silently. A change in meaning waits for you.
A change, caught
Pull request, merged 2 days ago
Maya R. · 3 files changed
Cleans up the shipping calculator and removes a duplicate branch.
Nothing in the description mentions prices. A reviewer reading the code could miss it too. This is the kind of change a specification exists to catch.
Compared with the requirement
Specification says
Free shipping applies to orders of $50 or more.
Code now does
Free shipping applies to orders of $75 or more.
Changes the meaning Customers with a $50–$74 cart now pay for shipping.
A rename, a refactor or a faster query would pass here without a word. Only changes to what the product does are raised.
Your decision
The requirement is rewritten to $75. History keeps the pull request and your decision.
Accept the change but say it your way.
Open a ticket because the code is wrong, mark a false alarm, or record that it was intended.
Pull request review
AI assistants now write more code than any team can read. Pull requests get a skim, or go to another agent for review, and a green test run seems to settle it. But passing tests and a friendly AI review show that the code runs. They do not show that the change to the product is the one you want.
SpecTrail asks that question for you, soon after each merge: does the product still match its specification? When a change alters what the product does, it reaches a person while there is still time to decide, before it goes to production.
A product manager does not have to read every pull request or every changed line. SpecTrail decides which changes are meaningful, and only those need a human.
Read why code review is not enough anymoreUse cases
SpecTrail is for any team that needs a better answer to “what does our software actually do?” than “ask whoever wrote it.” It matters most where the answer has to be written down, kept current and shown to someone else: an auditor, a regulator, a customer, or your own next hire.
In medical and health software the specification is part of the product. Regulators and notified bodies expect a document that says exactly what the software does, and evidence that the code, the tests and that document agree. In practice the document is written once and then drifts, release by release, until someone has to reconstruct it before an audit.
SpecTrail writes the specification from the repository, links every statement to the code and tests behind it, and checks each merged pull request against it. A change that alters behaviour cannot pass quietly: it waits for a named person to accept it, reword it or reject it, and the decision is recorded with the pull request, the old and new wording and the reason. The result is a requirements document that stays aligned with the code, and a traceable history of how it changed.
How a medical startup keeps its requirements current while moving fast
Auditors ask how changes to production software are reviewed and approved. Most teams answer with pull-request approvals, which show that someone clicked a button, not that anyone considered what the change did to the product. That gap is easy to defend while you are small and uncomfortable once a customer’s security team starts asking.
SpecTrail adds the record that is usually missing. For every change that alters what the product does, you can show who decided, when, what the requirement said before and after, and why. It sits next to the specification, so the evidence for your change-management controls is produced as a side effect of the work and not assembled the week before the audit.
Early on, a team ships daily and the product lives in Jira tickets, Slack threads and the memory of the first engineers. That works until it doesn’t. There are now hundreds of features, nobody remembers exactly how the discount rules or the permissions behave, and customers and investors expect things to work every time. The team still wants to move fast, but now it also has to test, and it cannot test what it has never written down.
SpecTrail reads what the code already does and writes it as user stories with acceptance criteria, grouped by epic and feature. The evidence marks show which behaviours have tests and which do not, so QA and engineering know where to start. After that, every pull request is checked against the specification, so you keep shipping every day without wondering what the last release quietly changed.
Code now arrives faster than anyone can read it. SpecTrail moves the review from lines of code to behaviour: whatever wrote the change, a person decides whether the product should now work that way.
Fees, limits, rounding, refunds and eligibility are rules where a changed threshold costs money or breaks a promise. Each one becomes a plain statement you can check, and a change to it becomes a decision.
Standards such as ISO 26262 and DO-178C expect traceability from each requirement to its code and tests. SpecTrail helps keep those links current instead of rebuilt by hand before a milestone.
Eligibility, benefit, premium and tax rules live in code, but policy and legal teams own their meaning. They can read the rule in plain words and see when a change touches it.
After an acquisition, a handover from an agency, or when the original engineers leave, a specification derived from the code is the fastest way to learn what the system really does and what is tested.
Clients can check delivered software against the agreed specification, and see exactly which later changes altered what was agreed. Fewer arguments about what “done” meant.
Articles
AI assistants write more code than any team can read. Passing tests and an AI review show the code runs. SpecTrail flags the changes that alter what the product does soon after the merge, while there is still time to decide.
Read the articleA walkthrough of one change, from the pull request that was merged to the decision a person made, using a shipping rule that moved from $50 to $75.
Read the articleA closed ticket records what someone planned to build, not what the product does today. A specification describes the product as it is, in one place, and stays current.
Read the articleA medical startup has to know exactly what its product does and show it to a regulator. SpecTrail closes the loop from requirement to code to test, so the team works with agents and tickets at full speed while the numbered requirements document stays current.
Read the articleTrust
Access is a read-only token. SpecTrail never writes to your repository.
No statement without a source. Open any requirement to see the code, the tests and the history behind it.
SpecTrail decides which changes alter what the product does. Refactors and renames pass quietly. A meaningful change comes to you to accept, edit or deny, and the decision is recorded with who and when.
We test against labeled pull requests from open-source projects, and we publish the results.
Pilot
The fastest way to know whether it works is to run it on your code. We baseline your last 100 merged pull requests and you judge the result.
One token. Nothing is installed in your repository.
A specification drafted from the code, with the last 100 merged pull requests replayed against it.
Accept, edit or deny. Then you decide if it is worth keeping.