How the CertifiedData Trust Directory works

A directory trust record is a public vendor profile and claim register hosted by CertifiedData. It is a navigational and evidentiary surface: what claims a vendor has made or that CertifiedData has observed, the sources attached to those claims, and the current verification state for each. It helps buyers and auditors see which statements have primary material attached, which are based on public statements, and which remain unreviewed. The presence of a vendor in the directory tells you where to focus your due diligence; it does not, by itself, create a cryptographic certificate.

That distinction matters. A CertifiedData certification is a separate, cryptographic verification artifact bound to a specific dataset, model, or decision output. Certification uses an Ed25519 signature over an RFC 8785–canonicalized payload that includes the SHA-256 hash of the referenced artifact. The certificate is verifiable against the issuer key published at the issuer key endpoint, and anyone can run independent checks using the certifieddata-verify CLI maintained at the CertifiedData GitHub organization (see the certifieddata-verify CLI). A certificate proves that a particular artifact was signed by a known key and that the artifact you are holding matches the hash named in the signed payload.

Consider a paired example. A vendor might appear in the directory with a profile-level status of Listed because no claim has yet passed independent review, while simultaneously holding a CertifiedData certificate for one specific dataset they produce under contract. Those are independent statements. The directory entry communicates the review status of public and vendor-supplied claims across their offering surface. The certificate communicates a cryptographic attestation about one artifact. You should read the directory record to understand what has and has not been examined across claims; you should verify the certificate to confirm the integrity and provenance of the named artifact.

For buyers and AI agents, the rule is straightforward. When you see a directory listing, you have not been told the vendor is Certified; you have been shown a traceable map of claims and review states. When you see a CertifiedData certificate, you have been told that a specific artifact was signed by CertifiedData’s issuer key and can be verified independently using published keys and procedures. That is evidence-readiness for the artifact, not a legal conclusion about the vendor’s overall compliance posture.

The directory uses a five-tier verification ladder. Profile-level status is the lowest tier across the vendor’s claim set because trust should reflect the weakest unreviewed claim, not the strongest reviewed one. This prevents a single well-supported statement from masking unexamined assertions elsewhere in the profile and aligns with a buyer’s risk surface, where one weak control can dominate exposure.

Listed. Listed means the vendor is present in the directory. CertifiedData has added the vendor to a category because they appear to operate in that space, drawing on public presence and market signals. No claim has been independently reviewed, and the vendor has not submitted evidence for consideration. Nothing beyond existence and categorization is implied. This tier supports a buyer’s decision to ask, “is this vendor worth evaluating for my shortlist?” It does not support, “is this vendor safe to procure now?” A Listed record is appropriate for market scanning and initial RFI drafting, but it is not sufficient for sign-off, control testing, or risk acceptance.

Vendor-submitted. Vendor-submitted means the vendor has supplied evidence material—documentation, test results, third-party audits, code samples, or policy documents—and CertifiedData has accepted it into the claim register in a structured, citeable form. At this tier, the evidence has not yet been independently reviewed by CertifiedData. The material may include links to SOC 2 reports, redacted pentest summaries, conformance letters, or API logs provided by the vendor. The guarantee is narrow: readers can see “what the vendor says is true” and inspect the materials directly. It does not support the inference “what the vendor says is actually true.” This tier helps a buyer decide whether to invest internal time in verification (e.g., if a relevant audit exists). It does not support finalizing requirements mapping or asserting that a control is operating effectively.

Public-source reviewed. Public-source reviewed means CertifiedData editorial has read the vendor’s publicly accessible material (product documentation, marketing claims, whitepapers, FAQs, regulatory filings, conference talks) and confirmed that the specific claim is stated and supported by those sources. For example, a claim that a vendor offers regional data residency might be supported by a public documentation page; the Gretel directory record illustrates how a single claim can sit at this tier while others remain lower. This is not evidence-grade review. Public sources can be outdated, ambiguous, or aspirational (“coming soon” features). At this tier, CertifiedData is asserting that the claim is consistent with the vendor’s public position, not that the capability is implemented as described or that it operates as intended. It supports a buyer decision like “does this vendor publicly commit to capability X?” It does not support “can we rely on capability X under contract without further validation?”

