⬢ licensefoundry

Public methodology · Auditable scoring

Compliance scoring
framework v1.0

How LicenseFoundry assesses the completeness of a credential against current legislative expectations. The credential records what the data owner asserts; the score independently reports how complete that assertion is for compliant downstream use. Eight categories. Six jurisdiction-weighted views. Fully public methodology.

Version 1.0 · Published 24 May 2026 · Endpoint: /v1/credentials/{id}/compliance-score

The principle.

LicenseFoundry plays two roles, and conflating them creates essentially every legal and compliance risk in our architecture.

As issuer, we sign a credential containing exactly the rights the data owner asserted. We attest to the authenticity of the signature — not to the truthfulness or completeness of the assertion.

As verifier scorer, we compute a score against this published framework at verification time. We attest that the framework reflects our reading of current legislation; verifying labs decide how much weight to give it.

Three rules follow from this split:

  1. Issuance never adds rights. Every right in the credential traces to an explicit assertion by the data owner. No defaults; no inferences.
  2. Scoring is computed, not signed. The score never appears inside the credential JWT. It's computed at verification time by anyone with the framework.
  3. The framework is public. Versioned and linkable, so verifiers can audit our methodology — this page IS that framework.

Scope.

What this framework scores: a single credential, in isolation. Inputs: the parsed credentialSubject block plus the JWT envelope (issuer, status). Output: a structured score breakdown.

What this framework does NOT score:

  • The truthfulness of the data owner's assertion. We cannot independently verify that they own the asset or that the rights they assert are legally available to them.
  • The legality of downstream use under specific facts. Whether THIS lab using THIS credential for THIS model on THIS dataset complies with THEIR jurisdiction's law is fact-specific — we provide signal, not legal opinion.
  • Comparative ranking against other credentials. The score is absolute (0–8) per category, not relative.
  • Forward-looking risk. The framework reflects legislation as of its publication date.
  • Whether the rights granted match the underlying licence. The data owner's signed claim controls; consistency checks are explicitly deferred to v1.1.

The eight categories.

Contents

  1. Use rights coverage
  2. Per-right scope specificity
  3. Personal data declaration
  4. Lawful basis
  5. Data subject rights mechanism
  6. Provenance integrity
  7. Temporal + jurisdictional scope
  8. Attribution + downstream obligations
Category 1

Use rights coverage

What it checks
All seven canonical use rights — train, rag, embed, display, eval, derive, commercial — are explicitly declared (granted: true or granted: false, never absent).
Why it matters
Implicit grants create ambiguity. A credential that doesn't address commercial use leaves the lab to infer. Forcing explicit declaration eliminates the inference gap.
Pass criterion
All seven rights present with explicit granted boolean. Pass = 1, fail = 0.
Legal anchors
  • US: 17 USC §106 — copyright owner's exclusive rights
  • EU: Directive 2001/29/EC Art. 2–5 (Information Society Directive)
  • International: Berne Convention Art. 9 (reproduction), Art. 12 (adaptation)
  • AI-specific: EU AI Act Art. 10.3 — training data documentation requirements
Category 2

Per-right scope specificity

What it checks
Granted rights have meaningful scope fields populated — not just granted: true with default-empty scope.
Why it matters
"Granted" without scope is over-broad. EU AI Act Art. 10 requires data governance to address purpose limitation; vague rights fail this test.
Pass criterion
≥75% of granted rights with applicable scope vocabulary have it populated. train needs model_family + one_time; rag needs max_excerpt_tokens; embed needs max_dim; display needs max_excerpt_tokens; derive needs derivative_categories. eval and commercial have no scope vocabulary and are excluded from the denominator.
Legal anchors
  • EU AI Act Art. 10.3 (intended-purpose documentation)
  • GDPR Art. 5(1)(b) — purpose limitation
  • GDPR Art. 6(1)(b) — contract basis specifying processing
Category 3

Personal data declaration

What it checks
The credential declares whether the underlying asset contains personal data (pii_present field set to true or false; absence fails).
Why it matters
"Unknown PII status" cannot be assessed for GDPR / CCPA / similar compliance. A credential silent on PII forces labs to assume the worst. This category is also a prerequisite for Categories 4 and 5 — without it, those categories auto-fail because they can't be assessed.
Pass criterion
credentialSubject.pii_present present with explicit boolean value.
Legal anchors
  • GDPR Art. 4(1), Art. 5(1)(a)
  • CCPA Cal. Civ. Code §1798.140(v)
  • CPRA §1798.140(ae) — sensitive personal information
  • UK GDPR §3 · LGPD Art. 5(I) · APPI §2
Category 4 · Conditional

Lawful basis

