Digital Credential PlatformsDigital Credential Platforms
Research standards

Research Methodology

How Digital Credential Platforms researches, verifies, and compares credentialing technology

On this page
  1. 1. Our Research Principles
  2. 2. Research Scope and Platform Selection
  3. 3. The DCP Evidence Framework
  4. 4. Research Records and Traceability
  5. 5. Our Evaluation Process
  6. 6. Hands-On Testing: What It Means
  7. 7. Credential Standards and Interoperability
  8. 8. How We Use Customer Reviews
  9. 9. Missing Information and Research Limitations
  10. 10. Research Maintenance and Corrections
  11. 11. Commercial Relationships
  12. 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

DCP six-stage research process: define, discover, verify, evaluate, review, and maintain.
The DCP Evidence & Evaluation Framework: six stages from research question to maintained findings.

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:

RequirementAssessment
Category relevanceThe product addresses the credentialing problem being researched
Product availabilityThe platform is publicly available or its commercial availability can be substantiated
Identifiable providerThe organization responsible for the product can be established
Assessable informationSufficient evidence is available to describe meaningful capabilities and limitations
Comparative relevanceThe 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 classDescriptionAppropriate use
A – Directly verifiedCapability observed through documented hands-on testing, a reproducible demonstration, or independent technical verificationSupports a direct finding within the limits of the test
B – Officially documentedCurrent vendor documentation, product specifications, pricing pages, API documentation, or recognized standards registriesSupports a documented capability or published commercial term
C – Externally reportedReputable third-party reporting, independently published research, or attributable user experienceProvides corroboration and contextual evidence
D – UnconfirmedClaims that cannot be adequately substantiated, including incomplete or ambiguous vendor statementsIdentified 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:

  1. Authority: Who produced the information, and are they positioned to know?
  2. Specificity: Does the source establish the precise claim, or only something broadly related?
  3. Currency: Does the evidence reflect the product and version currently being assessed?
  4. 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.

FieldPurpose
Product and providerIdentifies what is being evaluated
Research categoryDefines the comparison context
Assessment criterionIdentifies the capability or requirement
FindingRecords the conclusion reached
Supporting sourceLinks to documentation, a registry, a test, or another source
Evidence classShows the type of verification
Date checkedEstablishes when the evidence was reviewed
LimitationNotes unresolved questions and relevant uncertainty
Editorial decisionRecords 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:

WorkflowWhat can be evaluated
Account setupRegistration and initial configuration
Credential designTemplates, branding, metadata, and customization
IssuanceIndividual and bulk issuance processes
DeliveryRecipient notification and access
SharingPublic credential pages and supported sharing methods
VerificationAuthenticity checks and verification behavior
LifecycleUpdating, expiring, or revoking credentials
IntegrationsDocumented 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:

FindingMeaning
SupportedSufficient evidence establishes the capability within a defined scope
Not supportedReliable evidence establishes that the capability is unavailable or outside the product’s stated scope
Not verifiedAvailable 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.