What stands behind what we say.

Our evidence position in 30 seconds

We distinguish three things: evidence that a method exists, evidence that a product has been built and tested, and evidence that a customer achieved a result. We hold the first two. We do not yet publish the third, so you will find no testimonials, case studies or performance figures anywhere on this site. When consented, documented customer evidence exists, it will appear here with its scope and limits attached.

The detail below is for anyone — a validation panel, a procurement team, a careful buyer — who wants the full classification.

The premise

What we can prove, what we have merely done, and the difference.

This page sets out how we classify evidence, which class can support which kind of claim, and — necessarily — what we do not currently have.

The rule

Doing something is not proof that it worked for someone else.

Internal testing, founder use, product-generation exercises and demonstration projects can show that the method can be operated. They cannot show that customer capability or customer outcomes improved. We treat that distinction as a hard rule, not a stylistic preference.

Evidence classes and their permitted use
Evidence type	What it may be used to show	What it may never be used to show
Internal method evidence	Operational discipline, workflow completeness and internal quality control. That we run our own method on our own work.	That customers achieved the same result. Our own use is not your outcome.
Product-generation evidence	How a reference workflow, course, diagnostic or workflow pack was designed and tested. Design logic and repeatability.	Market-wide effectiveness or client transformation. Building something well is not evidence it works for you.
Client field-work evidence	Specific customer capability, workflow or output claims — where the evidence is consented, representative and documented.	Anything beyond the tested role, context or sample. No quiet generalisation from one sector to all of them.
Microcredential evidence Future	Future architecture. When it exists: assessed performance, artefacts, reflection, workflow operation and verification decisions, within a stated scope.	Professional licensure or universal competence, unless explicitly authorised by a body with standing to authorise it.

The vocabulary

Six evidence terms, used precisely.

These words are not interchangeable, and we do not treat them as such. Every claim on this site is meant to sit against exactly one of them. Reliability is not validity; self-reported confidence is not verified competence.

The six evidence terms and what each does not, by itself, establish
Term	What it means	What it does not, by itself, establish
Problem validated	Credible evidence that a defined customer recognises, prioritises and may pay to solve the problem.	Product effectiveness or instrument validity.
Product piloted	The offer was delivered with real customers under bounded conditions and its operation was documented.	Repeatability, scale or customer transformation.
Workflow tested	The workflow was run on authentic work and its failures, exceptions and support needs were captured.	Broad effectiveness or transfer across populations.
Output verified	The output passed declared professional, quality or acceptance checks.	General or transferable competence of the person.
Instrument evidence-supported	A specified score interpretation is supported for a named population and use by an approved body of evidence.	Validity for every population, use or consequential decision.
Capability assessed	Authentic performance and evidence met an approved assessment standard in a stated context.	Universal competence, licensure or unsupervised transfer to other contexts.

The diagnostic is offered as a Controlled Developmental Release: it is not yet instrument evidence-supported, and it is never a basis for a consequential decision. The developmental profile →

Current position

Where Edney Learn actually stands today.

Method evidence

Held

We use the ten-stage design method to build our own standard operating procedures, production workflows and operating routines. The method is documented and published in full on this site.

Supports: that the method exists, is specified, and is operated internally.

Product evidence

Held

The role-specific reference workflows, the diagnostic construct and the workflow packs were designed using the method and tested against real work during construction.

Supports: design logic and repeatability of the products themselves.

Client field-work evidence

Not yet held

None published. The verticals are new and the pilot cohorts are in progress. When consented, representative, documented client evidence exists, it will appear here with its scope and limitations attached.

Consequence: no customer outcome claims anywhere on this site.

What this means when you read the rest of the site

You will find no testimonials, no case studies, no percentage improvements, no time-saving figures and no client logos. Not because we are being modest, and not because they are coming soon in a marketing sense, but because we would have to invent them, and the entire proposition of this company is that invented evidence is the problem we exist to solve.

Publication gates

What has to be true before we publish anything about a customer.

Four promises, in plain terms. We publish only with specific written consent for that use; only when the IP boundary is confirmed so nothing you own or must keep confidential is disclosed; anonymised by default unless you ask to be named; and with the claim's limits stated — context, role and sample.

Nothing is published unless the consent and the IP confirmation are both on record.

Application contexts

Same method, three different evidence positions.

Context	What happens	Evidence implication
Internal operations	We design our own SOPs, production workflows and operating routines with the method.	Shows internal operational discipline. Does not prove client outcomes.
Product generation	We create reference workflows, course structures, workflow packs and product systems with it.	Shows product design logic and repeatability. Does not prove customer transformation.
Client field work	A customer applies the method to build their own workflow, through a course, workshop, coaching engagement or programme.	Can support customer outcome claims where consent, evidence quality and claim boundaries are satisfied.

See the Workflow Design Method Map for how these relate.

Claims we will not make

Guaranteed commercial success
Universal elimination of professional specialists
Complete automation of professional judgment
Instant originality
One-click trade-standard books
Professional quality without serious customer participation
Guaranteed acceptance by Amazon, IngramSpark or any external platform

What we will stand behind

These are the claims we make, because the evidence supports them:

You can build a reusable workflow
You can reduce unnecessary fragmentation in your production process
You can improve consistency and quality control
You can prepare publication-ready files, subject to platform specification and final checks
You can identify where independent specialist review remains valuable
You can retain greater ownership of the process and the intellectual property

The codified-knowledge claim, stated precisely

Our workflow products embed codified domain best-practice. That is a statement about how the product is constructed: a mechanism.

It is not a guarantee of the output you will produce, the quality you will reach, or the result you will get. Those depend on your inputs, your judgment and your participation. Anywhere on this site that the codified-knowledge advantage appears, it appears as mechanism and never as promise.

Found something that breaks these rules?

If any page on this site presents internal or product evidence as proof of a customer outcome, that is a defect and we want to know. Tell us →