Requirements Base

Requirements Base

RequirementsBase is a structured, modular repository of validated functional requirements for financial services systems, mapped to the BIAN capability model and packaged with regulatory references, acceptance criteria, and executable BDD test assets. AI drafts the content at scale; domain experts validate and sign off, creating provenance that regulated buyers will pay for. Clients connect their existing Jira, Confluence, or live systems to an MCP-native gap analysis agent, which scores their current capability coverage against the reference packs and outputs a prioritised remediation list, a sprint-ready Jira backlog, and a matched test pack — feeding directly into AI coding tools like Claude Code or Kiro with no reformatting required. The commercial model runs three parallel revenue streams: platform licences (free through to A$55k–190k/year firm licences targeting consulting firms and system integrators), fixed-fee productised services (gap sprints, pack customisation, onboarding),
rawuncategorizedfree idea

Snapshot

RequirementsBase is a structured, modular repository of validated functional requirements for financial services systems, mapped to the BIAN capability model and packaged with regulatory references, acceptance criteria, and executable BDD test assets. AI drafts the content at scale; domain experts validate and sign off, creating provenance that regulated buyers will pay for. Clients connect their existing Jira, Confluence, or live systems to an MCP-native gap analysis agent, which scores their current capability coverage against the reference packs and outputs a prioritised remediation list, a sprint-ready Jira backlog, and a matched test pack — feeding directly into AI coding tools like Claude Code or Kiro with no reformatting required. The commercial model runs three parallel revenue streams: platform licences (free through to A$55k–190k/year firm licences targeting consulting firms and system integrators), fixed-fee productised services (gap sprints, pack customisation, onboarding),

Current signal

No signal has been added yet.

Next step

Define the cheapest validation step.

Risk

Main risk not yet identified.

How to help

  • Add evidence from public sources.
  • Name a risk or reason to trash it.
  • Suggest a sharper customer, wedge, or pivot.

Research & evidence

12 recorded entries behind this idea, oldest first. Open one to read it in full.

Evidence 2

Sources, findings, and competitor scans.

evidenceCompetitive research part 1/2 — landscape (4 parallel searches, ~40 vendors + academic lit). Headline: NO vendor spans the full chain regulation → cl…

Competitive research part 1/2 — landscape (4 parallel searches, ~40 vendors + academic lit). Headline: NO vendor spans the full chain regulation → clause-traceable → buildable stories → EXECUTABLE BDD → AI-coding handoff. The market splits into two non-touching worlds: (A) RegTech/GRC (CUBE, Ascent, Corlytics, Regology, 4CRisk, Archer Evolv, Norm Ai) maps regulation→obligations→controls/policies for the COMPLIANCE officer, terminating at a policy PDF/attestation; (B) BDD/AI-gen tools (Gherkinizer, RequireKit, Specmatic Genie) turn stories into runnable tests but have zero regulatory ingestion or clause trace. RequirementsBase sits in the empty bridge. Corrections forced by evidence: (1) Traceability = table stakes (Corlytics/Regology/Archer all market it) — don't lead with it. (2) Done-vs-gap + Jira scorecard = SATURATED (Vanta/Drata/LogicGate/ServiceNow already auto-create tickets) — don't lead with it. (3) Obligation extraction = solved (Ascent did MiFID II in 2.5min; Archer Evolv ~95% accuracy) — table stakes. (4) BIAN mapping = ZERO competitors do it, and BIAN is free — novel positioning. (5) Executable step-definitions = almost nobody ships runnable tests — sharpest messaging wedge. (6) Buyer flank: every incumbent sells to Compliance/Risk; the unserved buyer is Product/Engineering/Delivery, who today hand-write specs from obligation exports.

evidenceCompetitive research part 2/2 — wedge, threats, enabling stack.

Competitive research part 2/2 — wedge, threats, enabling stack. Defensible wedge = the connective spine: one clause ID carried unbroken clause→EARS story→acceptance criterion→runnable Gherkin→live-system check, sold to the change-the-bank engineering team. Plus a MANDATORY human-review gate — the arXiv study 'From Law to Gherkin' (2025) found LLM requirement omissions and hallucinations, so review is a built-in compliance requirement, not a nicety. This turns the earlier 'completeness trap' risk from a weakness into a mandated, differentiating feature. Threats to watch: Archer Evolv (only incumbent already attempting law→requirements at scale with deep FS content — closest competitor); Norm Ai ($48M 'law-as-code', dangerous if it pivots from document-review to live-systems verification); CUBE (consolidating the entire reg-intel content layer — bought Thomson Reuters Regulatory Intelligence + 4CRisk); pincer risk from Ketryx (regulated-ALM adding executable BDD) or Gherkinizer/RequireKit/Specmatic Genie (bottom-up, adding regulatory ingestion + clause trace). Enabling stack is production-ready NOW: frontier LLM (Claude) for clause extraction, grounded via clause-aware RAG + Anthropic Citations API for provenance; EARS notation as the intermediate representation; strict structured output (clause ID a required field at every hop); emit onto two rails — Gherkin (Cucumber/Reqnroll/Serenity) and OpenAPI (Specmatic); push to backlogs via the official Atlassian and Azure DevOps MCP servers; hand structured specs to Kiro (spec-driven) or Claude Code. Note: SpecFlow is EOL (Dec 2024) — target Reqnroll.