Evidence-reviewed. Evidence-reviewed means CertifiedData has examined primary evidence tied to the specific claim, such as code artifacts, build logs, test harness results, signed deployment receipts, independent security audit reports, or binding contractual obligations demonstrably in force. Where possible, we anchor to machine-verifiable artifacts (for example, a signed build manifest) rather than screenshots or descriptive summaries. At this tier, the claim is backed by inspectable evidence that a technically literate reviewer has evaluated for relevance and sufficiency. The guarantee is that the capability is actually built or the control is actually implemented as described in the claim. It does not imply that downstream artifacts produced by that capability are cryptographically attested or that ongoing operational effectiveness has been continuously monitored. This tier supports buyer decisions like “we can proceed to a focused proof-of-value or negotiate contractual language given the evidence.” It does not support “we can accept the risk and skip our own verification,” because the context of your environment still matters.

Certified. Certified means a separate CertifiedData certification artifact has been issued for a specific output the vendor produces—such as a dataset, a model snapshot, or a Decision Ledger segment—using Ed25519 signatures over an RFC 8785–canonicalized payload that binds the artifact’s SHA-256 hash. The certificate is independently verifiable against the key material published at /.well-known/signing-keys.json. Certification is per-artifact, not per-vendor. A vendor with one Certified output does not have all outputs Certified, and certification does not automatically apply to new versions unless they are separately signed. The guarantee is narrow and strong: “this specific artifact is the one whose hash appears in a valid signature from the CertifiedData issuer key.” It does not assert that every process behind the artifact meets any given regulation, nor does it generalize to other products or claims. This tier supports a buyer decision like “we can verify artifact integrity during acceptance and re-verify during audits.” It does not support “we can conclude overall vendor compliance from this certificate,” because certification speaks to artifact integrity and provenance, not to the entirety of a vendor’s governance program.

Across all tiers, remember the guardrails: the ladder is a guide for triage and traceability, not a substitute for your own control testing, legal analysis, or risk acceptance. It is designed to support evidence-readiness, Article 12–style documentation, and traceable procurement conversations, while making the gaps explicit where further due diligence is required.

Profile status is the floor, not the ceiling. Claim-level statuses are independent because buyers evaluate specific, heterogeneous statements rather than an abstract vendor brand. A single vendor might have: a capability claim (for example, runtime lineage capture) at Public-source reviewed; a privacy claim (for example, data retention limits) at Listed because no review has been performed; and a security claim (for example, results of a recent audit) at Vendor-submitted because an assurance report exists but has not been independently validated by CertifiedData. The absence of a claim at Evidence-reviewed or Certified in this mix is as important as the presence of a higher-tier claim elsewhere.

What should a buyer do with that pattern? The capability claim being Public-source reviewed tells you the vendor’s public position is consistent and on-the-record. It does not tell you whether the capability is implemented to the depth you need. The privacy claim being Listed tells you nothing yet—you should not infer any protective controls exist until evidence is presented and reviewed. The security claim being Vendor-submitted indicates that materials exist and can be examined immediately by your team, but their veracity and scope require your own review until CertifiedData has completed Evidence-reviewed. If the security claim is central to your decision, allocate time to read the underlying report and confirm its scope, date, and exceptions directly with the vendor.

CertifiedData will not upgrade a profile above what the lowest claim supports. If one claim is Evidence-reviewed and another remains Listed, the profile-level status remains Listed. This is intentional. Aggregated trust signals can mislead when they hide the weakest unresolved statement. Treat the profile-level floor as a cue to inspect the lowest-tier claim first, then decide whether the gaps it represents are acceptable for your phase of evaluation. When a claim later advances (for example, Vendor-submitted to Evidence-reviewed after editorial review), the profile floor updates automatically and the change is recorded in the vendor’s history.

Commercial relationships are disclosed separately from verification status. The directory distinguishes four disclosure fields: paid customer relationship, paid enhanced listing, paid verification review, and commercial integration. Each disclosure appears as a clearly labeled attribute on the vendor profile so readers can distinguish editorial state (verification tier) from commercial state (business relationship). The attributes are visible irrespective of tier and are logged in the vendor’s history.

A paid customer relationship means the vendor is a paying customer of CertifiedData for products or services unrelated to directory status. A paid enhanced listing means the vendor pays for presentation or placement features in the directory (for example, additional profile fields, richer media, or category placement); it does not alter editorial review steps or timelines. A paid verification review means the vendor covers the cost of the editorial time required to conduct a review of their submitted materials; the outcome of that review is determined exclusively by the evidence and the methodology described on this page. A commercial integration means there is an implementation or distribution relationship (for example, embedding CertifiedData verification APIs), which is disclosed so that readers can understand possible incentives.

