On this page
- 1. Our Research Principles
- 2. Research Scope and Platform Selection
- 3. The DCP Evidence Framework
- 4. Research Records and Traceability
- 5. Our Evaluation Process
- 6. Hands-On Testing: What It Means
- 7. Credential Standards and Interoperability
- 8. How We Use Customer Reviews
- 9. Missing Information and Research Limitations
- 10. Research Maintenance and Corrections
- 11. Commercial Relationships
- 12. Questions and Evidence Submissions
This framework defines the evidence and review standards for DCP assessments. It does not establish that any existing article has completed every step. Each assessment should identify its sources, verification date, research method, and limitations; hands-on testing must only be claimed when it is documented.
Digital Credential Platforms (DCP) is a specialist research and comparison publication covering software for digital certificates, badges, micro-credentials, and credential management.
Our research is designed to help organizations evaluate technology using documented capabilities, transparent assessment criteria, and the practical requirements of credential programs.
This page explains the DCP Evidence & Evaluation Framework: how we select platforms, collect evidence, assess product claims, distinguish fact from interpretation, and maintain our research over time.
Our separate Scoring Methodology explains how evidence is converted into numerical ratings. Our Editorial Policy covers publishing standards, corrections, and commercial disclosures.
1. Our Research Principles

Five principles guide DCP’s research framework.
Evidence before conclusions. Product capabilities, pricing, and technical claims must be supported by identifiable sources. Unsupported claims are not treated as established facts.
Consistent evaluation. Products in the same comparison are assessed against a defined set of criteria. Differences in assessment methods must be disclosed.
Relevance to real buying decisions. We prioritize capabilities that materially affect implementation, credential issuance, recipient experience, verification, interoperability, and ongoing program management.
Transparency about limitations. Documentation review is not presented as hands-on testing. When information is incomplete, outdated, or unverified, that limitation is identified.
Editorial accountability. Published conclusions must be explainable, revisable, and open to documented correction.
2. Research Scope and Platform Selection
DCP covers technology used to design, issue, deliver, manage, share, and verify digital credentials.
Our coverage includes:
- Digital certificate and badge issuing platforms.
- Credential management and verification software.
- Open Badges and standards-based credentialing systems.
- Digital diploma and academic credential solutions.
- Enterprise learning and workforce credentialing products.
- Certificate generators and specialized issuing tools.
We consider products for inclusion based on their relevance to a defined category or use case, rather than market size alone.
Platform eligibility
A product may qualify for evaluation when it meets the following conditions:
| Requirement | Assessment |
|---|---|
| Category relevance | The product addresses the credentialing problem being researched |
| Product availability | The platform is publicly available or its commercial availability can be substantiated |
| Identifiable provider | The organization responsible for the product can be established |
| Assessable information | Sufficient evidence is available to describe meaningful capabilities and limitations |
| Comparative relevance | The product is a credible alternative for the intended audience or use case |
Products may be excluded from a particular ranking because they serve a different use case, lack sufficient verifiable information, are discontinued, or fall outside the research scope.
Exclusion is not necessarily a judgment about product quality.
A focused shortlist is not presented as an exhaustive market census unless the research actually covers the entire defined market.
3. The DCP Evidence Framework
We distinguish between what a product demonstrably does, what its provider documents, what third parties report, and what remains unverified.
Evidence classifications
| Evidence class | Description | Appropriate use |
|---|---|---|
| A – Directly verified | Capability observed through documented hands-on testing, a reproducible demonstration, or independent technical verification | Supports a direct finding within the limits of the test |
| B – Officially documented | Current vendor documentation, product specifications, pricing pages, API documentation, or recognized standards registries | Supports a documented capability or published commercial term |
| C – Externally reported | Reputable third-party reporting, independently published research, or attributable user experience | Provides corroboration and contextual evidence |
| D – Unconfirmed | Claims that cannot be adequately substantiated, including incomplete or ambiguous vendor statements | Identified as unverified; not presented as established capability |
Evidence classification is not equivalent to product quality.
A platform can have a well-documented feature without DCP having tested it directly. Conversely, a successful demonstration does not establish long-term reliability, scalability, or support quality.
Source evaluation
Under this framework, researchers should assess sources using four considerations:
- Authority: Who produced the information, and are they positioned to know?
- Specificity: Does the source establish the precise claim, or only something broadly related?
- Currency: Does the evidence reflect the product and version currently being assessed?
- Independence: Is the source provided by the vendor, an independent standards body, a customer, or another interested party?
For example, a vendor’s statement that it supports Open Badges is different from an independently verifiable certification in a recognized standards directory.
These statements should not receive identical evidentiary treatment.
4. Research Records and Traceability
A DCP platform evaluation should be supported by a structured research record connecting important findings to their sources.
Each material finding should have an identifiable basis.
| Field | Purpose |
|---|---|
| Product and provider | Identifies what is being evaluated |
| Research category | Defines the comparison context |
| Assessment criterion | Identifies the capability or requirement |
| Finding | Records the conclusion reached |
| Supporting source | Links to documentation, a registry, a test, or another source |
| Evidence class | Shows the type of verification |
| Date checked | Establishes when the evidence was reviewed |
| Limitation | Notes unresolved questions and relevant uncertainty |
| Editorial decision | Records how the finding informs the published assessment |
This structure supports more consistent reviews, comparisons, and ranking updates.
It also provides a basis for investigating corrections without reconstructing the research from memory.
5. Our Evaluation Process
Stage 1 – Define the buyer’s decision
Every research project should begin with a defined question.
Examples include:
- Which platforms are appropriate for high-volume certificate issuance?
- Which systems support portable, standards-based digital badges?
- What software is suitable for universities issuing verifiable credentials?
- How do credential platforms differ in automation, pricing, and recipient experience?
Before comparing vendors, researchers should establish the intended audience, operating context, relevant product category, and essential capabilities.
Stage 2 – Establish the research universe
Researchers should identify potentially relevant products through category research, vendor documentation, standards directories, product databases, and other appropriate sources.
A research universe is broader than the shortlist ultimately published.
Where a comparison selects a limited number of products, its scope and selection rationale should be explained.
Stage 3 – Collect product evidence
Research addresses the capabilities relevant to the defined use case.
Typical areas include credential creation and design, issuance workflows, recipient delivery, verification, interoperability, integrations, administrative controls, analytics, pricing, and lifecycle management.
Findings should be recorded at the capability level rather than relying only on broad descriptions such as “enterprise-ready” or “easy to use.”
Stage 4 – Verify material claims
High-impact claims require particular attention.
These include:
- Standards compliance or certification.
- Security and identity-related functionality.
- Published subscription prices and usage limits.
- Revocation and credential verification capabilities.
- Native integrations and API availability.
- Data portability, access controls, and export functionality.
Where evidence is incomplete, the claim should be qualified or excluded from a definitive conclusion.
Stage 5 – Evaluate tradeoffs
Products are considered in relation to the buying problem.
A platform suitable for individual course creators may differ substantially from one designed for institutional diplomas or large enterprise credential programs.
Comparisons should explain meaningful differences rather than assuming one feature set is universally superior.
Stage 6 – Score eligible products
Where a numerical evaluation is appropriate, researchers should apply the criteria, weights, and evidence requirements documented in the DCP Scoring Methodology.
A score does not replace the underlying explanation.
The published assessment should make clear which strengths, limitations, and tradeoffs contributed to the result.
Stage 7 – Conduct editorial review
Before publication, research and accompanying copy should be checked for internal consistency, source accuracy, calculation errors, unsupported claims, and missing context.
Articles must not describe documentation-based research as hands-on testing.
Material uncertainties and relationships relevant to interpreting the evaluation must be disclosed.
Stage 8 – Publish and maintain
Published research should identify its scope, applicable methodology, and date of verification.
Material changes to product facts or evaluation results may trigger a review and, where appropriate, an update or correction.
6. Hands-On Testing: What It Means
DCP distinguishes direct testing from research based on published documentation.
A hands-on evaluation means that the researcher has actually used the relevant product or participated in a sufficiently observable product demonstration.
When direct testing is performed, the test record should identify the product, version or plan where relevant, tested workflow, test conditions, observations, and limitations.
A typical credential issuance test may include:
| Workflow | What can be evaluated |
|---|---|
| Account setup | Registration and initial configuration |
| Credential design | Templates, branding, metadata, and customization |
| Issuance | Individual and bulk issuance processes |
| Delivery | Recipient notification and access |
| Sharing | Public credential pages and supported sharing methods |
| Verification | Authenticity checks and verification behavior |
| Lifecycle | Updating, expiring, or revoking credentials |
| Integrations | Documented or directly tested connections and APIs |
Not every evaluation includes all these tests.
Where direct product access has not been obtained, DCP should explicitly identify the assessment as documentation-based.
It should not imply that an editor personally tested functionality that was only described in product documentation.
7. Credential Standards and Interoperability
Interoperability requires more careful evaluation than a simple feature checklist.
DCP distinguishes between several different claims:
- A product offers publicly accessible credential verification.
- A product supports structured credential metadata.
- A product implements a recognized credential standard.
- A product is independently certified against a specified standard.
- A product supports practical import, export, or interoperability workflows.
These are related but not interchangeable capabilities.
Where appropriate, DCP considers specifications and recognized certification directories associated with Open Badges and verifiable credentials.
Published findings should identify the relevant standard or version where that distinction materially affects compatibility.
8. How We Use Customer Reviews
Customer reviews can reveal practical information about implementation, usability, support, reliability, and everyday operations.
However, reviews are not automatically treated as representative measurements of product quality.
Review platforms differ in their collection methods, moderation policies, incentives, reviewer populations, and rating systems.
Accordingly, DCP distinguishes:
- Documented product capabilities.
- Directly observed product behavior.
- Attributable user-reported experiences.
- Quantitative review-platform ratings.
Third-party user ratings should not be combined into a proprietary numerical score unless DCP has defined and documented an appropriate method for validating, normalizing, and weighting those data.
A small number of reviews should not be presented as evidence of broad market consensus.
9. Missing Information and Research Limitations
An absence of published evidence does not automatically mean a capability is absent.
DCP uses three distinct findings:
| Finding | Meaning |
|---|---|
| Supported | Sufficient evidence establishes the capability within a defined scope |
| Not supported | Reliable evidence establishes that the capability is unavailable or outside the product’s stated scope |
| Not verified | Available research is insufficient to determine whether the capability is supported |
This distinction is particularly important when evaluating private enterprise features, custom integrations, contractual pricing, or functionality available only in specialized plans.
A platform should not be penalized for a documented capability merely because DCP has not tested it. Equally, unsupported assumptions should not fill gaps in research.
Where significant gaps prevent a fair assessment, the product may be described without receiving a numerical score.
10. Research Maintenance and Corrections
Digital credential software changes over time.
Important changes may include pricing revisions, new standards support, product discontinuation, acquired platforms, security changes, integration availability, and altered usage limits.
DCP’s maintenance model prioritizes updates according to their impact on buying decisions.
High-priority changes: Incorrect scores, discontinued products, broken verification claims, significant pricing errors, or material changes affecting a published recommendation.
Routine changes: Additional integrations, revised product documentation, new plans, or incremental feature releases.
Editorial improvements: Added context, clearer explanations, improved sources, or presentation changes that do not alter the underlying assessment.
A visible review date should represent an actual substantive check, not merely a website publishing or formatting change.
Where a material correction changes an evaluation or recommendation, the change should be recorded transparently.
11. Commercial Relationships
DCP may have advertising, affiliate, sponsorship, or other commercial relationships with companies covered in its research.
Commercial arrangements must not be represented as independent evidence of product quality.
Sponsored placements, where offered, should be distinguishable from editorial recommendations.
Material professional or commercial relationships that could affect readers’ interpretation of a comparison should be disclosed in an appropriate, visible context.
Providers may submit factual corrections and supporting documentation. Submission does not guarantee a favorable evaluation.
Our governance rules are described in the Editorial Policy.
12. Questions and Evidence Submissions
Software providers, researchers, and readers may submit factual corrections, product documentation, or methodological questions to:
hello@digitalcredentialplatforms.com
Please include the relevant page, the disputed statement, and a supporting source where available.
Credible new evidence can justify a revision. Disagreement with an editorial conclusion alone does not automatically establish an error.
