CGAI™ Assessment Specification

Status: proposed-normative. Every parameter and mechanism in this document is proposed pending council ratification; ratification precedes authority. Amendments accrue as dated changes through pull request; ratified versions are tagged. This specification governs the credential, not the course content: the course is open (CC BY-SA 4.0) and free to study. The credential is what we govern.

Substrate: Credential envelopes, receipts, registry, revocation, and validation are those of exo-avc in exochain/exochain at

PINNED_EXOCHAIN_SHA = 86e9a029b7a62417b658b04d0def7a979e21fc8b

The cgai/*.v1 shapes in this document are payload profiles: canonical JSON whose content hash is bound into an AutonomousVolitionCredential and/or AvcTrustReceipt. They have no independent (non-AVC) normative force. Field-level homes are recorded in docs/spec-reconciliation/AVC-MAPPING.md.

Change history

0. Envelopes and identity

Issuance. A CGAI credential is an AutonomousVolitionCredential issued by the Institute (issuer_did / principal_did) to the candidate (subject_did; optional holder_did). Until an upstream human subject kind exists, subject_kind is Unknown and the payload profile declares the subject as a CGAI candidate. Candidate keys are EXO DIDs (transitional note: legacy “0dentity” public keys are represented as DIDs).

Ceremony patterns. Issuance and sealed-form commit reuse the LiveSafe-style patterns at the pin: bind an evidence/content hash before issue_avc; multi-step package (credential → authorization or registration material → verifiable receipt); public surfaces carry hashes and IDs, not private evidence; timestamps are caller-supplied; intents are narrow and fixed (e.g. cgai.sealed_form.commit, cgai.grading.record, cgai.credential.issue).

Verification. Anyone with the substrate registry, credential, and required public keys verifies via validate_avc (AvcValidationRequest → AvcDecision). A git mirror alone cannot prove Allow/Deny, signature validity, or non-revocation.

1. Disclosure attestation

Every submission is accompanied by a signed attestation binding the candidate, the exact course version studied, and an AI-assistance disclosure. The attestation is the credential’s honesty anchor: the fraud posture is detect-and-remediate, and a false attestation is independent grounds for revocation regardless of the work’s quality.

AI assistance is permitted. It is the subject matter of the course; prohibiting it would certify a pretense. What is not permitted is undisclosed assistance.

Carrier. Profile cgai/attestation.v1 is candidate-signed. Its content hash is bound into an AvcTrustReceipt (typically AvcTrustReceiptEvidence.action_commitment_hash) and may also be referenced from the issued credential’s policy_refs / delegated_intent. The candidate signature over the profile is distinct from the AVC issuer signature.

AI assistance vs LYNK. The honesty disclosure enum below is not carried as an llm_usage_receipt chain and has no field-level isomorphism to LlmUsageEvidence. When tools emit LYNK evidence, zero or more LlmUsageEvidence records may accompany the process via llm_usage_evidence_hash on a trust receipt; their presence neither proves nor replaces disclosure. LYNK evidence is optional even when ai_assistance.level is not none.

{
  "$id": "cgai/attestation.v1",
  "candidate_did": "Did (EXO)",
  "course_version": { "tag": "string", "commit": "sha-256" },
  "submission_sha256": "hex",
  "ai_assistance": {
    "level": "none | drafting | research | review | substantial",
    "disclosure": "free text: tools, models, and how they were used"
  },
  "statements": [
    "The submitted work reflects my own reasoning.",
    "All AI assistance is disclosed above.",
    "I understand false attestation is grounds for revocation."
  ],
  "signature": "candidate signature over all fields",
  "signed_at": "ISO 8601"
}

2. Sealed-bank hash commitments

The 200-question bank in this repository is open by design and therefore functions as published practice material. Scored objective forms are generated off-repository from a superset bank and are sealed: each form’s SHA-256 is committed before the form is administered, so the commit timestamp proves the form predates every sitting without revealing its content.

Carrier. Profile cgai/sealed-form.v1 supplies the content commitment. Form content hashing remains SHA-256 (opaque 32-byte digest). AVC envelope hashing at the pin is BLAKE3 over CBOR; that is the substrate’s structure hash, not a redefinition of form hashing. Bind sha256 into a pre-administration AvcTrustReceipt with action_commitment_hash derived from the canonical profile bytes. Production forms require timestamp_provenance = ExternalTimestampAuthority and an external_timestamp_proof so commit-before-administration does not rest only on a validator clock. Fixtures may use disclosed validator-clock provenance.

{
  "$id": "cgai/sealed-form.v1",
  "form_id": "string",
  "sha256": "hex, of the canonical form document",
  "generated_from": { "bank_version": "off-repo bank content hash" },
  "item_count": "integer",
  "committed_at": "ISO 8601 (must precede first administration)",
  "window": { "opens": "ISO 8601", "closes": "ISO 8601" },
  "disposition": "sealed | revealed | retired"
}

Rules: a form is administered only while sealed; after its window closes it is either revealed (content published, hash verifiable by anyone) or retired (hash remains as the record). A form whose content leaks before its window closes is retired and every sitting against it is voided and re-offered at no cost to candidates. Leakage may additionally produce substrate revocation of related credentials under the process in section 4.

3. Grading manifest

Essays are graded by council members against five rubric dimensions, each scored 0–4:

Proposed pass line: 14/20 with no dimension at 0. Each grading produces a manifest; the manifest’s content hash is bound into an AvcTrustReceipt (create_trust_receipt / create_trust_receipt_with_evidence). Pass/fail lives in the profile; the receipt’s AVC decision is Allow/Deny for the recorded action, not the academic outcome.

{
  "$id": "cgai/grading.v1",
  "submission_sha256": "hex",
  "attestation_ref": "hash of attestation profile",
  "prompt": { "path": "repo path", "commit": "sha-256" },
  "rubric_version": "this file's ratified tag",
  "graders": ["council member DIDs"],
  "scores": { "D1": 0, "D2": 0, "D3": 0, "D4": 0, "D5": 0 },
  "decision": "pass | fail",
  "receipt_id": "AvcTrustReceipt.receipt_id",
  "graded_at": "ISO 8601"
}

Consistency controls, per cohort: anchor essays are graded by all active graders and drift beyond one point on any dimension triggers recalibration before the cohort is scored; each quarter, a random sample of not less than five percent of that quarter’s gradings (minimum three) is independently re-graded, and divergent outcomes follow the correction path in section 4. Recalibration and re-grade outcomes are themselves receipted.

4. Revocation and appeal

Grounds: false attestation; plagiarism; sealed-form leakage or misuse; grading error established by re-grade. Process:

1. A revocation decision is receipted and the holder is notified. A 14-day timelock runs between decision and effect.
2. The holder may appeal within 30 days of notice. A timely appeal stays the timelock until decided.
3. Appeals are decided by council members with no part in the original grading or the revocation decision.
4. Outcomes: uphold, reinstate, or re-examine (fresh sealed form or fresh prompt, no fee).
5. Every decision at every step is receipted as an AvcTrustReceipt. Invalidation of a credential is an AvcRevocation in the substrate registry (revoke_avc). The timelock, appeal window, stay, and notification are process profile rules (not fields on AvcRevocation); intermediate states (decision, appeal opened, appeal decided, effect) are receipted. Emergency stops may use AvcRevocationReason::EmergencyStop. Routine grounds map primarily to PolicyViolation (false attestation, plagiarism, leakage/misuse). Grading error uses reinstate / re-examine unless a credential was issued in error.

Credentials are version-bound: a certificate names the course version and rubric version it was earned against (via profile fields and credential policy_refs / intent). Versions are superseded, not invalidated: issue a new version-bound credential; do not call revoke_avc with Superseded for routine version bumps. Revocation is the only mechanism that invalidates, and it exists only through this process.

5. Registry and transparency mirror

Origin of truth. The exo-avc registry (AvcRegistryRead / AvcRegistryWrite and durable credential, revocation, and receipt state at the pin) is the origin for issuance, receipts, revocation, and validation.

Git transparency mirror. This repository may publish a mirror listing, at most: credential IDs and issuance timestamps; sealed-form commitment hashes, windows, and disposition; revocation records (credential_id, reason, created_at); attestation and grading receipt IDs. Entries are corrected by later entries, never rewritten — the same convention this repository applies to its briefs and claims.

Evidentiary limits. The mirror can prove that a hash or ID was published in git history at a commit time. The mirror alone cannot prove AVC signature validity, authority-chain rootedness, non-revocation against a live set, or a validate_avc Allow/Deny decision. Those require the substrate registry and keys.