// SPDX-License-Identifier: CC-BY-SA-4.0
// Copyright (c) 2026 Jonathan D.A. Jewell (hyperpolymath) <j.d.a.jewell@open.ac.uk>

= CRG-PROFILE — {LANGUAGE_NAME}
:toc: left
:toclevels: 2

[cols="1,3"]
|===
| Field | Value

| Language | {LANGUAGE_NAME}
| Repository | {REPO_URL}
| Current CRG Grade | {GRADE}  (X \| F \| E \| D \| C \| B \| A)
| Assessed | {YYYY-MM-DD}
| Assessor | {NAME <email>}
| CRG Spec Version | 2.2
| ARG Profile | spec/ARG-PROFILE.adoc
| TRG Profile | spec/TRG-PROFILE.adoc
| FRG Profile | spec/FRG-PROFILE.adoc
|===

== About this profile

This profile applies the *CRG v2.2 (STRICT)* baseline to
{LANGUAGE_NAME} and records the current honest grade per released
component, the evidence supporting it, and the path to the next grade.

CRG grades *released components*: artefacts the project publishes for
external consumers (libraries, binaries, services, plugins). Toolchain
internals are graded separately under TRG; the user-facing language
adoption surface is graded under ARG; the foundational research
surface is graded under FRG.

CRG = {GRADE} (worst-of any released component). The full chain of
axes for this language:

* ARG: {ARG_GRADE}
* TRG: {TRG_GRADE}
* FRG: {FRG_GRADE}
* CRG: {GRADE}
* RSR: {RSR_LEVEL}

== Released components

A *released component* is any unit of work this repository publishes
under its own name + version: crate, library, binary, plugin, schema,
or vendored artefact. Each is graded independently against CRG.

The list below is the complete published surface as of {YYYY-MM-DD}.

[cols="2,1,3,4", options="header"]
|===
| Component | Grade | Release stage | Evidence

| {component-1-name}     | {grade} | {pre-alpha / alpha / alpha-stable / beta / stable / N/A} | {Path or registry URL; test coverage; CI status}
| {component-2-name}     | {grade} | {stage} | {Evidence}
| {component-3-name}     | {grade} | {stage} | {Evidence}
| {...}                  | {grade} | {stage} | {Evidence}
|===

If the project has no externally-released components, the
language-level CRG is *X* by definition and this table will be empty
with a single explanatory row.

== Per-component evidence (deep)

For each component above whose grade is *D or higher* (CRG §4.4+
requires the deep per-file + per-directory annotation at grade C
onward), include a per-file / per-directory annotation table here or
link to one. The canonical example is
`gossamer/docs/governance/CRG-AUDIT-2026-04-18.adoc`.

* {component-1-name}: {link to its audit file}
* {component-2-name}: {link to its audit file}

== Grade rationale

[cols="2,1,4", options="header"]
|===
| Grade clause (CRG §4) | Met? | Evidence

| *E1 — At least one test exists*
| {YES/NO}
| {Path; brief description}

| *E2 — Failures documented*
| {YES/NO}
| {Path to failure ledger}

| *D1 — Test matrix documented*
| {YES/NO}
| {Path}

| *D2 — Scope documented*
| {YES/NO}
| {Path}

| *D3 — RSR compliance*
| {YES/NO}
| {RSR level + audit ref}

| *C1 — Dogfooded*
| {YES/NO}
| {Internal-use list}

| *C2 — CI green*
| {YES/NO}
| {Workflow run URL; cadence}

| *C3 — Deep annotation (per-file + per-dir)*
| {YES/NO}
| {Annotation doc path}

| *B1 — ≥6 diverse external targets*
| {YES/NO/N/A}
| {External-targets list with diversity argument}

| *B2 — Issues fed back from external use*
| {YES/NO/N/A}
| {Closed-issue trail; external-reporter labels}

| *A1 — Confirmed real-world value, no harm*
| {YES/NO/N/A}
| {External-feedback corpus}

| *VeriSimDB attestation (grade C+)*
| {YES/NO}
| {Attestation ID; last-ingested timestamp}
|===

== Language-specific tightening (this profile only)

For {LANGUAGE_NAME}, the following additional obligations apply at the
stated grades:

* *Grade C tightening:* {Language-specific obligation, e.g.
  "AffineScript stdlib: every released module MUST have a borrow-check
  fixture suite."}
* *Grade B tightening:* {e.g. "Ephapax verifier crate: every released
  layer MUST have a published soundness theorem."}
* *Grade A tightening:* {Aspirational, e.g. "Registered VeriSimDB
  instance, public health check."}

These tightenings are *additional* to the baseline — none of the
baseline evidence is waived.

== What is NOT yet met (honest gaps)

* {Bullet list of specific CRG evidence the released components do not
  currently produce, grouped by component}
* {Each gap should be specific enough that a reader can verify by
  inspection of the repo}

== Path to next grade ({NEXT_GRADE})

* {Specific next-step item 1, naming the gated component(s), with
  estimated work}
* {Specific next-step item 2}
* {...}

*Realistic timeline estimate:* {N weeks/months}

== Path to grade beyond that ({GRADE_AFTER_NEXT})

* {Larger items that follow the immediate next grade}

== Demotion risk

* *Lowest:* {What would have to break for the grade to drop by one,
  e.g. "single released component CI flips to red"}
* *Medium:* {What would have to break for a multi-step demotion}
* *Catastrophic:* {What would force demotion to F, e.g. "released
  component found to be harmful in production"}

== Iteration history

[cols="1,1,4", options="header"]
|===
| Date | Grade | Notes

| {YYYY-MM-DD} | {grade} | Initial assessment.
| {YYYY-MM-DD} | {grade} | {Reason for change.}
|===

== Review cycle

* *Routine:* Reassess on every release cycle (per CRG §6.3).
* *Immediate:* Reassess within 7 days of any released-component
  regression.
* *VeriSimDB drift alert:* Reassess within 24 hours of any drift alert
  from VeriSimDB on this language's released components.

== Footer

Run `just crg-badge` in this repo to generate the shields.io badge for
the README.

This profile is itself a VCL-total proposition. Its content is
`DECLARE`'d to VeriSimDB on each commit. Drift between the claimed
grade above and the underlying evidence surfaces as a grade-stale alert.
