Skip to content

CONCEPT Cited by 1 source

Certification as metadata not enforcement

Definition

Certification as metadata not enforcement is the design property that review status of a registered artifact — security approval, API-contract validation, PII-handling check, compliance attestation — is held in the registry as metadata that informs adoption decisions, not as a runtime gate the registry itself enforces. The actual review work is performed externally by the security organisation through its existing tooling; the registry's contribution is visibility at the right moment.

"Certification status (things like security approval, API contract validation, PII handling checks) is metadata that the registry surfaces, not a boundary that the registry itself enforces. The actual review work happens through the security organization's existing tooling. The registry's contribution is making the result of that review visible at the moment a team is deciding whether to adopt a tool, ensuring the review actually informs the decision it was meant to inform." — Source: sources/2026-05-11-mongodb-fighting-tool-sprawl-the-case-for-ai-tool-registries

The two roles the property keeps separate

This concept is a special case of the broader registry vs policy layer split, applied to certification specifically:

Role Where it lives What it does
Review work Security organisation's existing tooling (ticketing, threat modelling, scanners, manual review) Performs the review and produces a verdict
Verdict storage Registry, as metadata on the registered artifact Surfaces the verdict at adoption time
Enforcement Policy layer, which reads the metadata at request time Applies the verdict as an allow/deny rule

A tool can be: registered without review (registry holds it, metadata says "unreviewed"); registered + reviewed + approved (registry holds the approved status as metadata, but the registry doesn't block use); registered + reviewed + rejected (same shape — metadata says "rejected," and the policy layer reads that and denies).

Why the property matters

If the registry enforced certification (e.g. refused to list unreviewed tools), three failure modes appear:

  1. Pre-registration shadow. Teams register tools elsewhere (or don't register them) until they pass review. The registry loses its role as the complete inventory.
  2. Review-first ordering inversion. Adoption decisions require review-completion as a hard prerequisite, even for prototyping or scoping work that should precede formal review.
  3. Brittle review-tool coupling. If review status is enforced by the registry, the registry needs to model the review-tool's lifecycle; review tools change, so the registry needs to track them — a coupling the registry should not own.

By keeping certification as metadata:

  • The registry holds everything (registered ≠ approved). It remains the source of truth for what exists.
  • Review can be out-of-band at whatever speed the security organisation operates.
  • The policy layer enforces whatever rule it wants against the metadata: "deny if not approved," "warn if pending," "allow with read-only scope until approved."

The "moment of decision" property

The post sharpens the framing with a precise claim about when metadata is most valuable:

"…ensuring the review actually informs the decision it was meant to inform."

The structural property: a security review's value is realized at the moment a team decides whether to adopt the tool, not at the moment the review is filed. If the review verdict is stored in a separate ticketing system the adopting team doesn't look at, the review didn't function as a gate. The registry's job is to make the verdict visible at adoption time — i.e. to surface the metadata next to the tool's discoverable entry.

Composability with policy

Once certification is metadata in the registry, the policy layer has a clean dependency:

policy rule: deny if registry.cert_status == "rejected"
policy rule: allow if registry.cert_status == "approved" AND identity.team in registry.allowlist
policy rule: warn if registry.cert_status == "pending"

The same metadata is consumed by:

  • Humans at adoption time (registry UI shows the cert badge).
  • Policy layer at request time (registry API returns the cert status as part of a tool descriptor).
  • Audit / forensics post-incident (cert status at time-of-call is a query against the registry's history).
  • vs concepts/data-classification-tagging: data classification tagging applies the same metadata-vs-enforcement separation at the data layer (tags drive ABAC policies). Certification-as-metadata applies it at the tool layer. The same architectural argument generalises.
  • vs concepts/registry-as-governance-precondition: the precondition concept is the broader argument that an inventory is upstream of governance; certification-as-metadata is the specific consequence about how certification status flows through the inventory without coupling to it.
  • vs runtime gating by the registry: a registry that enforced would be effectively a policy layer; that's a different architecture and produces the failure modes above.

Seen in

Last updated · 542 distilled / 1,571 read