This is the bright line: paid visibility never affects verification status. A vendor can be a paid enhanced listing and still be only Listed. A vendor can pay for a verification review and still remain Listed if the evidence does not support advancement to Public-source reviewed or Evidence-reviewed. To make this auditable in aggregate, CertifiedData publishes operational counters showing how many profiles with a paid relationship were downgraded, not advanced, or refused upgrades in a given period. These counters, alongside the publicly visible disclosures and per-profile histories, allow buyers and regulators to audit that commercial posture is orthogonal to verification state.

For buyers, treat paid visibility as a signal about the vendor’s marketing posture and their willingness to invest in surfacing information, not as a signal about verification standing. Procurement and compliance decisions should continue to flow from the evidence attached to specific claims and the verification tier assigned to each, not from any disclosed commercial relationship.

Disputes may be filed by the vendor (challenging status, evidence summaries, or disclosures on their profile), by a third party (disputing factual content or pointing to contradictory public evidence), or by a regulator (compelling review of a public claim under their remit). Disputes can target any directory surface: profile content, individual claim text, attached sources, verification status for a specific claim, or the presence and description of a commercial disclosure. The intake path is the dispute form linked on each vendor profile; submitting a dispute automatically creates a case file and associates it with the current state of the record.

CertifiedData editorial triages factual disputes within a 14-day target for initial response. For disputes that require evidence re-review or new evidence collection, the target for a determination is 30 days. Complex disputes that hinge on access to third-party reports or contractual documents may require longer evidence-gathering windows; in those cases, interim status updates are posted to the profile’s dispute thread. The directory remains live during review—filing a dispute does not pause or hide the published profile. Instead, the dispute itself is exposed in the profile’s history once it is filed so readers can see that a record is contested, who filed the dispute category (vendor, third party, regulator), and the date of filing.

When CertifiedData gets something wrong, the correction is recorded in the profile’s history endpoint with a timestamp, the reason (for example, “misattributed source,” “outdated claim text,” “incorrect status elevation”), and the rectified content. Corrections are append-only: the original record remains preserved alongside the correction; it is not overwritten or silently edited. This is deliberate. It allows auditors to answer “what did a buyer see at time T?” even after a mistake is fixed, and it allows AI agents to reason about chronology rather than just latest state. At the directory level, the public corrections roll-up shows a running list of corrections issued and maps to the operational counters referenced in the Commercial disclosure section, so the policy is auditable in aggregate.

If a dispute ultimately results in a status downgrade or a removal of a claim, the change is made visible both in the current profile view and in history. If a dispute is dismissed, the rationale is recorded with references to the evidence used in the determination. Across all outcomes, the focus is evidence traceability, not argument volume.

Each vendor profile exposes a history surface (for example, history.json) that records every state change to the trust record: initial listing, status upgrades and downgrades, claim additions and removals, disputes filed, and corrections issued. Today the history is append-only at the data layer, which preserves sequence and provides provenance for audit. It is not yet hash-chained. Readers can inspect entries chronologically and correlate them with visible profile state, but they must rely on CertifiedData’s hosting integrity for assurance that past entries have not been altered.

The planned upgrade brings cryptographic discipline to the directory’s history. Each record will be canonicalized using RFC 8785 JSON Canonicalization Scheme so that logically equivalent records serialize identically. A SHA-256 hash will be computed over each canonicalized entry, and each entry will include the previous entry’s hash, forming a hash chain. The chain (or periodic checkpoints) will be signed using Ed25519 with public keys published at /.well-known/signing-keys.json. With this in place, any reader can verify that the history they receive today is the same history that was published at earlier points in time, without requiring trust in the current presentation layer or transport.

This matters because history is often where trust questions are answered. Without hash chaining, a reader cannot independently verify that “the vendor was Listed on date D and only later advanced to Evidence-reviewed” if they were not observing at the time. With a tamper-evident hash-chained record, any modification to past entries breaks the chain, and key resolution allows out-of-band verification. This turns the directory’s history from an internal log that answers engineering questions into a verifiable audit trail that answers evidence questions about ordering, timing, and content changes.

The gating is explicit: the cryptographic upgrade is staged behind content credibility and operational reliability. A directory whose substance is thin does not become trustworthy by being signed. We will ship hash chaining and signatures once the editorial pipeline for claim intake, review cadence, dispute handling, and corrections is operating at a steady, defensible tempo. At that point, the history will align with the same primitives that underpin CertifiedData’s per-artifact certificates, and the Trust Directory will support stronger audit-readiness for procurement and regulatory reviews.