What it checks
If pii_present=true, an explicit lawful_basis field naming a recognised GDPR Art. 6 category.
Why it matters
GDPR requires every processing operation on personal data to have a documented lawful basis. A credential authorising AI training on personal data without naming a basis is asserting unlawful processing.
Pass criterion
  • pii_present=false → auto-pass (no PII; lawful basis not applicable).
  • pii_present=true → lawful_basis required, value in {consent, contract, legal_obligation, vital_interests, public_task, legitimate_interests}.
  • If special_categories (race, health, biometric, etc.) is non-empty, lawful_basis_special also required, value from GDPR Art. 9(2)(a–j).
  • pii_present absent (Cat 3 failed) → fail.
Legal anchors
  • GDPR Art. 6 — six lawful bases
  • GDPR Art. 9 — special categories
  • GDPR Art. 8 — children under 16; UK threshold 13
  • CCPA §1798.120 — opt-out framework (distinct from EU lawful-basis model)
Category 5 · Conditional

Data subject rights mechanism

What it checks
If pii_present=true, the credential names mechanisms by which data subjects can exercise their rights (erasure, retention, access).
Why it matters
A credential asserting training rights over personal data must connect to a workflow by which data subjects can revoke. Otherwise the credential authorises perpetual processing — directly conflicting with GDPR Art. 17.
Pass criterion
  • pii_present=false → auto-pass.
  • pii_present=true → data_subject_erasure_url + retention_period_days (non-null) required.
  • High-stakes (commercial=granted + pii_present=true) → data_subject_access_url also required.
Legal anchors
  • GDPR Art. 15 (access), 16 (rectification), 17 (erasure), 18 (restriction), 20 (portability), 21 (object)
  • CCPA §1798.105 (delete), §1798.110 (know specific pieces)
  • LGPD Art. 18 (Brazilian data subject rights)
Category 6

Provenance integrity

What it checks
The credential's identity chain is complete and verifiable. Asset SHA-256 present and well-formed; issuer DID resolvable; rights-assertion provenance explicit where applicable.
Why it matters
A credential is only as trustworthy as its provenance. Without integrity, downstream labs can't audit where the rights claim originated.
Pass criterion
credentialSubject.asset.sha256 is exactly 64 lowercase hex characters (already enforced by the schema validator). Direct customer issuance and OSS-bot issuance auto-pass on partner-side provenance metadata. Partner-issued credentials (per SDK embedded-issuance flow) require asserted_by + asserted_at + ownership_proof when present.
Legal anchors
  • EU AI Act Art. 10.3 — training-data documentation
  • EU AI Act Art. 13 — transparency obligations
  • EU AI Act Art. 50 — provenance disclosure for AI-generated content
  • US FTC Section 5 — deceptive practices (false provenance)
Category 7

Temporal + jurisdictional scope

What it checks
The credential bounds its grant in time and space.
Why it matters
Perpetual, unbounded grants over personal data violate storage-limitation principles. Cross-border transfers require explicit jurisdiction handling.
Pass criterion
  • scope.duration.starts required (ISO-8601 timestamp with UTC offset).
  • scope.duration.ends is optional in canonical v1.1 — perpetual grants pass only when pii_present=false; perpetual + PII fails.
  • scope.jurisdiction required (list of ISO 3166-1 alpha-2 country codes, or ["*"] for unrestricted). Empty list fails.
Legal anchors
  • GDPR Art. 5(1)(e) — storage limitation
  • GDPR Art. 44–50 — cross-border transfers
  • UK DPA 2018 Sched. 21 — Transfer Impact Assessments
  • CCPA §1798.99.80–99.88 · CPRA §1798.100(a)(3)
Category 8

Attribution + downstream obligations

What it checks
Attribution requirements and derivative-use rules are explicit.
Why it matters
Most permissive open-source licences require attribution. Copyleft licences propagate obligations to derivative works. A credential silent on these fails to communicate downstream restrictions.
Pass criterion
  • scope.attribution.required present with explicit boolean.
  • If rights.derive.granted=true, derive.scope.share_alike required (boolean; copyleft / CC-BY-SA semantics).
Legal anchors
  • Berne Convention Art. 6bis — moral rights (180+ countries)
  • US: VARA / 17 USC §106A — limited moral rights
  • EU: Directive 2001/29/EC Art. 5 — exceptions and limitations
  • Creative Commons licence compatibility rules
  • GPL family — derivative-work share-alike

Jurisdiction-weighted views.

The base score is uniform — eight categories, each pass/fail, totals 0–8. Verifying labs view the same credential through their jurisdiction-specific lens. The relative weights below reflect each jurisdiction's emphasis; the underlying category evaluators are identical.

EU view (GDPR + AI Act) — max 10.0

Foundational PII categories elevated; storage-limitation matters more.

