| Principle | Meaning |
|---|---|
| Capability over completion | Credentials are meant to signal demonstrated capability through observable work, scenario performance, review, or other inspectable evidence. |
| Readable before issuance | The claim, the expected capabilities, the verification mode, and the intended outcome are published before a credential is awarded. |
| Portable learner ownership | The model is designed around learner-controlled, machine-readable credentials rather than a platform-locked completion badge. |
| Open inspection surfaces | The issuer page, JSON catalog, plaintext summary, policy page, and verifier manifest are public so humans and software can inspect the framework directly. |
| Expectation |
|---|
| Inspect the issuer page, catalog, and policy together before treating a credential as trustworthy. |
| Review the specific credential claim, pathway, level, and verification method instead of inferring more than is published. |
| Treat this framework as a capability layer, not a substitute for legal licenses or regulated professional requirements. |
| Guidance |
|---|
| The public catalog is intentionally framework-level and does not publish learner records. |
| Verification should minimize unnecessary collection and ask only for the information required to confirm the credential claim. |
| This public surface is designed for discovery and inspection, not for exposing private learner data. |
| Policy |
|---|
| Catalog and policy updates are versioned and published at stable URLs. |
| Verification and standards language can evolve, but major changes should preserve backward-readable documentation. |
| Material changes should update the public policy, manifest, and discovery links together. |
| Boundary |
|---|
| This public surface describes the issuer and framework; it is not a remote pass/fail verification oracle for an individual learner record. |
| Credential use in regulated domains may require additional licensing, accreditation, or employer review. |
| Open standards language does not by itself guarantee interoperability with every verifier implementation. |
| Surface | Endpoint | Purpose |
|---|---|---|
| Credential catalog | https://lotdpbc.com/credentials | Canonical public page for the credential framework and pathway catalog. |
| Credential summary JSON | https://lotdpbc.com/.well-known/credentials.json | Well-known discovery summary for agents and integrators. |
| Credential Atom feed | https://lotdpbc.com/credentials.atom | Syndication feed for the credential catalog and trust surfaces. |
| Credential catalog JSON | https://lotdpbc.com/credentials.json | Machine-readable catalog of pathways, credentials, and verification flow. |
| Credential summary text | https://lotdpbc.com/credentials.txt | Plaintext summary for lightweight human and machine inspection. |
| Verifier guide | https://lotdpbc.com/credentials-verifier | Human-readable guide for institutions, employers, and software verifiers. |
| Verifier manifest JSON | https://lotdpbc.com/credentials-verifier.json | Read-only discovery surface describing verification checks, endpoints, and limitations. |
| Site discovery JSON | https://lotdpbc.com/.well-known/lotdpbc-discovery.json | Site-wide routing surface for public LOTD machine-readable resources. |
| Broadcast manifest | https://lotdpbc.com/.well-known/lotdpbc-broadcast.json | High-signal crawl-now manifest for loud public LOTD resources. |
This issuer policy is public by design. A verifier should not need to guess what the framework claims, how it thinks about evidence, or where the supporting discovery surfaces live.