VALIDATION.WORKS — FULL TEXT FOR AI ASSISTANTS This file is the plain-text compilation of the two canonical documents published at https://validation.works: the Venture Validation Standard (VVS 2.0) page (/standard) and the whitepaper "Evidence Over Narrative" (/whitepaper). Text matches the live site. If you have been asked to assess a venture against this Standard, follow the protocol at https://validation.works/vvs-protocol.txt ================================================================================ PART A — THE VALIDATION STANDARD (/standard) ================================================================================ THE VALIDATION STANDARD A common language for what's been proven. VVS 2.0 · August 2026 The Venture Validation Standard (VVS) defines how ventures are assessed on the road from idea to product-market fit: five dimensions, evidence-based confidence levels, independent assessment, and the delta between belief and evidence — tracked on a cadence. Developed in live assessment practice. Applied to every venture on the platform, including Validation.Works itself. THE FINISH LINE — WHAT PRODUCT-MARKET FIT MEANS HERE Product-market fit is the moment the direction of force reverses. Before it, you push the product onto the market — every sale a shove, every user won by effort. At it, the market starts pulling the product out of you: customers come back unprompted, bring others with them, and demand begins to outrun what you can deliver. Pull and profitability are related tests, not the same test. A venture can feel real pull on economics that will never work; a venture can grind its way to cashflow positivity without any pull at all. The finish line requires both: demonstrated pull, and an evidenced path to cashflow positivity — the venture creating more value than it consumes, and so earning its place in its ecosystem. Everything before that point is a claim. The Standard measures the distance between claim and evidence, until both are real. SECTION 1 — THE FIVE DIMENSIONS 01. Ecosystem Who the players are, how value flows between them, and exactly where the venture fits. An organism survives by playing a role in its system. 02. Target Customer Who they are, what defines them, and the goals, behaviours, and frustrations that shape their decisions. 03. Customer Problem The problem as the customer describes it — in their words, not the founder's translation. 04. Customer Job The progress the customer is trying to make, solution-agnostic: the job they'd hire anything to do. 05. Value Capture What the customer gives in return — money, time, data, behaviour — and how and when it's captured. THE CASCADE — VALIDATION EXPIRES DOWNWARD The five dimensions are ordered, and each is conditioned on the ones above it. Change the Ecosystem and, by definition, the Target Customer within it, the Problem they feel, the Job they need done, and the Value that can be captured all change with it. Change cascades downward from the point of change — never upward. Evidence at any level is therefore conditional on every level above it holding: a change above expires the validation below. The same law governs building. Spending resources at any layer beneath an unvalidated one — in the dimensions, or further down the enterprise stack in organization, information, and technology — is a leveraged bet that the layers above will not move. When they move, everything built beneath them is written off. This is why premature construction, not bad construction, is what kills early-stage ventures. The one legitimate form of that bet is the experiment: minimal construction below, purpose-built to generate evidence for the layer above, sized to the evidence it must produce, and priced as spend-at-risk rather than commitment. And it is why the Standard reads a confidence profile top-down: eighty percent confidence in Value Capture resting on thirty percent confidence in Ecosystem is not an eighty — it is a conditional eighty standing on a thirty. SECTION 2 — CONFIDENCE & EVIDENCE Each dimension carries a confidence score — not how strongly the team believes, but how much evidence exists. A named individual signs every score. Confidence without evidence is the exact risk the Standard exists to expose. SECTION 3 — THE DELTA Every venture is scored twice: by the team that runs it, and independently by a certified assessor against the same definitions. Neither score alone is the product. The gap between them is. [Figure — Delta diagram: One record. Two perspectives. The gap is the signal.] SECTION 4 — THE CADENCE Monthly snapshots. Event-logging on material changes — a pivot, a key departure, a raise. One snapshot is a photo; the sequence is the record, and the record is the asset. FOUNDATIONS — WHERE THE STANDARD STANDS VVS is an application of three established bodies of work to one new object: the venture seeking product-market fit. 01. What a venture is — enterprise engineering. A venture is a solution system inside a using system: it produces a function for its environment and receives value in return. The five dimensions decompose exactly that function model. The theory descends from enterprise ontology and enterprise engineering — Dietz, Hoogervorst, de Vries & Gerber — through the DEMO-based enterprise engineering approach developed by co-founder Thomas van der Meulen. Function before construction: prove the venture should exist before engineering how it works. 02. What counts as evidence — validated learning. The unit of progress before product-market fit is the tested assumption, in the tradition of Ries and hypothesis-driven entrepreneurship. VVS makes that discipline accountable: confidence scored against evidence held, signed by name, assessed independently. 03. How it's governed — risk-based supervision. The governance model is adapted from prudential regulation. We don't prescribe what a venture does or how. The venture must demonstrate that it understands its business, knows its risks, and manages them. Self-assessment, independent review, and the delta between them mirror the supervisory bargain regulators apply to the institutions they oversee. The Standard grew from two parallel master's theses written a decade before the company — one applying enterprise engineering to what an enterprise is, the other applying validated learning to whether a platform should exist — and has been tested since across fifty-plus entities the founders built, backed, advised, or buried. VERSION HISTORY VVS 2.0 — August 2026 — Current Scope narrowed to the five dimensions that decide whether a venture should exist on the road to product-market fit: Ecosystem, Target Customer, Customer Problem, Customer Job, Value Capture. Organisation, information, and technology dimensions moved out of pre-PMF scope. Named-signature rule and delta methodology formalised. Dimensions: Ecosystem · Target Customer · Customer Problem · Customer Job · Value Capture VVS 1.0 — March 2026 — Superseded First published framework. Twelve dimensions across four groups: Market (Ecosystem, Target Customer, Customer Problem, Customer Job, Value Exchange), Organisation (Operating Model, Key Actors), Information (Data Required for Decisions, Information Flow, System Structure), Technology (Technology Stack Implementation). Market: Ecosystem · Target Customer · Customer Problem · Customer Job · Value Exchange Organisation: Operating Model · Key Actors Information: Data Required for Decisions · Information Flow · System Structure Technology: Technology Stack Implementation The Standard is reviewed on a quarterly rhythm. Every change is logged here — the Standard keeps the same discipline it demands: versions signed, history public, no silent edits. TERMS OF ADOPTION — A CONDITION, NOT A FEATURE The Standard only works if both sides accept its terms before capital moves. For the founder: if the discipline reads as surveillance rather than support, the honest answer is to say no — before the investment, not after. For the allocator: if you're not prepared to enforce the cadence and respect the independence of the assessment, don't mandate it. Adopted honestly, the record serves the founder first and the backer second. That's by design. STATUS — OPENNESS AND STATUS The Standard is being formalised for open publication — versioned, freely usable, with instruments anyone can run. Its version history is public above; its live application is public at /record. The Standard is open. Independent assessment is the service — scoped in conversation. Run a VVS self-assessment with any AI assistant — the protocol is published at validation.works/vvs-protocol.txt ================================================================================ PART B — WHITEPAPER: EVIDENCE OVER NARRATIVE (/whitepaper) ================================================================================ Evidence Over Narrative A Validation Accounting Standard for Ventures on the Road to Product-Market Fit Thomas van der Meulen and Hannes Heyns, Validation.Works Working Draft v0.3 (August 2026) This is a living document, published in the open before it is finished. It follows the same discipline the Standard demands of the ventures it measures. Sections still in development are marked. Every revision is logged; no silent edits. Feedback: connect@validation.works ABSTRACT Early-stage capital allocates on narrative. Between a venture's founding and product-market fit there are no audited financials, no standardized disclosures, and no shared definition of progress, so capital flows on proximity, charisma, and pattern-matching, and both founders and their backers navigate by gut. This paper introduces validation accounting: a standard for measuring what a venture has actually proven, as distinct from what it believes. The Venture Validation Standard (VVS) assesses ventures across five dimensions derived from the function model of an enterprise (Ecosystem, Target Customer, Customer Problem, Customer Job, and Value Capture), each scored twice: by the venture itself, under named signature, and independently against defined evidence criteria. The gap between the two scores, the delta, is the risk signal, tracked on a monthly cadence until the finish line: product-market fit, the market pulling the product from the venture, together with an evidenced path to cashflow positivity. The two are correlated but distinct tests; the Standard requires both. The governance model is adapted from risk-based prudential supervision: the standard does not prescribe what a venture does or how; it requires the venture to demonstrate that it understands its business, knows its risks, and manages them, with measurement kept structurally independent of capital allocation. We present the theoretical foundations, the standard's mechanics, early evidence from its application (including to the authors' own companies), its limitations, and a research agenda. 1. THE PROBLEM: THE BROKEN EVIDENCE FLOW The early-stage venture ecosystem runs on flows of capital, time, and trust between four parties: capital sources; portfolio managers who deploy that capital across batches of ventures; the founders operating those ventures; and the supporting cast around them. Capital and guidance flow downward. What should flow upward is evidence: what each venture has actually proven about its ecosystem, its customer, the problem, the job, and the value exchange. That flow is broken. What flows up instead is activity reporting: burn, users, decks, and founder narrative. [Figure 1: The broken evidence flow: capital and guidance flow down; narrative, not evidence, flows back up.] The allocator's version, as heard in practice: "I walk into founder calls blind. Founders love telling me how busy they are. Activity. None of it tells me what they've actually tested versus what they're just assuming, so I'm gauging risk off their confidence and my own pattern matching. I can't just demand better reporting either. I'm not close enough to know what each venture should be tracking, and I don't have the time or a framework to guide them without becoming the bottleneck. I invest in ten knowing most will fail. But I can't tell you which risk is killing which venture right now." A portfolio manager And the founder's: "I'm working flat out and I genuinely can't tell you if we're getting closer. Every week is full (building, content, calls) but when our investor asks 'what have you proven since last month,' I don't have a clean answer. I know there are assumptions buried in what we're doing. I don't know which ones are the dangerous ones, and honestly, some I'd rather not look at too hard. Investor updates are a performance. And when the investor pushes back, it feels personal, because there's no shared reference point that isn't one of our guts." A founder, inside such a portfolio Public markets solved the adult version of this problem a century ago with standardized accounting, independent audit, and disclosure regimes, and that solution is precisely what made those markets broadly accessible. The pre-PMF stage has no equivalent. Existing portfolio- monitoring tools track outcome metrics that early-stage ventures do not yet meaningfully have; they report activity without distinguishing what has been tested from what is assumed. The absence of a measurement standard, not the absence of administrative tooling, is what keeps early-stage investment the province of insiders, and what keeps founders performing progress instead of proving it. This paper proposes the missing layer: an accounting standard for validation. 2. WHAT A VENTURE IS: FUNCTION BEFORE CONSTRUCTION A standard must first define its object. We draw on enterprise engineering for a definition with three properties the standard requires: it is implementation-independent, it is complete, and independently constructed models of the same enterprise converge. The foundational distinction is between a system's function (what it produces for its environment) and its construction (how it is internally built). A venture, at this level, is a solution system inside a using system: the using system transfers value to the solution in exchange for a business function the solution produces. Before the internals of the black box are designed at all, its external reason to exist must hold: some actor in the using system must need the function, and must part with value for it, sustainably. The Standard departs from enterprise-engineering practice in one deliberate way. Most enterprise- engineering work is done within existing enterprises, designing new parts or redesigning existing business processes: construction, within a set of requirements. This Standard purposefully removes the focus from construction and places it on the function and the value exchange, because for a venture the prior question is not how should this be built, but: is this worth building at all? Consider the business world as you would an ecosystem. A new actor introduced into an existing ecosystem must either take over the role of an incumbent, or perform a function that is currently not being performed. That is how it extracts value and exists sustainably. An actor that does neither will perish, or persist as a parasite; and the business world is considerably less tolerant of parasites than nature is. The Standard exists to help founders establish whether their venture brings value the ecosystem requires, and can extract sufficient value in return to exist sustainably, while taking less risk in finding out. [Figure 2: The function model: a solution system inside its using system, exchanging a business function for value.] The five dimensions of VVS are a decomposition of exactly this function model: Ecosystem is the using system: who the players are, how value flows, where the venture must fit. Target Customer is the initiating actor within it. Customer Problem is the felt deficiency that makes the function needed, in the customer's words. Customer Job is the progress the customer is trying to make; the function, solution-agnostic. Value Capture is the value-transfer arrow: what flows back, from whom, when, under what conditions. [Figure 3: The five dimensions of VVS as a decomposition of the function model.] One further element of the theory does load-bearing work: the layer-ordering principle. Enterprise design proceeds business function (what the business does, and for whom) -> organization (the construction of responsibilities and artifacts: an ontological view of the business processes) -> information (what must be known for those processes to work) -> technology (what enables the process and information flow). Each layer derives much of its requirements from the layer above. Working on construction before understanding the business function violates this ordering. This is why VVS scope is deliberately confined to the five dimensions of the business-function layer for the pre-PMF stage, and why the Standard's own first version, which carried organisational, informational, and technological dimensions, was narrowed in v2.0. [Figure 4: Enterprise design layers, each derived from the one above; VVS deliberately scopes to the function layer.] The layer-ordering principle carries a corollary the Standard treats as law: because each layer derives its requirements from the one above, change cascades downward from the point of change, never upward. A change in the ecosystem redefines the target customer within it; a redefined customer changes the problem, the job, and the value that can be captured; and the same holds through organization, information, and technology. Validation therefore expires downward: evidence at any level is conditional on the levels above it holding, and a pivot above writes off what was built below. Spending resources beneath an unvalidated layer is a leveraged bet that the layers above will not move. The one legitimate form of that bet is the experiment: minimal construction below, purpose-built to generate evidence for the layer above, sized to the evidence it must produce and priced as spend-at-risk rather than commitment. This is the formal ground of the lean tradition's riskiest-assumption-first discipline, and the reason the Standard reads a venture's confidence profile top-down: eighty percent confidence in Value Capture resting on thirty percent confidence in Ecosystem is not an eighty; it is a conditional eighty standing on a thirty. In development: the precise theoretical demarcation between the DEMO-based enterprise engineering approach and VVS, with full figure provenance. 3. WHAT COUNTS AS EVIDENCE If enterprise engineering supplies the ontology, the lean tradition supplies the epistemology. The unit of progress for a pre-PMF venture is validated learning: the conversion of an assumption into evidence through a test. Hypothesis-driven entrepreneurship supplies the discipline the Standard operationalizes: identify the riskiest assumption, test it first, and let the result reallocate effort. The Standard's contribution is to make this discipline accountable, through three mechanisms. Confidence as evidence held, not belief felt. Each dimension carries a confidence score defined against evidence criteria; not how strongly the team believes, but what has been demonstrated. The named signature. Every self-assessed score is signed by a named individual. A score is not a data entry; it is a commitment act by an accountable actor. A name on 'eighty percent confident' is skin in the game, and the record's value derives from it. The delta. Every venture is scored twice against the same definitions: by the team that runs it, and independently. Neither score alone is the product. The gap between them, the delta, is the risk signal: the measured distance between belief and evidence, per dimension, over time. Assessment recurs monthly, with event-triggered off-cycle entries. One snapshot is a photograph; the sequence is the record. The distinction matters formally: a snapshot validates at a point in time; only the sequence demonstrates trajectory, and trajectory, not level, is what predicts. [Figure 5: Two scores, one gap: self-assessed confidence, independent assessment, and the delta over time.] In development: per-dimension evidence definitions (admissibility of customer conversations; the evidentiary ranking of letters of intent, unpaid pilots, paid pilots, and revenue; evidence expiry; founder-reported versus independently verifiable evidence), the inter-rater reliability protocol, and the delta-pattern taxonomy. These are being formalised from live assessment practice. 4. THE GOVERNANCE MODEL: RISK-BASED SUPERVISION FOR THE PMF QUEST The third foundation is neither ontology nor epistemology but governance, imported from prudential regulation. Risk-based supervision, the model embedded in frameworks from Basel to Solvency II and practised by the regulators of leading financial jurisdictions, rests on a bargain: rather than imposing one uniform way of operating, the supervisor requires the entity to demonstrate that it understands its business, knows its risks, maintains controls proportionate to them, and can demonstrate that those controls are effective. Supervisory attention then concentrates where demonstrated understanding is weakest. VVS applies this bargain to the venture-backer relationship. Its clearest structural parallel is the Own Risk and Solvency Assessment: the regulated entity self-assesses its risks; the supervisor independently reviews; the gap between the two drives supervisory intensity. Self-assessment, independent assessment, delta: the Standard is that mechanism transported to the venture seeking product-market fit, with three roles strictly separated. The founder owns the risks and the self- assessment, and accepts the discipline as a condition of investment, or declines it before capital moves. The backer mandates the Standard, owns enforcement of the cadence, and directs attention by the delta, but does not negotiate the independent score. The assessor measures, and does nothing else. Measurement is structurally separated from capital allocation: the assessing function neither invests, transacts, nor advises on allocation. This separation is not a commercial preference but a design principle carried over from its source domain, where the supervisor's authority depends entirely on having no position in the outcomes it assesses. [Figure 6: Role separation under risk-based supervision: three parties, one record, measurement independent of allocation.] This governance model resolves the tension that dooms most reporting regimes: surveillance produces compliance theatre. The record must serve the founder first (focus, honest prioritization, protection of the backer relationship, a compounding diligence asset) and the backer second. A regime experienced as monitoring alone yields forms filled and honesty withheld, and the delta then measures nothing. The Standard's asks are therefore priced symmetrically: the founder owes time, honesty, and exposure; the backer owes enforcement, habit, and restraint. 5. THE STANDARD IN BRIEF Five dimensions (Ecosystem, Target Customer, Customer Problem, Customer Job, Value Capture), each carrying a self-assessed confidence score under named signature, an independent assessment against the same evidence definitions, and the delta. Monthly cadence; event-logged off-cycle entries; the sequence of snapshots constituting the venture's validation record. Scope: from idea to the finish line, which is a conjunction of two correlated but distinct tests: product-market fit (the direction of force reversed, the market pulling the product from the venture) together with an evidenced path to cashflow positivity: the venture creating more value than it consumes, and thereby earning its place in its ecosystem. Neither test implies the other; the Standard requires both. At that point the Standard hands off to conventional accounting, and the venture's construction becomes the design object. The normative specification, versioned with a public changelog, lives at validation.works/standard. In development: cadence boundaries: the earliest meaningful assessment, hand-off criteria, off- cycle triggers, and the list of what the Standard explicitly does not measure. 6. EARLY EVIDENCE, RELATED-PARTY DISCLOSURE, AND LIMITATIONS The Standard operates in live assessment practice, deliberately including on the authors' own companies. Validation.Works is assessed under its own Standard, on the same cadence, with the same named-signature rule, and publishes its record at validation.works/record. Three properties of that record bear noting. First, it begins where it began: with a crude, single-sided founding measurement in March 2026 that scored the authors' own Value Capture at zero: 'Guessing.' Second, between the June and August 2026 snapshots, two scores fell while others rose. A record that cannot fall cannot be trusted when it rises; scores falling under scrutiny is the mechanism working. Third, successive snapshots carry different named assessors (the two authors), a first, minimal instance of the inter-rater discipline the Standard requires at scale. The live record remains the source of truth for current state; this paper cites only dated events from its history. Full disclosure: the Standard's first commercial adoption is by an investment entity affiliated with one of the authors, under a related-party contract disclosed to all parties at signing. We state this because the Standard's own epistemics demand it: related-party evidence is weak evidence, and we score it accordingly. Whether independent parties will pay unprompted is, at the time of writing, the authors' least-validated claim, and our own published record says so. The Standard's history, however, is longer than its record. Across the fifty-plus entities the authors built, backed, advised, or buried over the preceding decade, the underlying discipline (riskiest assumption first, evidence before construction, confidence tied to what has actually been demonstrated) was applied in a handful and absent in the rest. The asymmetry in outcomes is stark: the entities run on the discipline are, at the time of writing, alive or concluded on their own terms; of the roughly forty where the discipline was not applied, none is. We state this evidence exactly as the Standard requires us to state it: it is retrospective, observational, and classified by the same people now advancing the conclusion. It is exposed to selection effects (the discipline may have been applied where conviction was already stronger), to survivorship framing, and to the base rate that most early-stage ventures fail regardless. It is a practitioner's pattern, not a proof: strong enough to justify formalising the Standard and testing it prospectively; not strong enough to cite as validation. Converting these cases into a rigorous retrospective analysis is the work noted below. Limitations, stated plainly: the evidence base is small and early. No prospective outcome data yet links formalised delta patterns to venture survival: the Standard's central predictive claim, and the core of the research agenda. The evidence definitions are being formalised from practice and will change. And the independent-assessment function is currently performed by the Standard's authors; its independence at scale depends on an assessor-certification layer that does not yet exist. In development: retrospective case analysis across the fifty-plus entities in the authors' history: the dimension-level false-evidence patterns that preceded failure, and the assessment cycle at which the Standard, had it existed, would have forced the kill or pivot decision. 7. VERSIONING, OPENNESS, AND THE RESEARCH AGENDA The Standard is published as a versioned, living specification with a public changelog (no silent edits) and freely usable instruments; independent assessment, certification, and the ledger are services built upon it. The research agenda, in order of consequence: outcome linkage: do delta patterns predict venture survival and capital efficiency; inter-rater reliability: do independent assessors converge, and what calibration instrument proves it; evidence definitions: formal criteria per dimension per confidence level; and scope boundaries: the earliest meaningful assessment and the product-market-fit hand-off. We invite adversarial review of all four, and of the theoretical mapping in section 2, in particular from the enterprise-engineering community whose work this Standard applies to a new object. Origin note: the Standard grew from two parallel master's theses written a decade before the company: one applying DEMO-based enterprise engineering to what an enterprise essentially is, the other applying validated learning to whether a platform should exist, and has since been tested, informally and then formally, across more than fifty entities the authors built, backed, advised, or buried. REFERENCES Dietz, J.L.G. (2006). Enterprise Ontology: Theory and Methodology. Springer. Dietz, J.L.G. & Mulder, H.B.F. (2020). Enterprise Ontology: A Human-Centric Approach to Understanding the Essence of Organisation. Springer. Hoogervorst, J.A.P. (2009). Enterprise Governance and Enterprise Engineering. Springer. van der Meulen, T., de Vries, M. & Gerber, A. (2017). Demonstrating Approach Design Principles during the Development of a DEMO-based Enterprise Engineering Approach. Proceedings of ICEIS 2017, Vol. 3, pp. 471-482. van der Meulen, T. (2017). Towards a Useful DEMO-based Enterprise Engineering Methodology, Demonstrated at an Agricultural Enterprise. MEng dissertation, University of Pretoria. Ries, E. (2011). The Lean Startup. Crown Business. Eisenmann, T., Ries, E. & Dillard, S. (2012). Hypothesis-Driven Entrepreneurship: The Lean Startup. Harvard Business School Background Note 812-095. Blank, S. (2013). The Four Steps to the Epiphany. K&S Ranch. EIOPA, Solvency II: Own Risk and Solvency Assessment provisions. Basel Committee on Banking Supervision: Core Principles for Effective Banking Supervision. CHANGELOG v0.3 (24 August 2026): co-author review incorporated: enterprise-engineering demarcation and ecosystem-sustainability framing added to §2; transaction-pattern passage and figure removed as construction-layer material out of scope; layer definitions clarified; figures renumbered; author order updated. v0.2 (14 August 2026): first public working draft. v0.1 (13 August 2026): internal draft. ================================================================================ CONTACT AND PAGES ================================================================================ Contact: connect@validation.works https://validation.works/ — Home https://validation.works/standard — The Venture Validation Standard (VVS 2.0) https://validation.works/whitepaper — Whitepaper: Evidence Over Narrative (working draft v0.3) https://validation.works/record — Validation.Works' own live assessment record https://validation.works/allocators — For capital allocators https://validation.works/operators — For founders https://validation.works/vvs-protocol.txt — VVS self-assessment protocol for AI assistants