CategoryWeight
1. Use rights coverage1.0×
2. Per-right scope specificity1.0×
3. PII declaration1.5×
4. Lawful basis1.5×
5. Data subject rights1.5×
6. Provenance integrity1.0×
7. Temporal + jurisdictional1.5×
8. Attribution + downstream1.0×

California view (CCPA + CPRA) — max 8.5

Broader PII definition; opt-out framework rather than lawful-basis-categorical.

CategoryWeight
1, 2, 6, 81.0×
3. PII declaration1.5×
4. Lawful basis1.0×
5. Data subject rights1.5×
7. Temporal + jurisdictional0.5×

US federal view — max 9.0

No comprehensive federal privacy law; copyright + contract dominate; sector-specific layers (HIPAA, COPPA, FERPA) live in dedicated views.

CategoryWeight
1, 2 (rights + scope)1.5×
3. PII declaration1.0×
4. Lawful basis0.5×
5. Data subject rights0.5×
6. Provenance integrity1.5×
7. Temporal + jurisdictional1.0×
8. Attribution + downstream1.5×

Children's data view (COPPA + GDPR-K) — max 11.0

Triggered when special_categories contains child or domain is child-directed. All PII categories doubled.

CategoryWeight
1, 2, 6, 7, 81.0×
3. PII declaration2.0×
4. Lawful basis2.0×
5. Data subject rights2.0×
Auto-fail rule. In the children's-data view, failing any PII category (3, 4, or 5) forces the overall score to 0/8, regardless of other passes. COPPA / GDPR Art. 8 are not graded on a curve.

Health data view (HIPAA + GDPR Art. 9) — max 11.5

Triggered when special_categories contains health or domain is healthcare.

CategoryWeight
1, 2, 7, 81.0×
3. PII declaration2.0×
4. Lawful basis2.0×
5. Data subject rights2.0×
6. Provenance integrity1.5×

Using the score from the API.

The score is computed live from the stored credential on every request. Public endpoint — no authentication required:

GET /v1/credentials/{credential_id}/compliance-score
GET /v1/credentials/{credential_id}/compliance-score?jurisdiction=eu
GET /v1/credentials/{credential_id}/compliance-score?jurisdiction=children
GET /v1/credentials/{credential_id}/compliance-score?framework_version=v1.0

Sample response:

{
  "credential_id": "8c23470a-576a-4c6f-9340-490c5281ebba",
  "framework_version": "v1.0",
  "framework_url": "https://licensefoundry.com/framework/v1.0",
  "jurisdiction": "eu",
  "score": "5/8",
  "passes": 5,
  "total": 8,
  "score_weighted": 6.5,
  "score_max": 10.0,
  "score_pct": 65,
  "auto_fail_reason": null,
  "categories": [
    {
      "id": "use_rights_coverage",
      "label": "Use rights coverage",
      "passed": true,
      "weight": 1.0,
      "reason": null,
      "legal_anchors": ["17 USC §106", "EU AI Act Art. 10.3", ...]
    },
    ...
  ]
}

Median latency target: <50ms. The score is supplementary information for verifying labs; the credential's cryptographic validity is checked separately via the signature + status-list.

Versioning.

The framework IS versioned — this page is v1.0. Future revisions land as v1.1 (minor — looser pass criteria, new jurisdictions, new legal anchors), v2.0 (major — new categories, stricter criteria, category removals).

Support windows:

  • Current major (vN.x): indefinite — labs pinning to it always work.
  • Previous major (vN-1.x): 12 months after vN.0 ships; deprecation warning on responses; removed in vN+1.0.
  • Two-back (vN-2.x): archived; documented but no longer served by the live endpoint. Labs can compute locally from the published framework.

The endpoint reports its framework_version in every response. Pin with ?framework_version=v1.0 to guarantee a specific version even after we ship a successor.

What this framework is NOT.

  • Not legal advice. The score is our opinion against published criteria. Verifying labs should make legal decisions with their own counsel.
  • Not a guarantee. A high score doesn't guarantee compliant use; a low score doesn't necessarily mean non-compliant use. The score is signal among many inputs.
  • Not a certification. Certifications imply third-party audit. We compute scores from credential contents; the data owner remains responsible for the underlying claims.
  • Not a substitute for the credential. Verifiers verify the credential cryptographically (signature, status). The score is supplementary information.
  • Not fixed. The framework will evolve as legislation evolves. Verifiers pin to specific versions; we publish revisions transparently.
  • Not exhaustive. Some compliance dimensions are too fact-specific to assess from a credential alone. The framework scores what's structurally assessable from the credential; remaining work is the verifier's.

Engineering source — including open questions, governance plans, and the spec sections that didn't make this public page — lives at docs/compliance-scoring-framework.md on GitHub.