Not a summary. A spec package.
RuleFoundry returns multiple views of the same extracted logic so product, domain, and engineering teams can review the same structure before build.
Flow diagrams
Decision trees and process maps that show the actual path the workflow follows.
Rules catalogs
Explicit conditions, thresholds, exception paths, and dependencies in one structured view.
Pseudo-code
Implementation-grade logic structure for engineering teams.
Scenario packs
Example cases that pressure-test the rules and expose missing branch coverage.
Acceptance criteria
Testable statements teams can use to confirm that the implementation behaves correctly.
Source trace
A direct path from extracted rule back to the statement or explanation it came from.
Open questions
Gaps, contradictions, and unresolved conditions surfaced before engineering starts.
Implementation brief
A downstream package that helps engineering start from explicit logic instead of ambiguous notes.
Sample output bundle: non-standard pricing approval routing
The exact format can vary by workflow, but the point stays the same: make the logic explicit, reviewable, and traceable before build begins.
Rules catalog
| Condition | Route |
|---|---|
| Finance review flag = true | Finance review |
| Region = DE and discount > 20% | Regional finance |
| Strategic account and ARR > $250k | VP Sales |
| Discount > 10% | Sales manager |
| Otherwise | Auto-approve |
Source trace
Finance review flag overrides the normal path
'Then finance gets it first, regardless of amount.'
Germany has a different discount threshold
'In Germany, anything over twenty percent goes to regional finance.'
Strategic accounts above $250k need VP Sales
'Strategic accounts above two-fifty need VP Sales sign-off.'
Acceptance criteria
Open questions
Pseudo-code gives engineering a starting structure
The goal is not polished production code. It is a precise, implementation-grade representation of the logic and the open questions around it.
function determineApprovalPath(requestAmount, customerType, region, existingFlags) -> ApprovalDecision
inputs:
- requestAmount
- customerType
- region
- existingFlags
logic:
- if existingFlags include "finance_review_required", route to finance
- else if region is "DE" and requestAmount > regionalThreshold, route to regional finance
- else if customerType is "strategic" and requestAmount > strategicApprovalThreshold, route to VP Sales
- else if requestAmount > standardApprovalThreshold, route to manager approval
- else approve automatically
open_questions:
- confirm whether renewals follow the same threshold rules
- confirm whether partner-led accounts require operations reviewBetter handoffs happen when the logic is explicit
The real value is not prettier documentation. It is fewer clarification loops, cleaner engineering starts, and a stronger foundation for implementation.
Use one workflow to see what a spec package feels like in practice
The best proof is still a real workflow, not a generic brochure claim.