Risks 2

Reasons this could fail.

riskCritical assessment — five failure modes, most fatal first:

Critical assessment — five failure modes, most fatal first: 1. Reusability paradox (core flaw). Functional requirements are valuable because they're firm-specific (products, jurisdiction, risk appetite, legacy stack). A requirement generic enough to resell is either so abstract it's a truism BIAN gives away free, or so specific it doesn't fit the next buyer. The reusable middle band is thin — and it's exactly what the A$55–190k/yr licence charges for. 2. Provenance doesn't transfer. Regulated buyers pay for accountability tied to THEIR system, not a library another firm's expert blessed elsewhere. A sign-off on a generic pack carries no assurance or liability across the boundary — so the thing "buyers will pay for" is the thing that doesn't cross it. 3. Inverted margin story. "AI drafts at scale" implies cheap content, but the value is the expensive human validation, whose cost dominates and doesn't shrink with scale. Regulation churns (APRA, Basel, AML, multi-jurisdiction) → permanent re-validation treadmill; stale requirements are worse than none. This is a consultancy with an AI intake funnel, not an AI-leverage content business. 4. Channel conflict with the named buyer. Consulting firms and SIs sell requirements-gathering as billable hours. A library that commoditizes that work threatens their model — you're asking them to pay you to undercut their own margin. 5. Liability on the gap agent. An MCP agent wired into a bank's live systems declaring "you have a compliance gap" — false negatives are regulatory exposure for the client and litigation exposure for you. Without heavy assurance you can't sell it; with it you're back to a consultancy (see #3). Secondary: cold-start (no packs = no value; large upfront build before revenue) and undifferentiation vs BIAN (free), Big-4 accelerators, and Jama/DOORS. Decider: will a real FS firm pay for a validated requirement written for someone else? If reusability is thin, everything downstream collapses.

riskVerification-of-done honesty (the scorecard's weak point). The gap tracker labels each requirement done vs gap, but a scorecard is only as honest as…

Verification-of-done honesty (the scorecard's weak point). The gap tracker labels each requirement done vs gap, but a scorecard is only as honest as its ticks. Software controls are verifiable (inspect code / run tests). Non-software controls (policy, procedure, guideline) usually rely on self-attestation — someone saying "we did it." A policy can be written and ticked green while nobody follows it; regulators judge actual behaviour, not the document. So a green board can give false confidence, and when a regulator finds a "done" that wasn't, the tool that reported it green carries the blame. Two riders: (1) This positioning lands in a crowded GRC market — Vanta, Drata, Archer, LogicGate, ServiceNow already map obligations to controls and track done-vs-gap. The defensible edge is NOT the scorecard; it is automatically translating raw regulation into typed, buildable, clause-traceable requirements. (2) Done-vs-gap only means something if the requirement list is complete — a requirement that was never generated never appears as a gap, so a firm can read 100% green over an invisible hole (inherits the completeness trap).

Pivots 1

Alternative shapes worth testing.

pivotReframe (strengthens the idea): the core value is a TRANSLATION LAYER, not a requirements library. The system ingests government/regulator source tex…

Reframe (strengthens the idea): the core value is a TRANSLATION LAYER, not a requirements library. The system ingests government/regulator source text (e.g. APRA CPS 230, AML obligations) and translates it into structured, buildable requirements — user stories, use-cases, acceptance criteria, BDD tests — i.e. "pseudo-code for something that could be built." Firms no longer re-derive requirements from dense legal prose themselves. Why this is stronger: regulation is SHARED across every firm in a jurisdiction, so the translation is genuinely reusable — this defuses the earlier reusability-paradox objection for the regulatory-derived layer. It also flips the maintenance treadmill from a cost into the business model: an always-current regulation-as-requirements subscription (like a legal-update service that goes one step further, into buildable form). What still stands: (a) interpretation liability — principles-based regs require opinionated interpretation, so faithful clause→story→test traceability is the real moat and the thing compliance teams must be able to audit; (b) product delivers the shared first ~60%, with the firm-specific "buildable in THIS bank" last mile remaining (which conveniently lowers channel conflict — consultancies use it as a tool rather than fear it); (c) competes adjacent to reg-change trackers (CUBE, Ascent, LexisNexis/Thomson Reuters) — win by going all the way to executable stories/tests, not by being the only one tracking regs. Cheapest test: translate ONE regulation (CPS 230) into a story/use-case pack WITH clause traceability, put it in front of one compliance lead. Yes = "saves weeks and I trust the trace." Tests both load-bearing assumptions at once: good enough to trust, and saves enough to pay for.

Proposed refinements 7

Proposals for the document above. Open ones are awaiting merge.

refinementawaiting mergeSection: next_step — Proposal:

Section: next_step Proposal: Before building any packs, pre-sell a single fixed-fee gap sprint to one real FS firm. Concretely: pick one BIAN capability domain in one jurisdiction, hand-build one reference pack, and get a paying client to run their current-state against it. Success = they pay, and the output changes what they actually put in their next sprint. This tests the load-bearing assumption (will a firm pay for a requirement written for someone else?) for the cost of one sprint, before any platform or content investment. Rationale: The idea's viability hinges on requirement reusability across firms. That is cheap to falsify with one pre-sold engagement and expensive to discover after building a pack library. De-risk the core assumption first.

refinementawaiting mergeSection: snapshot — Proposal:

Section: snapshot Proposal: RequirementsBase is a translation layer that turns government and regulator source text into buildable requirements. It ingests regulation (e.g. APRA CPS 230, AML obligations) and outputs structured, testable assets — user stories, use-cases, acceptance criteria, and executable BDD tests — effectively "pseudo-code for something that could be built," with each artefact traceable back to the exact regulatory clause it came from. Because regulation is shared across every firm in a jurisdiction, the translation is reusable, and keeping it current becomes a subscription (always-current regulation-as-requirements) rather than a maintenance cost. AI drafts the translation at scale; domain experts validate and sign off, and clause→story→test traceability lets compliance teams audit faithfulness. An MCP-native gap-analysis agent connects to a client's Jira/Confluence/live systems, scores current coverage against the reference packs, and outputs a prioritised remediation list, a sprint-ready Jira backlog, and a matched test pack — feeding directly into AI coding tools like Claude Code or Kiro. The product delivers the shared regulatory layer; the firm-specific "buildable in this bank" last mile stays with the client and their integrators. Revenue: platform licences (free → A$55k–190k/yr firm licences for consulting firms and SIs), fixed-fee productised services (gap sprints, pack customisation, onboarding), and subscription updates. Rationale: Repositions from a static "requirements library" (which triggered the reusability-paradox objection) to a regulation-to-requirements translation layer, where the shared regulatory source makes the output genuinely reusable and turns the maintenance treadmill into a subscription. Adds clause traceability as the core trust/moat mechanism.

refinementawaiting mergeClarification (resolves the "not everything is a test" objection): each translated requirement is typed as either a SOFTWARE control (built in code,…

Clarification (resolves the "not everything is a test" objection): each translated requirement is typed as either a SOFTWARE control (built in code, verifiable via tests) or a NON-SOFTWARE control (internal guideline, policy, or procedure). The system doesn't force everything into executable tests — instead it tracks IMPLEMENTATION STATUS across both types: for every requirement derived from a regulation, the company can see what has been implemented and what is still a gap. The output is a single coverage scorecard (done vs gap) spanning code and policy, not just a test pack. This positions the gap-analysis agent as a regulation-to-implementation coverage tracker.

refinementawaiting mergeSection: snapshot — Proposal:

Section: snapshot Proposal: RequirementsBase is a translation layer that turns government/regulator source text (e.g. APRA CPS 230, AML obligations) into buildable requirements — user stories, use-cases, acceptance criteria, and executable BDD tests — with every artefact traceable back to the exact clause it came from ("pseudo-code for something that could be built"). Each requirement is typed as a SOFTWARE control (built in code, verifiable via tests) or a NON-SOFTWARE control (policy, procedure, guideline). Because regulation is shared across all firms in a jurisdiction, the translation is reusable, and keeping it current is a subscription (always-current regulation-as-requirements) rather than a maintenance cost. AI drafts the translation at scale; domain experts validate and sign off; clause→story→test traceability lets compliance teams audit faithfulness. An MCP-native gap-analysis agent connects to a client's Jira/Confluence/live systems and produces a single coverage scorecard — done vs gap across both software and policy controls — plus a prioritised remediation list, a sprint-ready Jira backlog, and a matched test pack that feed AI coding tools (Claude Code, Kiro). The product delivers the shared regulatory layer; the firm-specific "buildable in this bank" last mile stays with the client and its integrators. Revenue: platform licences (free → A$55k–190k/yr firm licences for consultancies and SIs), fixed-fee productised services (gap sprints, pack customisation, onboarding), and subscription updates. Rationale: Consolidated canonical snapshot that supersedes earlier piecemeal snapshot proposals: folds in the translation-layer reframe, clause traceability, the software-vs-policy control typing, and the done-vs-gap coverage scorecard. Represents the idea's current, internally consistent state.

refinementawaiting mergeSection: risk — Proposal:

Section: risk Proposal: Four surviving risks after the translation-layer reframe: (1) Completeness trap — traceability proves each generated requirement maps to a clause, but not that every obligation was captured; a missed rule never shows as a gap, so a firm can see 100% green over an invisible hole. Proving completeness needs an expert to read the whole regulation — the exact cost the AI was meant to remove. (2) Verification-of-done honesty — the done-vs-gap scorecard is only as honest as its ticks; software is verifiable, but policy/procedure controls rely on self-attestation and a written-but-unfollowed policy still reads green. (3) Interpretation liability — principles-based regs (esp. APRA) require opinionated interpretation; clause→story→test traceability is the mitigation and the moat. (4) Crowded GRC market — Vanta/Drata/Archer/LogicGate/ServiceNow already map obligations and track coverage; the edge must be automatic raw-law→buildable-requirements translation, not the scorecard. Unresolved decision: position as "sign-off-grade, complete, expert-gated" (premium, competes with law firms) or "fast first draft, human-completed" (cheap, tool-shaped) — the pitch currently implies both, which are different companies. Rationale: Consolidated risk field capturing the risks that survived successive reframes, plus the still-open positioning decision. Supersedes the earlier standalone risk contributions as the canonical summary.

refinementawaiting mergeSection: next_step — Proposal:

Section: next_step Proposal: Single cheapest test that exercises every load-bearing assumption at once: take ONE regulation (APRA CPS 230), translate it into a typed requirement pack — each item tagged software vs policy/procedure — WITH clause→story traceability. For at least one policy-type item, define concretely how implementation would be PROVEN beyond self-attestation (evidence, not a ticked box). Put the pack in front of one real compliance lead and pre-sell a fixed-fee gap sprint against it. Success = they trust the traceability, believe the coverage is honest (not falsely green), and pay. This tests all three at once: is the translation faithful and complete enough to trust, is done-vs-gap credible, and will a firm pay — before building any pack library or platform. Rationale: Consolidated next step that supersedes the earlier "pre-sell a gap sprint" proposal: adds clause traceability, software/policy typing, and a concrete proof-of-implementation check so the single test covers the completeness, verification, and willingness-to-pay risks together.

refinementawaiting mergeSection: signal — Proposal:

Section: signal Proposal: Market evidence supports timing and white space. Competitive research across ~40 vendors confirms NO product spans regulation → clause-traceable → buildable stories → EXECUTABLE BDD → AI-coding handoff. The field splits into two non-overlapping worlds — RegTech/GRC (stops at policy/control artefacts for compliance officers) and BDD/AI-gen tools (start after the hard part, no regulatory input) — leaving the bridge empty. The concept is being published in 2025-26 academic papers ('From Law to Gherkin'), a recognized-but-unsolved signal. The enabling stack is production-ready today (frontier LLM extraction, clause-aware RAG + Anthropic Citations API, EARS→Gherkin, strict structured output, official Atlassian/Azure DevOps MCP servers, Kiro/Claude Code handoff). The defensible wedge is the unbroken clause→story→AC→runnable-test spine plus a mandatory human-review gate, sold to the underserved Product/Engineering/Delivery buyer rather than Compliance. Traceability, obligation extraction, and the done-vs-gap+Jira scorecard are all table stakes or saturated — the differentiation is executable output + BIAN alignment + the engineering buyer, not any single piece. Rationale: Fills the empty Current Signal field with the strongest evidence-backed reason to pay attention now: a validated white space, academic corroboration that it's unsolved, and a fully production-ready enabling stack — while correcting the pitch away from the saturated/table-stakes pieces.

Comments

Loading comments...

Sign in with GitHub or Google to comment and react.

Sign in to post public comments.