Discovery output
What you get from Discovery
Two artifacts, one lineage. Every route, job, and workflow in your codebase becomes a user story your team recognizes. Every rule those stories run on is recovered, cited, and anchored back to the story that produces it. Nothing orphaned. Nothing guessed
User stories, grouped by domain
A full set of user stories, grouped by the domain entity they act on, recovered from a real production codebase
Every story, in your team's vocabulary
Expand any domain to see every CRUD story, verb, and short narrative in the same view
Business rules, anchored to their stories
Rules grouped by the story that produces them, with rule-kind pills for validation, authorization, and business logic
How we recover your business rules
The rules your business runs on are buried in legacy code, undocumented, and often known to no one. Here is the actual pipeline: AI reads the code, we recover each rule into a plain-language spec you own, with a citation to the exact source, so the modern rebuild can be validated against the original behavior
server/src/routes/classes.ts
Source
router.post('/classes', async (req, res) => {
const { classroomNumber, teacherId } = req.body;
// strip anything that isn't
// alphanumeric before persisting
const clean = classroomNumber
.replace(/[^a-zA-Z0-9]/g, '');
const cls = await db.class.create({
data: { classroomNumber: clean, teacherId },
});
res.json(cls);
});business-rules.yaml
Recovered · owned by you
rule_id: BR-Class-Create-SanitizeClassroomNumber
rule_kind: validation
trigger: When a class is created
condition: classroomNumber contains
non-alphanumeric characters
action: Strip non-alphanumeric
characters before persisting
rationale: Classroom numbers must be
sortable and comparable across records
sources:
- file: server/src/routes/classes.ts
start_line: 42
end_line: 58
confidence: 0.92
provenance: original
parent_story_id: US-Class-Createcoverage-check
Anchored to stories
total_stories: 83 total_rules: 412 orphan_rules: 0 stories_without_rules: 0 # Every rule anchored to a story. # Every story has explicit rules. # Nothing lost between extraction # and specification.
The export format is a machine-checkable schema, so every recovered rule is validated, cited, and reviewed and curated by your domain experts before it drives a single line of the rebuild. You end up owning a complete, plain-language specification of a system that used to live only in code
The hard part is the edge cases nobody remembers
Extracting the obvious rules is easy. The value is in the rules that are conditional, date-sensitive, or quietly special-cased. The ones that pass a rewrite's unit tests and still get month-end billing wrong. Take tax:
server/src/lib/tax.ts
Source
export function computeTax(invoice) {
const taxable = invoice.lines
.filter(l => l.isTaxable)
.reduce((sum, l) => sum + l.total, 0);
// rate as of the invoice date,
// NOT today's rate
const rate = rateOn(invoice.date);
return round2(taxable * rate);
}business-rules.yaml
Needs domain sign-off
rule_id: BR-Invoice-Tax-DateScopedRate
rule_kind: business_logic
trigger: When an invoice is finalized
condition: invoice contains lines where
isTaxable = true
action: Sum taxable-line totals and
multiply by the rate in effect on the
invoice date; return 0.00 (not null)
when no lines are taxable
rationale: Back-dated invoices must use
the historical rate, not today's rate
sources:
- file: server/src/lib/tax.ts
start_line: 40
end_line: 77
confidence: 0.71
provenance: inferred
parent_story_id: US-Invoice-FinalizeA rewrite that “looks right” would use today's tax rate and return null for an untaxed invoice. Both are wrong, and both are invisible until a client's month-end. Because these rules are inferred, not certain, we flag them for the domain owner to confirm before the rebuild starts
Not just math: who can do what, and when
The rules that govern authority and approval flows are where the real risk lives, and they are almost never written down. We recover those too
validation
authorization
business_logic
data_integrity
workflow
other
authorization rule
Who can do what
rule_id: BR-Billing-WriteOffWip-AuthorizedRoles
rule_kind: authorization
trigger: When a user attempts to write
off WIP on a matter
condition: actor.role in
[ResponsiblePartner, BillingManager]
AND amount <= actor.approvalLimit
AND matter.status != 'locked'
action: Allow the write-off; otherwise
reject with a permission error
rationale: Locked matters block all
write-offs, and delegated authority
expires with the delegation, not the
matter
sources:
- file: server/src/routes/billing.ts
start_line: 112
end_line: 149
confidence: 0.68
provenance: inferred
parent_story_id: US-Billing-WriteOffWipworkflow rule
Approval flow
rule_id: BR-Bill-Finalize-PartnerApprovalChain
rule_kind: workflow
trigger: When a draft bill is submitted
for finalization
condition: bill.state transitions across
draft → pending → approved → final;
bills over matter.threshold require a
second approver
action: Advance the bill through the
approval chain; a rejected bill returns
to draft (not pending) and the chain
resets; approvals are voided if the
total changes after sign-off
rationale: Approval authority is scoped
to the amount at time of sign-off
sources:
- file: server/src/lib/bill-workflow.ts
start_line: 64
end_line: 120
confidence: 0.74
provenance: inferred
parent_story_id: US-Bill-FinalizeThese are the rules a rewrite gets subtly wrong: an approval that should have reset, a delegated authority that should have expired, a threshold that quietly moved. Every one is recovered, cited, and reviewed against the running system before the rebuild ships