Open · Public · Normative
The published specification for COHESION human-oversight certification. Defines DRS routing, JIS measurement, signed evidence artifacts, and customer-system writeback.
Version: 1.3.0 Status: Published specification Published: 2026-04-16 Last revised: 2026-06-30 Custodian: COHESION AUTH LLC (Washington, USA) Revision (v1.3.0, 2026-06-30): Evidence-surface refresh. Added public receipt verification language (§10.7), signed DDQ kit language (§10.7), Mandatory Reasoning Capture language (§10.7), customer system-of-record writeback (§11.7), CRICS and judgment-velocity trend language (§24.5), and corresponding glossary and abbreviation entries. Updated public Enterprise pricing to custom/contact language. The frozen measurement core is unchanged: DRS remains the per-decision routing and hold score; JIS remains the reviewer judgment-quality score across seven dimensions; no JIS weights, DRS weights, decay parameters, bands, thresholds, or IMP intervention types changed. Errata (v1.2.1, 2026-06-27): Factual refresh. Corrected regulatory citations (Colorado SB 26-189 effective-date treatment and superseded SB 24-205 status, EU AI Act Article 14 final enforcement dates), extended the NIST AI RMF mapping (MEASURE 2.8 and GOVERN 3.2), added a reviewer-identity traceability limitation note (§10.6) and the corresponding Tier L3 checklist item (§26.3), corrected the audit-log retention language, and added the L1 self-serve pricing tier. The frozen measurement core is byte-identical to v1.2: the seven JIS dimensions and weights, the classification bands, the decay model and parameters, the IMP intervention types, and the DRS subscores and weights are unchanged. The only added conformance obligation is the §10.6 reviewer-identity disclosure and its §26.3 checklist item, which document an existing product behavior and do not alter any measurement, score, or threshold. Licence: Permissive open-standard licence. Implementation is free. The COHESION Certified mark is trademarked and may only be applied by organisations that have passed a Tier L3 conformity audit.
This document is the authoritative technical reference for the COHESION Certification Standard. It defines the measurement methodology, scoring system, intervention protocols, and certification tiers used to evaluate human oversight of high-risk AI systems. Companion materials (case library, patent, preprint, API reference) are linked at the end.
AI is now deployed inside high-stakes decisions about people: who is hired, who receives credit, who is admitted, who is treated, who is investigated. The durable problem is not whether a human is nominally "in the loop." It is that no widely available runtime mechanism measures whether the human is exercising independent judgment or merely defaulting to the model's output. Regulators, deployers, and the public are asked to trust that a human reviewer thought, when the only available evidence is that a human was present. Effective human oversight is therefore asserted, not demonstrated.
A growing and converging body of law and standards now demands effective human oversight of AI in consequential decisions. These drivers do not share a common enforcement calendar or a single jurisdiction, but they share a common gap: each requires oversight to be effective, and none specifies how to measure whether it is. The drivers most relevant to this specification, US-first, are:
Colorado SB 26-189 (Automated Decision-Making Technology). Signed 2026-05-14, repealing and reenacting the prior Colorado AI Act. Section 5 states that, except for listed rulemaking, appropriation, and related procedural provisions effective upon passage, SB 26-189 takes effect 2027-01-01 and applies to consequential decisions made on or after 2027-01-01. It conditions a deployer's defence on "meaningful human review" by a trained reviewer with authority to approve, modify, or override a consequential decision and who, among other duties, does not default to the system output. See Annex H §27.1.
NIST AI Risk Management Framework 1.0 (Measure function, MS-2.5 adversarial and calibration testing, MS-3.2 operator-AI interaction telemetry).
US federal AI policy, including the federal AI Executive Order direction on safe and accountable AI and SEC guidance on AI use in regulated decision-making, both of which presume documented, effective human control.
The proposed US GUARDRAILS Act, which would impose documented effective human oversight obligations for high-risk AI in federal procurement contexts.
Other US state automated-decision and ADMT statutes following Colorado's lead in conditioning deployer obligations on genuine human review rather than nominal presence.
ISO/IEC 42001:2023 (AI management system, human oversight clause 8.3).
EU AI Act Article 14, which requires "effective human oversight" of high-risk AI by natural persons. Article 14(4) enumerates four specific capabilities the oversight person must possess:
The EU AI Act (Regulation (EU) 2024/1689) is fully adopted and phases in across multiple application dates. This specification addresses Article 14 human oversight and does not rely on a single EU enforcement date. Article 14 is one leg of the regulatory landscape, not its spine.
None of these frameworks specify a measurement methodology for human oversight. In practice, organisations demonstrate "effective oversight" through self-attestation, training records, or checkbox audits. None of these produce an auditable real-time artefact that would survive a post-incident regulatory review. COHESION exists to close that gap: it measures, at runtime and as invisible middleware, whether the human reviewing a high-stakes AI decision is exercising independent judgment, and it produces the auditable record that every one of the frameworks above presumes but none defines.
COHESION operates as invisible middleware between an AI system's output and the human-facing interface, following the architecture middleware to telemetry to scoring to invisible intervention. Two distinct scoring constructs operate on this stream, at two distinct levels:
DRS scores the decision; JIS scores the human. DRS routes; JIS measures. They are complementary and MUST NOT be conflated. Together they form the operational definition of effective oversight: DRS ensures a real human sees the decisions that matter, and JIS produces the auditable evidence that those humans actually thought.
This specification defines:
Out of scope: the alignment or safety properties of the AI system itself, model-level bias audits, and conventional governance tooling (which addresses model behaviour, not operator behaviour).
Implementations that claim conformance with this specification MUST satisfy every requirement marked MUST or REQUIRED. Requirements marked SHOULD are recommended. Requirements marked MAY are permissible variations. A third-party conformity assessment is required for Tier L3.
This specification has 19 normative sections (§§1-19) covering the two scoring constructs (DRS and JIS), the judgment decay model, the Invisible Maintenance Protocol, certification tiers, regulatory mapping, the data schema, the API contract, privacy obligations, and conformance. It is supplemented by 11 annexes labelled A through K: Annexes A through J at §§20-29, and Annex K (Decision Risk Score Methodology) at §34. Annex K sits after the glossary, bibliography, abbreviations, and closing (§§30-33) because it was added in a later revision; this is an editorial sequencing artifact and not a normative ordering. The reference sections (§30 Glossary, §31 Bibliography, §32 Abbreviations, §33 Closing) are supporting but not primary. The exact line count is non-normative and may change with editorial updates. When external materials cite "19 sections," they refer to the normative body; the 11 annexes are normative for the methodology they specify (DRS in Annex K is normative for the routing layer; the others provide normative mappings, schemas, and procedures referenced from the body).
This specification is written for four distinct audiences:
Language in this specification follows RFC 2119 (MUST / SHOULD / MAY) conventions. Terms of art are defined in §3 and the glossary in §30.
Retry-After headerOperator. A natural person in scope of Article 14 or an equivalent oversight obligation, interacting with an AI system in a regulated decision workflow.
AI-augmented interaction. A single unit of work in which an AI system generates a recommendation, classification, draft, or alternative, and an operator decides whether to accept, modify, reject, or act independently of that output.
Judgment Independence Score (JIS). A 0-100 composite score reflecting the degree to which an operator's behaviour across the observable interaction stream constitutes genuine judgment rather than deference to the AI. Higher values indicate stronger independent judgment.
Judgment decay. The measured decline in JIS over time, absent maintenance interventions, as operators interact continuously with AI-augmented workflows.
Invisible Maintenance Protocol (IMP). The set of embedded stimuli (calibration injections, recommendation withholding, unranked presentation) that maintain or restore JIS without the operator being able to distinguish a maintenance interaction from a normal workflow interaction in real time.
Certification tier. A level (L1, L2, L3) of COHESION implementation. Requirements escalate; all higher tiers include the lower tiers.
Domain. The regulated sector in which the AI system operates. Calibrated domains are: healthcare, aviation, financial services, legal, pharmaceutical, critical infrastructure, and general.
Calibration injection. A maintenance intervention in which the AI output presented to the operator contains a deliberately introduced error of known difficulty. The operator's response is measured. The injected error is filtered through a safety-net layer and never reaches downstream systems.
Safety-net layer. An independently-testable architectural layer that intercepts all maintenance-injected AI outputs before they can propagate to any real-world system, external API, or human not involved in the intervention.
Automation bias. The tendency of operators to over-rely on AI-generated recommendations, accepting outputs they would have rejected or questioned in the absence of AI assistance. Named in Article 14(4)(b).
Rubber-stamping. The colloquial term for operator behaviour that accepts AI recommendations without independent evaluation. The inverse of effective oversight.
Trap scenario. Synonym for calibration injection.
Independent scenario. A maintenance event in which the AI recommendation is withheld entirely and the operator makes the decision without AI assistance. Used to measure J3 (Independent Performance).
Split scenario. A maintenance event in which ranked AI output is presented unranked, stripped of highlighting, confidence annotation, or recommended-option flagging.
The JIS is computed as a weighted sum across seven dimensions. Every dimension maps to at least one Article 14 subsection. Weights are normative and frozen per specification version; an implementation that varies these weights MUST declare itself non-conformant or fork the specification under a different name.
| # | Dimension | Weight | Article 14 mapping | What it measures |
|---|---|---|---|---|
| J1 | Deferral Resistance | 0.20 | 14(4)(d) | Maintaining independent position when the AI recommendation conflicts with domain knowledge. Strongest single indicator of rubber-stamping behaviour. |
| J2 | Error Detection Capability | 0.20 | 14(4)(a), 14(4)(c) | Catching incorrect, misleading, or contextually inappropriate AI output. Measured via calibration injections across difficulty levels per §7. |
| J3 | Independent Performance | 0.15 | 14(4)(a), 14(4)(d) | Decision quality when the AI system is unavailable or is deliberately withheld for a subset of interactions. |
| J4 | Deliberation Depth | 0.15 | 14(4)(b) | Cognitive effort per interaction. Composite of time-to-decision, information-seeking behaviour, modification depth, and review patterns. |
| J5 | Post-Error Recalibration | 0.10 | 14(4)(b) | Appropriate trust adjustment after a detected AI error. Penalises both missed adjustment and overcorrection. |
| J6 | Domain Confidence | 0.10 | 14(4)(a) | Demonstrated expertise and confidence calibration, independent of AI assistance. Measured from independent-performance and override-quality signals. |
| J7 | Decision Autonomy | 0.10 | 14(4)(d) | Frequency and quality of overrides, supplementation, and contextual reasoning beyond what the AI presents. |
Weights sum to 1.00.
Each dimension is computed from a specific combination of observable interaction signals. Implementations MUST NOT substitute signals not listed here without declaring a deviation from the normative specification.
J1 Deferral Resistance: count of interactions where operator's final decision differed from the initial AI recommendation (override count); rate of override on interactions where ground truth later proved the operator correct; deviation from population mean override rate for the operator's role and domain; time from AI recommendation presentation to override commit.
J2 Error Detection Capability: accuracy on calibration injections of known difficulty (easy/moderate/subtle/adversarial); false-positive rate (operator rejects correct AI output); response consistency across difficulty strata; recovery after missed injection (did a subsequent injection of similar difficulty get detected).
J3 Independent Performance: decision accuracy on withholding events (AI recommendation hidden); time-to-decision on withholding events compared to AI-assisted events; confidence expressed on withholding events; accuracy on ground-truth-validated withholding outcomes.
J4 Deliberation Depth: log(time-to-decision) normalised against operator and role baseline; hover events on AI-adjacent evidence; scroll depth on available evidence; alternative-option checks; note-taking or annotation activity (where captured); keystroke or cursor activity during review.
J5 Post-Error Recalibration: magnitude and duration of override-rate change following a detected AI error in a recent interaction; appropriateness of change (under-correction flags if override rate does not rise; over-correction flags if it rises inappropriately and persists); recovery time to baseline after the local event.
J6 Domain Confidence: independent-performance accuracy (overlaps J3 signals but weighted for calibration); confidence vs accuracy calibration slope; tenure and role-level adjustment; cross-validation against role-specific benchmark.
J7 Decision Autonomy: supplementation events (operator adds context, evidence, or reasoning not present in AI output); override frequency weighted by override quality (penalises unsupported overrides); modification depth distribution on accepted-with-edit decisions; citation of non-AI sources in annotations.
A dimension score MUST NOT be reported with fewer than the following observation counts:
Before these thresholds are met for a given dimension, the composite JIS MUST mark the dimension as "insufficient data" and exclude it from the weighted sum, with the remaining weights renormalised. The classification band derived from such a partial JIS MUST carry a "provisional" flag visible to the compliance officer.
An operator's JIS MUST NOT be reported as valid with fewer than 50 scored interactions OR 10 days of monitoring, whichever occurs first. Before this threshold, the system MAY display a provisional score marked as such but MUST NOT use the score for any compliance, employment, or operational decision.
The JIS is recomputed after every AI-augmented interaction. The displayed JIS is an exponentially weighted moving average (EWMA) with a default 30-day half-life. Implementations MAY expose shorter-window scores for operational monitoring; the 30-day EWMA is the normative value for certification and compliance reporting. See §24 for the EWMA derivation.
| Range | Label | Meaning |
|---|---|---|
| 90-100 | Exemplary | Strong independent judgment, consistent error detection, minimal automation bias indicators. |
| 75-89 | Proficient | Effective oversight with self-correction. Meets Article 14 bar with margin. |
| 60-74 | Adequate | Minimum threshold for effective oversight. Maintenance recommended. |
| 40-59 | At Risk | Degraded oversight. Maintenance required. Supervisory review. |
| 20-39 | Impaired | Materially compromised oversight. Immediate remediation. Operational restrictions may apply. |
| 0-19 | Non-Functional | Cannot provide effective Article 14 oversight. Operator MUST be reassigned or retrained before continuing in the role. |
An organisation MUST NOT claim Article 14 compliance in a high-risk AI deployment if, at any time across a 30-day window:
Transitions between classification bands generate normative events:
All transitions MUST be logged to the audit log with before/after JIS, timestamp, and triggering interaction identifier.
Continuous AI-augmented work without maintenance intervention degrades JIS over time. The decay follows:
JIS(t) = JIS_0 · (1 − α · ln(1 + β · t))With maintenance intervention active:
JIS(t) = JIS_0 · (1 − α · ln(1 + β · t)) + γ · M(t)Where:
JIS_0 is the operator's baseline score at t=0.t is elapsed days of continuous AI-augmented work.α is the decay rate coefficient (per domain).β is the decay acceleration coefficient (per domain).γ is the maintenance efficacy coefficient (0.4 ≤ γ ≤ 0.9 for IMP-compliant implementations).M(t) is the cumulative intervention function over time.Effective maintenance can reverse decay, not only slow it.
Parameters are calibrated against the 21-case cross-case library (published 2026-04-19) and the SSRN preprint (under review). They MUST be revised on each major specification version; the values below are frozen for v1.1 and v1.2 (no parameter changes between versions; normative for v1.2 implementers).
| Domain | α (rate) | β (accel) | Floor | 90-day unmitigated Δ |
|---|---|---|---|---|
| Healthcare | 0.12 | 0.08 | 35 | −18 % |
| Aviation | 0.10 | 0.07 | 40 | −15 % |
| Financial services | 0.15 | 0.10 | 30 | −22 % (fastest decay) |
| Legal | 0.11 | 0.06 | 38 | −16 % |
| Pharmaceutical | 0.09 | 0.05 | 42 | −13 % (slowest decay) |
| Critical infrastructure | 0.13 | 0.09 | 33 | −20 % |
| General | 0.11 | 0.07 | 36 | −17 % |
The "floor" is the asymptotic minimum JIS in the absence of maintenance; it reflects irreducible baseline judgment that does not decay further.
The parameters in §6.1 were derived from the following sources:
Each case in the library is documented with entry, intervention, and outcome data at cohesionauth.com/research/21-cases. Raw decay curves are available on request under research licence.
Decay parameters in §6.1 are population means for the named domain. Individual operators exhibit variance of approximately ±20 % around the population mean. Implementations SHOULD fit per-operator decay parameters after at least 90 days of observation and 200 scored interactions; until personalised fit is available, the population mean for the operator's domain applies.
Within a domain, sub-roles may require parameter adjustment. For example, within healthcare:
Role-level adjustments SHOULD be calibrated against the implementer's own operator population after 6 months of observation and MUST be documented for conformity assessment.
Operators MUST NOT be able to distinguish a maintenance interaction from a normal workflow interaction in real time. Post-hoc audit labels are permitted; visible in-the-moment flags, badges, or notifications are not.
| Intervention | Frequency (of all interactions) | Purpose |
|---|---|---|
| Calibration injection | 2-8 % | Subtle errors calibrated to the operator's current JIS are injected into AI output; operator response measured. MUST be safety-netted (§7.4): never propagates into any real-world action. |
| Recommendation withholding | 3-10 % | Information is presented without an AI recommendation; the operator's independent assessment is captured before the AI output (if any) is revealed. |
| Unranked presentation | 2-5 % of ranked-output interactions | Ordering, highlighting, or confidence annotation is stripped; the operator evaluates alternatives on equal footing. |
| Difficulty adaptation | Continuous | Type and difficulty of all interventions adjusts to the operator's current JIS and per-dimension scores per §7.3. |
| JIS | Calibration difficulty | Frequency | Focus |
|---|---|---|---|
| 90-100 | High (subtle only) | 2-3 % | Maintain all dimensions |
| 75-89 | Moderate to high | 3-5 % | Lowest-scoring dimensions first |
| 60-74 | Moderate | 5-7 % | Deferral resistance, error detection |
| 40-59 | Low to moderate | 6-8 % | All dimensions |
| < 40 | Low (clear errors) | 8 % (cap) | Rebuild error detection and independent performance |
Every maintenance intervention MUST be filtered through a safety-net layer BEFORE reaching any downstream system, external API, or human not involved in the intervention. A calibration injection into an AI recommendation MUST NOT, under any implementation fault, cause a real medical, financial, legal, operational, or other adverse outcome. The safety-net layer MUST be independently testable, versioned, and logged.
Specific safety-net requirements:
intervention_id header that is stripped before any downstream call.See Annex I (§28) for the normative safety-net testing methodology.
At onboarding, organisations MUST inform operators that a maintenance system is active and that some proportion of interactions include calibrated stimuli intended to preserve oversight quality. Operators are entitled to know:
This satisfies transparency obligations without compromising invisibility.
Total maintenance intervention frequency across all categories MUST NOT exceed 15 % of interactions in any rolling 24-hour window. Higher rates may degrade operator workflow performance and introduce spurious JIS volatility.
The IMP MUST suspend (fall back to monitoring-only, no injection) in the following conditions:
Suspension events MUST be logged with trigger, duration, and restoration timestamp.
In addition to the four intervention types in §7.2, the IMP MUST emit two cognition probes per interaction. These probes are passive metrics derived from interaction telemetry; they do not modify AI output or operator workflow.
7.8.1 Counterfactual delta probe. Computes the gap between the operator's actual decision and the decision the AI recommendation alone would predict. Returned as cognition_probes.counterfactual_delta in /v1/score responses. Range: 0.0 (perfect alignment with AI) to 1.0 (maximal independent divergence). Strongly weighted in the Deferral Resistance dimension (§4).
7.8.2 Pre-commitment detection probe. Detects whether the operator formed a position before viewing the AI recommendation. Inferred from the interaction sequence (information-seeking depth, time-to-first-modification, alternative-views-checked count, scroll-depth before recommendation reveal). Returned as cognition_probes.pre_commitment in /v1/score responses. Boolean, with a confidence score in cognition_probes.pre_commitment_confidence. Strongly weighted in the Deliberation Depth dimension (§4).
Both probes are required fields in v1.1+ scoring responses. Implementations MUST emit both. The full computation method is normative and described in patent application 64/051,131 (Customer 230082). The probes do not constitute new operator-facing intervention; they are derived metrics over existing telemetry.
| Tier | Name | Requirements | Implementation time |
|---|---|---|---|
| L1 | Monitoring | Continuous telemetry · JIS computation · 30-day decay projections · alert triggers for JIS < 60 · 24-month interaction retention · GDPR-compliant personal-data processing · quarterly operator report | 4-8 weeks |
| L2 | Maintenance | All L1 + full IMP implementation · calibration library with minimum 200 scenarios per domain · safety-net layer with independent audit · difficulty-adaptation engine · efficacy tracking · incident-correlation reporting · documented remediation procedures | 8-16 weeks |
| L3 | COHESION Certified | All L2 + third-party conformity audit · tamper-evident data integrity (append-only hash chain) · outcome-validation studies · annual recertification · documented continuous-improvement process · public attestation | 16-24 weeks |
Only Tier L3 organisations MAY display the COHESION Certified mark.
Tier L3 requires annual recertification. Tier L2 self-attests annually. Tier L1 self-attests quarterly.
An organisation that fails a re-certification MUST either remediate within 90 days or downgrade to the next-lower tier. Continued display of a tier the organisation no longer holds is a violation of this specification and grounds for immediate revocation of the mark.
Audit criteria are normative and enumerated in Annex G (§26). A high-level summary:
An organisation adopting COHESION typically progresses L1 → L2 → L3 over 12-18 months. Skipping tiers is permitted but discouraged: the L2 safety-net layer is a prerequisite for credible L3 claims, and teams that have not operated L2 for at least 90 days often underestimate the calibration-library maintenance workload.
Two assurance levels parameterise WHO verifies the data feed underlying the JIS, independent of the L1/L2/L3 implementation tiers in §8.1 to §8.4.
8.5.1 Self-Reported assurance. The certified organisation connects a delivery surface (webhook, audit-log connector, or SDK) and signs a written data-accuracy declaration on behalf of the organisation. COHESION computes the JIS from the supplied data. The Self-Reported COHESION seal is issued. The score is methodologically equivalent to the Audited score; verification rigor differs.
8.5.2 Audited assurance. All Self-Reported requirements PLUS a third-party body (Big-4 audit firm, accreditation body such as ANAB, or a notified body in jurisdictions that recognise notified-body schemes) co-signs the data feed and the assurance statement. Requires tamper-evident audit trail (§13.2) and on-site walkthrough. The Audited COHESION seal is issued and is suitable for regulator-binding attestation in jurisdictions that recognise third-party verification.
8.5.3 Eligibility and progression. Any organisation with operators interacting with AI in regulated workflows MAY apply for Self-Reported. Audited eligibility requires twelve months of Self-Reported operation OR a regulator demanding third-party verification. Self-Reported organisations have priority access when the Audited tier opens for new partnerships.
8.5.4 Pricing. The Developer tier is free (raw JSON API, no signed artifacts). L1 self-serve is US$299/month or US$2,990/year, with a monthly decision allotment of 10,000. Starter is US$499/month or US$4,990/year (Self-Reported assurance, signed artifacts). Audited is US$1,999/month or US$19,900/year (Audited assurance, Big-4-compatible artifact bundle). Enterprise pricing, allotments, and volume terms are custom by contract; contact COHESION for a quote. Each non-Enterprise tier includes a monthly decision allotment: Developer 5,000, L1 self-serve 10,000, Starter 100,000, and Audited 500,000. Allotments are commercial tier terms with metered enforcement, not request throttles. Starter, Audited, and Enterprise are never cut off at the allotment; usage beyond the allotment bills at US$0.0008 per decision unless a custom Enterprise agreement states otherwise. The free Developer tier and the L1 self-serve tier stop at their allotment (hard stop, no overage); for L1 the cap is the upgrade trigger to Starter. Audit-ready artifacts are available exclusively on paid tiers and are cryptographically signed to the account that generated them. See cohesionauth.com/pricing/ for the current locked ladder (§13.5 explains the free-tier boundary).
| Article 14 clause | Requirement | COHESION satisfies via |
|---|---|---|
| 14(1) | Overall human-oversight obligation | Org-level compliance threshold §5.1, L2 or L3 |
| 14(2) | Appropriate oversight for intended use and foreseeable misuse | Domain calibration §6.1, role adjustments §6.4 |
| 14(3) | Oversight measures identifiable in the system | IMP telemetry and audit log |
| 14(4)(a) | Understand capacities and limitations | J2 Error Detection, J3 Independent Performance, J6 Domain Confidence |
| 14(4)(b) | Remain aware of automation bias | J4 Deliberation Depth, J5 Post-Error Recalibration, IMP calibration |
| 14(4)(c) | Correctly interpret output | J2, J6, combined with role-specific benchmark |
| 14(4)(d) | Disregard, override, reverse, intervene | J1 Deferral Resistance, J7 Decision Autonomy, IMP withholding |
| 14(5) | Additional oversight in biometric identification | L3 certification with domain-specific extension |
| Annex III point 1 | Remote biometric ID | Domain: general + extension |
| Annex III point 2 | Critical infrastructure | Domain: critical infrastructure |
| Annex III point 3 | Education and vocational training | Domain: general + extension |
| Annex III point 4 | Employment, worker management | Domain: general + extension |
| Annex III point 5 | Credit and pricing, essential services | Domain: financial services |
| Annex III point 6 | Law enforcement | Domain: legal + extension |
| Annex III point 7 | Migration, asylum, border | Domain: legal + extension |
| Annex III point 8 | Administration of justice | Domain: legal |
| NIST function | Sub-category | COHESION component |
|---|---|---|
| Govern | GV-1.4 | Written attestation and tier filing |
| Govern | GV-3.2 | Compliance officer, conformity assessor, and deployer-responsibility structure defined in §12 and §13 |
| Map | MP-5.1 | Risk-tier per deployment |
| Measure | MS-2.3 | Per-dimension measurement per §4 |
| Measure | MS-2.5 | Adversarial and calibration testing via IMP |
| Measure | MS-2.8 | Override statistics and human-oversight outcomes documented in audit log (§10.5) and JIS trend data (§24.5) |
| Measure | MS-2.9 | Error pattern reporting via post-error recalibration signals |
| Measure | MS-3.2 | Full operator-AI interaction telemetry |
| Measure | MS-4.1 | Audit log and retention §11.4 |
| Manage | MG-2.2 | Alerts and mitigation §5.2 |
| ISO 42001 clause | Requirement | COHESION satisfies via |
|---|---|---|
| 6.1.3 | AI risk treatment | Tier selection and implementation plan |
| 7.5.3 | Documented information | Spec adherence statement + calibration library hashes |
| 8.2 | AI system impact assessment | DPIA template in Annex F |
| 8.3 | Human oversight | Full COHESION implementation (any tier) |
| 8.4 | Performance monitoring | JIS trend reports, band transition logs |
| 9.1 | Monitoring and measurement | Per §4 signals |
| 10.2 | Nonconformity and corrective action | Post-error recalibration and remediation procedures |
See Annex H (§27) for extended regulatory mapping to Colorado AI Act, UK AI Safety Framework, GDPR, and the proposed US GUARDRAILS Act.
| Field | Type | Constraint | Purpose |
|---|---|---|---|
ai_recommendation_presented | boolean | required | Was an AI recommendation shown to the operator |
time_to_decision_ms | number | ≥ 0 | Wall-clock time from presentation to operator decision |
decision | enum | accepted | modified | rejected | independent | Operator's terminal action |
modification_extent | number | 0.0-1.0 | Degree of modification (if decision = modified); 0 for accepted/rejected/independent |
ai_available | boolean | required | Whether AI was available for this interaction; false captures withholding events |
scenario_type | enum | standard | independent | trap | split | Normal / withholding / calibration-injection / unranked |
outcome_correct | boolean | null | null if ground truth unknown | Whether the final decision matched ground truth (backfilled when known) |
hover_events | number | ≥ 0 | Count of interactions with AI-adjacent evidence elements |
scroll_depth | number | 0.0-1.0 | Proportion of available evidence scrolled through |
alternative_views_checked | number | ≥ 0 | Count of alternative-option or non-AI view accesses |
The operator_id MUST match the regex ^[A-Za-z0-9_-]{1,256}$. Operator IDs are organisation-scoped. Personal data (name, email) MUST NOT be used as operator_id; a pseudonymous identifier is required.
healthcare · aviation · financial · legal · pharmaceutical · general. (Critical infrastructure is modelled as a deployment attribute within general or dedicated per-sector sub-types in a future spec version.)
Implementations MAY capture additional fields for richer analysis. None of these are required for conformance:
| Field | Type | Purpose |
|---|---|---|
operator_role | string | Role within domain (e.g., "radiologist", "AML analyst", "air traffic controller") |
operator_seniority_years | number | Years in role (calibration adjustment) |
ai_model_id | string | Identifier for the underlying AI system |
ai_confidence_expressed | number | AI-reported confidence in its recommendation (0-1) |
operator_confidence_expressed | number | Operator-reported confidence in final decision (0-1) |
annotation_text_length | number | Character count of operator-authored annotations |
external_sources_consulted | array of strings | System identifiers for non-AI sources referenced |
interaction_complexity_score | number | Pre-computed complexity rating (implementation-defined) |
Extended fields MUST NOT change the weights in §4 and MUST NOT alter the composite JIS computation.
Every material event in the system MUST be written to an append-only audit log. See Annex J (§29) for the full schema. Required fields at minimum:
event_id (UUID v4)event_type (closed vocabulary from audit-log CHECK constraint)actor_type (operator / admin / system)actor_id (operator_id or admin identifier)org_id (scoped to organisation)timestamp (RFC 3339)request_id (correlated across the request lifecycle)payload_hash (SHA-256 of relevant event-type-specific payload)Reviewer identity traceability is conditional on the authentication path. On the reviewer-console (JWT or magic-link) path, each human review is atomically linked to an individually authenticated reviewer (single-use, email-tied link; HMAC-SHA256 chain). On the raw API-key path, reviewer identity is written from the caller-supplied X-Cohesion-User-Id header, which is informational only and not cryptographically verified by COHESION; if no reviewer identifier is supplied, the review is logged with reviewer identity recorded as unknown. Deployers who require unconditional person-level audit trails MUST use the reviewer-console path or implement out-of-band identity verification for API-key review submissions.
Conformant paid deployments SHOULD make signed, exportable oversight evidence artifacts available to the account that generated the underlying telemetry. Evidence artifacts MAY include per-decision receipts, regulator reports, DDQ kits, methodology annexes, and audit-log exports.
Public receipt verification means checking whether a receipt the verifier already has was changed after issuance. A public checker MUST require the verifier to supply the receipt payload or receipt envelope being checked. It MUST NOT expose, imply, or depend on a public database of customer receipts. Public verification MAY confirm signature integrity, payload hash integrity, canonicalization, schema version, issuer, issuance time, and whether the supplied receipt remains internally consistent with the signed fields available to the checker. Unless an external anchor or downloadable verifier is actually shipped for a deployment, public language MUST NOT imply verification independent of every COHESION-controlled system.
DDQ kits are signed evidence bundles prepared for customer due-diligence workflows. A DDQ kit MAY map the same telemetry and report envelope to common vendor-risk questionnaire categories, including CAIQ, SIG, VSQ, security, privacy, auditability, AI oversight, and regulatory-control evidence. The DDQ kit is an evidence export; it does not change the scoring methodology.
Mandatory Reasoning Capture (MRC) is a deployment option for workflows where independent human reasoning must be evidenced before an AI recommendation is revealed. In an MRC workflow, the reviewer submits a pre-AI reasoning artifact before seeing the AI recommendation; the artifact or its hash is appended to the audit chain and may later support review-quality evidence. MRC is evidence capture, not model training, and it does not replace the JIS seven-dimension scoring model.
The reference implementation (see §14) exposes 50 endpoints grouped into eight categories: baseline scoring + administration self-serve + meta (19), administration master-key (9 - added 2026-05-02 per scoring-api/CLAUDE.md "## 2026-05-02 additive authorization"), Decision Routing System / DRS (6 - added 2026-05-06), Reviewer Console (6 - added 2026-05-08), Methodology Annex (3 - added 2026-05-11 and 2026-05-12), Demo idempotency (1 - added 2026-05-12), Coverage Telemetry (2 - added 2026-05-13), and Single Sign-On / SSO (5 - added 2026-05-14). Full operational reference at cohesionauth.com/api.
| Method | Path | Auth | Purpose |
|---|---|---|---|
| GET | / | none | Health check |
| GET | /v1 | none | API info · self-describe |
| POST | /v1/score | key | Score a single interaction |
| POST | /v1/score/batch | key | Score ≤ 100 interactions in one call |
| GET | /v1/operator/:operator_id/profile | key | Operator judgment profile over time |
| GET | /v1/organization/dashboard | key | Aggregate organisation scores |
| POST | /v1/maintenance/recommend | key | Intervention recommendation |
| GET | /v1/compliance/report | key | Article 14 oversight evidence report (persisted) |
| POST | /v1/admin/key/rotate | key | Self-serve rotation; returns new key once |
| POST | /v1/admin/key/revoke | key | Self-serve revocation |
| GET | /v1/admin/audit-log | key | Own-organisation audit events |
| POST | /assessments | public (IP-rate-limited) | Submit a completed public-demo run |
| GET | /assessments/:sessionId | public | Retrieve a shared demo run for rendering |
Primary: X-API-Key header. The deprecated api_key body field is accepted until 2026-07-15 with Deprecation and Sunset response headers.
Keys: format ck_live_<26-char-Crockford-base32>. Body entropy is 130 bits via a cryptographically secure random source. Keys are SHA-256 hashed at rest with a pepper held in the implementation's secrets store; plaintext keys are never persisted to primary storage or logs.
All authentication responses (success, unknown prefix, wrong hash, inactive, expired, rate-limited) MUST observe a uniform minimum response time of 80 ms to prevent oracle attacks. Real failure reasons are recorded to the audit log, never returned to the client.
Two layers:
Both MUST emit RFC-7231-conformant integer Retry-After headers ≥ 1 and MUST write to the audit log on enforcement.
GET /v1/admin/audit-log and exportable via GET /v1/admin/audit-log/export); 90 months cold archive (forensics and compliance export only). The 90-day hot tier balances incident-diagnosis utility with personal-data minimization. The 90-month cold archive is intended to support Article 14 and equivalent oversight-evidence records while aligning with multi-year audit baselines common to financial-services and healthcare regulators.Customers requiring retention longer than 24 months for interactions or longer than the published tiers for audit / alerts must export via the compliance-report endpoint and store in their own systems. Implementation note: implementation of the 90-month cold archive is a deployer obligation. This document does not specify a reference cold archive worker design (R2-backed). Where the 90-month cold archive is not deployed, only the 90-day hot tier is enforced in implementation. This specification is the normative target; deployments MUST disclose any divergence in their published Methodology Annex.
All responses follow a uniform JSON envelope:
{
"request_id": "uuid",
"timestamp": "2026-04-21T14:32:11Z",
"data": { ... } | null,
"error": { "code": "ERROR_CODE", "message": "human-readable" } | null,
"meta": { ... optional ... }
}Error codes are enumerated in Annex B (§21).
Breaking changes to any /v1/* endpoint require a new version path (/v2/*) and a minimum 12-month deprecation window on the previous version. Additive changes (new optional fields, new endpoints) MAY be deployed to the current version without a version bump.
Writeback is evidence sync into customer systems of record. Conformant SDKs and integrations MAY forward COHESION evidence events into customer-controlled GRC systems, ticketing systems, audit repositories, data warehouses, SIEM or security logging systems, HR or CRM systems, vendor-risk platforms, and comparable systems of record. Writeback MUST be treated as downstream evidence synchronization and workflow continuity, not model training. A writeback adapter SHOULD preserve request identifiers, decision identifiers, artifact hashes, timestamps, event type, org scope, reviewer identity status, and any artifact signature metadata needed to reconcile the customer record with the COHESION audit trail.
JIS data is personal data under GDPR and equivalent frameworks. All processing MUST satisfy:
Deployments MUST complete a Data Protection Impact Assessment before operating COHESION in any EU jurisdiction, in line with GDPR Article 35. A template DPIA structure is provided in Annex F (§25).
JIS data collected in the EEA MUST be processed under a lawful cross-border transfer mechanism if it leaves EEA territory. Standard Contractual Clauses or Binding Corporate Rules are the expected mechanisms as of specification publication. The reference implementation at api.cohesionauth.com operates on Cloudflare Workers; implementers MAY restrict processing to EEA points of presence using Cloudflare's Regional Services Data Localization Suite, AWS local-zone EEA-only deployment, or Hetzner / OVHcloud EEA datacenter binding. Implementations using any other geographic-restriction mechanism MUST document the specific contractual and technical control set that constrains data egress to EEA territory; absence of that documentation invalidates the L1+ claim.
Operators MUST have a documented grievance procedure covering at minimum: contestation of a classification-band transition; request for re-evaluation of a specific scored interaction; request for independent review of the safety-net integrity; withdrawal from voluntary measurement (where local law permits). See Annex I-R (§28.5) for the normative grievance procedure.
Tier L1 and L2 organisations MUST maintain internal evidence of:
Tier L3 requires an independent conformity assessor - a notified body designated under EU AI Act Annex III, OR an ANAB-accredited ISO/IEC 17029 inspection body, OR a member firm of the Big Four operating its AI Assurance practice (Deloitte, EY, KPMG, PwC) - to audit against this specification. No other entity classes are recognized at L3. The assessor MUST verify:
Material misrepresentation of certification status, failure to remediate a tier downgrade within 90 days, or a critical safety-net failure MUST result in mark revocation. Revoked marks are published publicly.
An organisation whose certification has been revoked MAY appeal within 30 days. Appeals are heard by a three-person panel composed of a domain expert, a regulatory-framework expert, and a member of the specification custodian. The panel's decision is binding.
The COHESION assurance program offers no free assurance tier. Every assurance level (Self-Reported, Audited) is paid. This aligns with the practice of established certification authorities (FICO, Moody's, ANAB) and ensures organisations engaging with the certification process are committed to the underlying compliance work.
A free Developer tier exists for evaluation and integration, but it is deliberately walled off from the assurance program: it returns raw scoring data only, with no signed Methodology Annex, no signed audit-log export, no signed evidence of any kind, and no assurance level. Because free output carries no signature and no assurance level, it can never be presented as compliance evidence. The original rationale (preventing free artifacts from devaluing audit evidence) is preserved and, as of 2026-06-09, enforced as a hard product boundary: signed, audit-ready artifacts are available exclusively on paid tiers and are cryptographically signed to the account that generated them.
A reference implementation is maintained by the specification custodian at:
https://api.cohesionauth.com (documentation at cohesionauth.com/api)cohesionauth.com/research/21-cases. 21 documented judgment-decay cases across six regulated domains, validating the seven-dimension structure and decay parameters in §4 and §6.https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6571519.| Version | Date | Changes |
|---|---|---|
| 1.0 | 2026-04-16 | Initial public release. |
| 1.0.1 | 2026-04-21 | Editorial: expanded measurement signals (§4.1); added minimum-data thresholds per dimension (§4.2); documented parameter derivation (§6.2); added role-based adjustments (§6.4); expanded safety-net requirements (§7.4); added suspension conditions (§7.7); enumerated audit criteria per tier (§8.3); added cross-tier progression guidance (§8.4); added response envelope and versioning (§11.5, §11.6); added DPIA requirement (§12.1) and cross-border transfer (§12.2); added appeal procedure (§13.4); added 13 annexes (§§20-33). |
| 1.1 | 2026-04-28 | Added §7.8 cognition probes (counterfactual delta + pre-commitment detection), §8.5 assurance levels (Self-Reported + Audited), §13.5 no-free-tier rationale. Updated §14 reference implementation and §19 companion materials with provisional patent application 64/051,131 and SSRN paper canonical URL. No backward-incompatible changes to §1 to §6. |
| 1.2 | 2026-05-27 | Currency update. Recast §1.1 to centre the durable problem (no runtime measure of independent human judgment in high-stakes AI decisions) and present the legal landscape as multiple converging drivers US-first (Colorado SB 26-189, NIST AI RMF, US federal AI Executive Order, SEC guidance, proposed GUARDRAILS Act, other state ADMT laws, ISO/IEC 42001), with EU AI Act Article 14 as one leg rather than the spine. Article 14 enforcement dates omitted pending Parliament-Council finalisation. Promoted the Decision Risk Score (DRS) to first-class status in §1.2 and §1.4 alongside JIS, with normative methodology cross-referenced to Annex K (§34). Added a normative §1.2 clause stating that DRS and JIS MUST NOT be conflated; this is a clarification of the v1.1 implicit DRS/JIS separation, not a new behavioural requirement on conformant implementations. Clarified that JIS is a reviewer-level score and that organisation-level JIS values are rollups derived by aggregating reviewer-level scores. Added Colorado SB 26-189 (signed 2026-05-14, effective 2027-01-01) to §2 normative references, §27.1.1 extended regulatory mapping (including the verbatim "meaningful human review" four-prong definition from the enrolled signed-Act PDF), and the bibliography. Updated §1.4 section, annex, and line counts. No backward-incompatible changes to JIS methodology, scoring numbers, dimension weights, or existing normative MUST/SHOULD/MAY requirements; the new §1.2 MUST NOT clause is a clarifying separation between DRS and JIS, not a behavioural change. |
| 1.2.1 | 2026-06-27 | Non-normative factual errata refresh. Corrected the Colorado SB 26-189 effective-date treatment throughout (Section 5: effective 2027-01-01 except for listed rulemaking, appropriation, and related procedural provisions effective upon passage; applies to consequential decisions made on or after 2027-01-01) in §1.1, §2, §27.1.1, and the bibliography. Demoted SB 24-205 from a standalone normative reference and bibliography entry to a parenthetical superseded predecessor, and labeled the §27.1 SB 24-205 mapping table as historical reference only. Replaced the deliberately omitted EU AI Act hedge with adopted-Regulation language while avoiding a single-date Article 14 claim. Added NIST AI RMF MEASURE 2.8 and GOVERN 3.2 rows to §9.2 and refined the §27.3 MS-2.8 override-statistics mapping. Added §10.6 reviewer-identity traceability conformance limitation note and the corresponding §26.3 Tier L3 checklist item. Replaced the prior cold-archive implementation marker in §11.4 with the final retention divergence disclosure. Added the L1 self-serve pricing tier (US$299/month, US$2,990/year, 10,000 decisions/month) to §8.5.4. Added the SB 26-189 "authority to approve, modify, or override" prong as an explicit enumerated item in the §27.1.1 meaningful-human-review definition and mapped it to J1 and J7. The frozen measurement core is unchanged (the seven JIS dimensions and weights, classification bands, decay model and parameters, IMP intervention types, and DRS subscores and weights are byte-identical to v1.2); no revalidation of the normative methodology required and no patent scope change. The §10.6 reviewer-identity disclosure and its §26.3 Tier L3 checklist item are the only added conformance obligation; they document existing product behavior and alter no measurement, score, or threshold. |
| 1.3.0 | 2026-06-30 | Evidence-surface refresh. Added named coverage for exportable signed evidence receipts, public receipt verification, regulator reports, due-diligence questionnaire kits, Mandatory Reasoning Capture, reviewer-independence collapse monitoring, judgment velocity, and customer-system writeback. Clarified verification limits and removed public Enterprise floor pricing. No change to JIS weights, DRS weights, decay parameters, classification bands, or IMP intervention types. |
Change requests to this specification are accepted at standard@cohesionauth.com. Minor editorial revisions within a major version are made at the custodian's discretion and dated; major changes go through a public comment period.
A compatibility-break (normative change that would invalidate existing L3 certifications) requires a major version increment (v2.0 etc.) and a 12-month migration window.
"COHESION Certified" is a trademark of COHESION AUTH LLC. Use is permitted only by organisations holding a current Tier L3 certification. The specification itself (methodology, dimensions, decay model, IMP, tier definitions) is freely implementable under the permissive standards licence described at the top of this document.
The seven-dimension framework draws on the automation-bias literature (Skitka and Mosier 1999; Parasuraman and Manzey 2010), the decision-confidence literature (Lerner et al. 2015), and the organisational-learning literature on vigilance decrement (Warm et al. 2008). The 21-case empirical library was assembled from regulatory filings, peer-reviewed case studies, and public incident reports between 2018 and 2026. Individual case citations are in the companion case-library document.
cohesionauth.com/research/21-cases (21 documented judgment-decay cases)cohesionauth.com/apicohesionauth.com/integrationscohesionauth.com/pricing and cohesionauth.com/standard/assurance-levelscohesionauth.com/democohesionauth.com/enterprisehttps://papers.ssrn.com/sol3/papers.cfm?abstract_id=6571519 (Judgment Decay in AI-Augmented Environments)cohesionauth.com/research. Provisional Application Nos. 64/038,246 (filed April 13, 2026), 64/051,131 (filed April 28, 2026), 64/071,826 (filed May 21, 2026), and 64/096,426 (filed June 22, 2026). Customer 230082.A Tier L2 or L3 implementation MUST maintain a calibration scenario library of at least 200 scenarios per domain in active use. Scenarios are the raw material of the IMP: each scenario is a template from which a specific injection event is generated at runtime, calibrated to the operator's current JIS and dimension-level scores.
Each scenario MUST carry at least the following metadata:
| Field | Type | Purpose |
|---|---|---|
scenario_id | string | Stable identifier across spec versions |
domain | enum | Which domain the scenario targets |
sub_role | string | null | Role specialisation if narrower than domain |
difficulty | enum | easy | moderate | subtle | adversarial |
target_dimension | enum | Which of J1-J7 the scenario primarily exercises |
ground_truth | any | The correct operator response |
expected_ai_output | any | The AI output the operator will see (contains the injected error) |
error_taxonomy | enum | omission | commission | context_violation | hallucination | stale_reference |
safety_tier | enum | safe (no real-world consequence) | contained (consequence absorbed by safety-net) |
authoring_source | string | Where the scenario was sourced (case library, expert panel, synthetic) |
last_reviewed | date | Date of last quality review |
A conformant library MUST cover the following distribution per domain:
These requirements prevent a library that drills the same error type repeatedly.
Scenarios MUST rotate to prevent operator memorisation. Minimum requirements:
The following illustrate the scenario structure for three domains. Implementers MAY use these as starting points but MUST NOT rely on them alone.
Healthcare / radiology / moderate / J2: AI-annotated CT shows a suspected 8mm nodule with "likely benign" classification. Injected error: the nodule is actually in the left lung but AI annotation is placed on the right lung. Expected operator response: reject or modify with anatomical correction. Safety-tier: contained (report is intercepted before leaving the reading room).
Financial services / AML / subtle / J1: AI flags a transaction cluster as "LOW" money-laundering risk. Injected error: the cluster includes a counterparty newly sanctioned under EU restrictive measures 2024/789, published three weeks prior. The AI's training data is stale. Expected operator response: override to HIGH with reference to the sanctions list. Safety-tier: contained.
Legal / contract review / adversarial / J2: AI summarises a contract clause as "standard indemnification." Injected error: the clause contains a rare "gross negligence carveout" that substantially reduces indemnity. Expected operator response: catch the carveout, escalate. Safety-tier: contained.
| Code | HTTP | Meaning | When |
|---|---|---|---|
INVALID_JSON | 400 | Request body is not valid JSON | Body-parser fails |
VALIDATION_ERROR | 422 | Body violates schema | Field-level validation fails |
UNAUTHORIZED | 401 | Auth missing or invalid | Any auth failure mode (uniform envelope) |
FORBIDDEN | 403 | Authenticated but not permitted for resource | Cross-org access attempt |
NOT_FOUND | 404 | Resource does not exist | Unknown operator_id or session |
PAYLOAD_TOO_LARGE | 413 | Request body exceeds size limit | >1 MB single or >5 MB batch |
BATCH_TOO_LARGE | 422 | Batch count exceeds 100 | Batch size limit |
RATE_LIMITED | 429 | Layer 1 or Layer 2 rate-limit tripped | Throttle exceeded |
INTERNAL_ERROR | 500 | Unhandled server error | Catch-all, event logged |
SERVICE_UNAVAILABLE | 503 | Backend unavailable | D1 or rate-limiter unavailable |
POST /v1/score - single interaction scoringRequest body:
{
"operator_id": "org42_op_c9f3b2a1",
"domain": "financial",
"interaction": {
"ai_recommendation_presented": true,
"time_to_decision_ms": 4200,
"decision": "modified",
"modification_extent": 0.4,
"ai_available": true,
"scenario_type": "standard",
"outcome_correct": null,
"hover_events": 3,
"scroll_depth": 0.65,
"alternative_views_checked": 1
}
}Response 200:
{
"request_id": "9a8b7c6d-5e4f-3210-9876-543210fedcba",
"timestamp": "2026-04-21T14:32:11Z",
"data": {
"jis": 68,
"dimensions": {
"deferral_resistance": 72,
"error_detection": 70,
"independent_performance": 64,
"deliberation_depth": 66,
"post_error_recalibration": 70,
"domain_confidence": 67,
"decision_autonomy": 69
},
"classification": "Adequate",
"decay_projection": {
"current_trajectory_30d": 64,
"current_trajectory_90d": 56,
"with_intervention_30d": 72,
"with_intervention_90d": 78
},
"compliance": {
"article_14_status": "pass_with_maintenance_recommended",
"flags": []
},
"maintenance_recommendation": {
"intervention_type": "calibration",
"target_dimension": "independent_performance",
"difficulty": "moderate",
"frequency_next_30d": 0.06
}
},
"error": null
}POST /v1/score/batch - up to 100 interactionsRequest body: array of up to 100 interaction objects with a shared operator_id.
Response 200 returns a results[] array, count integer, and operator_id. Each result carries the same data shape as /v1/score.
GET /v1/operator/:operator_id/profileReturns historical profile: current JIS, trailing 30-day sparkline, per-dimension trendline, band transitions in the retention window, and accumulated interaction count.
GET /v1/organization/dashboardAggregate org-level view: operator count, JIS distribution histogram, band-threshold compliance flag (§5.1), and alert queue.
POST /v1/maintenance/recommendRequest: operator_id and optional override_dimension.
Response: concrete intervention recommendation with suggested exercise library references.
GET /v1/compliance/reportReturns a persisted compliance report suitable for Article 14 evidentiary submission. Response includes report_id, overall_status, per-operator rollup, and a tamper-evident hash.
POST /v1/admin/key/rotate: atomic rotation. New key returned ONCE.
POST /v1/admin/key/revoke: sets active = 0.
GET /v1/admin/audit-log: own-org events with filter params event_type, since, until, limit (max 500).
POST /assessments: submit completed demo run (IP-rate-limited).
GET /assessments/:sessionId: retrieve shared demo run.
An AML analyst at an EU bank reviews a transaction flagged by an AI model as "LOW risk." The operator has been using COHESION for 6 months. Current JIS: 67 (Adequate). Current dimension scores: J1=70, J2=65, J3=62, J4=68, J5=71, J6=69, J7=70.
The operator spends 6,800 ms reviewing the transaction. During review, they:
Captured interaction record:
{
"ai_recommendation_presented": true,
"time_to_decision_ms": 6800,
"decision": "modified",
"modification_extent": 0.33,
"ai_available": true,
"scenario_type": "standard",
"outcome_correct": null,
"hover_events": 1,
"scroll_depth": 0.78,
"alternative_views_checked": 1
}The scoring engine computes, for this single interaction, contributing signals:
For each dimension with a contributing signal, the EWMA is updated with a per-interaction weight derived from the 30-day half-life (approximate decay factor 0.977 per interaction at 10 interactions/day):
J2, J3, J5 unchanged.
Weighted sum of updated dimensions:
JIS = 0.20 × 70.18 + 0.20 × 65 + 0.15 × 62 + 0.15 × 68.26 + 0.10 × 71 + 0.10 × 69.05 + 0.10 × 70.21 = 67.19
Rounded to integer: 67. No band transition.
This interaction writes the following audit events:
INTERACTION_SCORED - operator_id hash, domain, interaction_id, resulting JIS.DIMENSION_UPDATED × 4 - one per updated dimension.MAINTENANCE_RECOMMENDATION_ISSUED - recommendation target and frequency.No band transition, no alert, no intervention triggered in this interaction.
The 21-case cross-case library (published 2026-04-19 at cohesionauth.com/research/21-cases) grounds the decay parameters in §6.1 and the dimension weights in §4. A summary of each case follows. Full case studies with citations are in the library itself.
Across all 21 cases, the pattern is consistent: measurable decline in independent operator behaviour over 6-18 months of continuous AI-augmented work, with faster decay in high-volume short-interaction workflows (financial services) and slower decay in workflows with strong independent verification culture (pharmaceutical, aviation). The dimension weights in §4 emerged from frequency analysis of which dimensions were primarily compromised across the library.
The displayed JIS is an exponentially weighted moving average over per-interaction contributions:
JIS_t = λ · x_t + (1 − λ) · JIS_{t−1}Where λ is the smoothing factor chosen to produce a 30-day effective half-life at the operator's expected interaction rate. For an operator at 10 interactions/day:
λ = 1 − 2^(−1/300) ≈ 0.00231
For different interaction rates, λ MUST be adjusted so the effective half-life remains 30 days:
λ = 1 − 2^(−1 / (N × 30))
Where N is the expected daily interaction count for the operator's role.
An implementation SHOULD report a 95 % confidence interval around the displayed JIS. For EWMA, the CI depends on the underlying variance of per-interaction contributions:
CI = JIS ± 1.96 · σ · √(λ / (2 − λ))Where σ is the empirical standard deviation of per-interaction contributions over a lookback window. With typical empirical values, the half-width of the 95 % CI is 3-6 JIS points.
A band transition (e.g., from Adequate to At Risk) SHOULD NOT trigger on a single noisy observation. An implementation MUST require that the EWMA cross the threshold and remain across for at least 3 consecutive updates before declaring a transition. This reduces false alarms while preserving sensitivity to genuine decline.
The weights in §4 (J1 0.20, J2 0.20, J3 0.15, J4 0.15, J5 0.10, J6 0.10, J7 0.10) were derived by a variance-decomposition analysis of the 21-case library, assigning higher weight to dimensions that discriminated strongly between cases with known incident outcomes and cases without. These weights MUST NOT be re-fit by individual implementations; variation requires a specification fork.
Organisation-level JIS trends SHOULD be monitored with control charts. A downward shift in median organisational JIS of > 4 points over a 30-day window, sustained for 60 days, indicates a systemic issue (training gap, AI-system change, workflow change) and MUST trigger a documented investigation.
Judgment velocity is the signed trend slope of reviewer or organisation JIS over a defined measurement window. It is a trend signal over JIS, not a substitute for JIS and not a DRS input unless a deployment explicitly configures a downstream policy using it. Customer-facing reporting SHOULD describe judgment velocity as improving, stable, or declining judgment quality over time and SHOULD preserve the measurement window used.
CRICS is an internal collapse-risk signal for correlated reviewer independence failure across a tenant or reviewer pool. CRICS MUST be treated as an operational alarm and investigation trigger, not as a public individual-reviewer score. Customer-facing summaries MAY report independence-risk progress or trend status, such as improving, stable, worsening, investigation opened, investigation resolved, or evidence insufficient, without exposing individual reviewer rows unless the customer's contract and law permit it.
Under GDPR Article 35, a DPIA is required where processing is likely to result in high risk to natural persons. COHESION processing in an operator-oversight context meets this threshold due to: systematic monitoring, use of new technology, and data that could affect employment outcomes.
Section 1: Processing description. Describe the COHESION deployment. Include: number of operators, domain, retention duration, which endpoints are used, who has access to what data.
Section 2: Necessity and proportionality. Justify why JIS measurement is necessary for Article 14 (or congruent obligation) compliance, and why it is proportionate (i.e., why a less invasive measurement would not suffice).
Section 3: Data-subject rights. Document how operators can exercise GDPR Articles 15-22 rights. Specifically: access procedure, rectification (limited to metadata), restriction, objection, and withdrawal (where legally permitted).
Section 4: Risk identification. Enumerate risks: wrongful disciplinary action based on JIS; re-identification from pseudonymised operator_id; data breach affecting sensitive behavioural data; function creep into performance evaluation.
Section 5: Risk mitigation. Mapping of each identified risk to a mitigation. For wrongful discipline: the §12 policy that JIS cannot alone ground discipline. For re-identification: pseudonymous IDs, access controls, audit logs. For breach: encryption, access monitoring, incident response. For function creep: documented purpose limitation and periodic review.
Section 6: DPO consultation. Evidence of Data Protection Officer review and sign-off. Date, name, findings.
Section 7: Data-subject consultation. Where practicable (e.g., through a works council or employee representation), consultation with operators on the DPIA findings.
Section 8: Residual risk assessment. After mitigation, the residual risk level. If residual risk remains high, supervisory authority consultation is required under Article 36.
Section 9: Review schedule. The DPIA MUST be reviewed annually or on any material change to processing.
The completed DPIA MUST be stored with the implementation records and be producible within 72 hours on request from a supervisory authority.
Architectural:
Governance:
Operational:
Calibration library:
IMP:
Safety-net:
Governance:
HISTORICAL REFERENCE ONLY: SB 24-205 was repealed and replaced by SB 26-189 (signed 2026-05-14). For current Colorado compliance obligations, see §27.1.1, which is the operative mapping.
Colorado's original Consumer Protections for Artificial Intelligence Act (SB 24-205) was codified at Colo. Rev. Stat. § 6-1-1701 et seq. with a 2026-02-01 effective date. It imposed duties on developers and deployers of "high-risk artificial intelligence systems" making "consequential decisions" about consumers. The mapping below reflects the SB 24-205 framework as originally enacted and is retained for historical continuity only:
| Colorado clause (SB 24-205, superseded) | Requirement | COHESION satisfies via |
|---|---|---|
| § 6-1-1702(11) | Definition of consequential decision | Tier L1 minimum where deployment makes consequential decisions |
| § 6-1-1703(1)(a) | Duty of reasonable care | Implementation of L2 or L3 demonstrates reasonable care |
| § 6-1-1703(2) | Risk management programme | COHESION programme with DPIA satisfies |
| § 6-1-1703(3)(a) | Impact assessment | DPIA plus Article 14 oversight evidence report |
| § 6-1-1704 | Disclosure to consumers | Operator-side COHESION is upstream of consumer disclosure |
On 2026-05-14, Governor Polis signed SB 26-189 (Automated Decision-Making Technology), which repealed and reenacted the prior Colorado AI Act framework. Section 5 states that, except for listed rulemaking, appropriation, and related procedural provisions effective upon passage, SB 26-189 takes effect 2027-01-01 and applies to consequential decisions made on or after 2027-01-01. SB 26-189 reframes the law around "Covered Automated Decision-Making Technology (ADMT)" that "materially influences" a "consequential decision" in education, employment, housing, financial or lending services, insurance, health-care services, or essential government services. Enforcement is by the Colorado Attorney General under the Colorado Consumer Protection Act; there is no private right of action.
The central deployer duty introduced by SB 26-189, and the provision most directly aligned with the substance of this specification, is its "meaningful human review" standard. The enrolled Act defines "MEANINGFUL HUMAN REVIEW" as review by an individual designated by the deployer who:
Source: enrolled signed-Act PDF, leg.colorado.gov/bill_files/116489/download (verified 2026-05-21).
Prong (a), the authority to approve, modify, or override, presupposes the independent judgment this specification measures: it is mapped to J1 Deferral Resistance and J7 Decision Autonomy, the dimensions that capture whether the reviewer exercises authority over the decision rather than ceding it to the model. Prong (d), the "does not default to the system output" requirement, is the first US state-statutory codification of automation bias as the substantive standard for human review. It is the precise question this specification's JIS is designed to answer about a reviewer in operation, and the precise question its DRS is designed to ensure is asked of every consequential AI decision before output release.
| SB 26-189 obligation | COHESION component |
|---|---|
| Pre-use clear and conspicuous notice to the consumer at point of interaction | Out of scope for COHESION; operator disclosure §7.5 covers the IMP-side disclosure obligation |
| Post-adverse-outcome disclosure of ADMT role | Audit log §10.5 and Annex J (§29) provide the per-decision record from which deployer disclosures can be assembled |
| Right to inspect/correct data | Out of scope for COHESION; deployer obligation under SB 26-189 (data-access and correction workflows sit outside the AI-output middleware boundary) |
| Right to request meaningful human review where technically feasible | DRS (Annex K §34) gates high-risk AI output to a human reviewer; JIS (§4) evidences prong (d) of the standard (reviewer does not default to AI output) and prong (a) (authority to approve, modify, or override) via J1 Deferral Resistance and J7 Decision Autonomy. Prongs (b) consideration of primary evidence, (c) reviewer training, and (e) access to sufficient information are deployer obligations and out of scope for COHESION's middleware. |
| "Meaningful human review" standard | DRS routing + JIS instrumentation: prong (a) authority to approve, modify, or override maps to J1 Deferral Resistance and J7 Decision Autonomy; prong (d) does-not-default maps to J1 Deferral Resistance, J2 Error Detection, J3 Independent Performance, and J4 Deliberation Depth, which jointly produce the per-decision and per-reviewer evidence that the reviewer did not default to the system output |
| Compliance records retention of at least 3 years | Audit log retention §11.4 (90-day hot, 90-month cold archive) exceeds the SB 26-189 minimum |
| Developer obligation that cannot be contractually shifted to deployer | Methodology Annex hashes (§7.5) and audit log §10.5 produce documentation usable by either party |
Note on Article 26 and the HIPAA carve-out: SB 26-189 includes targeted exemptions for HIPAA-covered entities and their business associates for certain clinical-utilization-review decisions, but does not exempt employment-related decisions or financial-assistance eligibility determinations made by those entities. Deployers should resolve carve-out applicability per their compliance counsel.
The UK's five cross-sectoral principles (safety, transparency, fairness, accountability, contestability) map to COHESION at:
In addition to §9.2, the following additional NIST sub-categories are supported:
| NIST sub-category | Requirement | COHESION component |
|---|---|---|
| GV-1.1 | Legal and regulatory requirements catalogued | §9 regulatory mapping |
| GV-1.3 | Policies aligned to risk | Tier selection |
| GV-4.1 | Organisational roles and responsibilities | Compliance officer + DPO designation |
| MP-4.1 | Context and intended purpose | Domain selection and role adjustment |
| MS-1.1 | Trustworthy characteristics | Seven dimensions cover a subset; others require model-side tooling |
| MS-2.1 | Test sets representative | Calibration library diversity §20.3 |
| MS-2.8 | Override statistics maintained; operator feedback loops | Override statistics maintenance: JIS trend data (§24.5), audit log (§10.5); operator feedback loops: grievance procedure (§12.3) |
| MG-1.1 | Risk response | Alert and remediation procedures |
| MG-1.2 | Risk management decisions reversible | Suspension conditions §7.7 |
| MG-4.3 | Ongoing monitoring | EWMA with control charts §24 |
If enacted as introduced, the GUARDRAILS Act would impose deployer obligations for high-risk AI systems in federal procurement contexts. COHESION's measurement methodology is anticipated to satisfy the "documented effective human oversight" requirement in the current draft language. Implementers SHOULD monitor for final text.
Annex III enumerates eight high-risk categories. Within each, COHESION applies differently:
ISO 23894 (AI risk management guidance) and ISO 24028 (trustworthiness overview) align with the governance and measurement posture of COHESION. An implementer pursuing concurrent ISO certification alongside COHESION L3 should find substantial evidence overlap.
Verify that no calibration injection can reach a downstream system, external API, or non-intervention human. A failure of this property is a critical defect regardless of frequency.
Testing occurs at three levels:
A release MAY NOT deploy to production if any of the following occur during testing:
intervention_id.In production, the safety-net layer logs every intervention and every stripping event. A reconciliation job MUST run at least daily to confirm every intervention has a corresponding stripping event. A mismatch indicates possible leakage and MUST trigger incident response.
An operator MAY contest any of the following:
Procedure:
The audit-log event_type column is constrained by CHECK to the following closed vocabulary:
| Event type | When |
|---|---|
ORG_CREATED | New organisation onboarded |
ORG_UPDATED | Organisation metadata changed |
KEY_CREATED | API key generated |
KEY_ROTATED | API key rotated via /v1/admin/key/rotate |
KEY_REVOKED | API key revoked via /v1/admin/key/revoke |
AUTH_SUCCESS | Authenticated request |
AUTH_FAIL_UNKNOWN_PREFIX | Unknown key prefix |
AUTH_FAIL_WRONG_HASH | Prefix known, hash does not match |
AUTH_FAIL_INACTIVE | Key inactive |
AUTH_FAIL_EXPIRED | Key expired |
AUTH_FAIL_RATE_LIMITED_IP | Layer 1 rate limit |
AUTH_FAIL_RATE_LIMITED_KEY | Layer 2 rate limit |
INTERACTION_SCORED | Single or batch interaction scored |
DIMENSION_UPDATED | One dimension EWMA updated |
BAND_TRANSITION | Operator crossed a classification band boundary |
MAINTENANCE_RECOMMENDATION_ISSUED | Maintenance recommendation generated |
INTERVENTION_DEPLOYED | Active intervention served to operator |
INTERVENTION_STRIPPED | Safety-net stripped an intervention id |
SUSPENSION_TRIGGERED | IMP suspended |
SUSPENSION_RESTORED | IMP restored |
COMPLIANCE_REPORT_GENERATED | Report generated |
ANOMALY_ALERT | Anomaly detected (rate or behavioural) |
GRIEVANCE_FILED | Operator grievance |
GRIEVANCE_RESOLVED | Grievance resolved |
CONFIG_CHANGED | Configuration change (calibration library, thresholds) |
Audit log retention: minimum 90 months (7.5 years), consistent with regulatory evidentiary expectations in several EU member states. Organisations MAY retain longer where justified.
Audit log access is strictly scoped. Each request to GET /v1/admin/audit-log returns ONLY events for the authenticated organisation. Cross-org reads MUST return 403 FORBIDDEN with no indication of whether the target org exists.
Tier L3 implementations MUST implement a tamper-evident hash chain: each new audit event includes the SHA-256 hash of the immediately prior event. Integrity verification is part of the L3 conformity assessment.
α (alpha). The decay rate coefficient in the judgment-decay model §6.
β (beta). The decay acceleration coefficient in the judgment-decay model §6.
Article 14. Article 14 of the EU AI Act, titled "Human oversight," imposing the measurement obligation central to this specification.
Automation bias. The tendency to over-rely on AI recommendations. Named in Article 14(4)(b).
Band. A contiguous JIS range with an associated label (Exemplary, Proficient, Adequate, At Risk, Impaired, Non-Functional). See §5.
Calibration injection. See §3.
Classification band. Synonym for band.
Compliance officer. The designated person within an implementing organisation responsible for Article 14 and equivalent oversight obligations.
Conformity assessment. The independent third-party audit process required for Tier L3 certification.
CRICS. Cross-Reviewer Independence Collapse Score. An internal collapse-risk signal for correlated reviewer independence failure across a tenant or reviewer pool.
DDQ kit. Signed due-diligence questionnaire kit generated from measured oversight evidence for procurement, vendor-risk, security, privacy, and AI-oversight review.
DPIA. Data Protection Impact Assessment under GDPR Article 35.
EWMA. Exponentially Weighted Moving Average, the time-series method used to produce the displayed JIS. See §24.
γ (gamma). The maintenance efficacy coefficient in the judgment-decay model §6.
JIS. Judgment Independence Score. See §3.
Judgment velocity. The signed trend slope of reviewer or organisation JIS over a defined measurement window.
IMP. Invisible Maintenance Protocol. See §3 and §7.
Intervention. A maintenance event: calibration injection, withholding, or unranked presentation.
L1, L2, L3. The three certification tiers. See §8.
Mandatory Reasoning Capture. A workflow option that records the reviewer's own pre-AI reasoning before an AI recommendation is revealed, so the pre-display artifact can support oversight evidence.
Notified body. In EU conformity-assessment parlance, an organisation authorised by a member state to perform third-party assessments.
Operator. See §3.
Public receipt verification. Checking whether an exportable receipt already held by the verifier was changed after issuance. A public checker does not expose a public database of receipts.
Pseudonymous ID. An identifier that does not directly identify a natural person but, in combination with other data, could. Compare with anonymous (unlinkable).
Safety-net layer. See §3.
Scenario. A template in the calibration library, from which specific injection events are generated at runtime.
Tier. A certification level. See §8.
Weighted composite. The JIS computation method: sum of per-dimension scores times per-dimension weights.
Writeback. Evidence synchronization into customer systems of record such as GRC, ticketing, audit, warehouse, or security logging systems. Writeback is not model training.
This specification is published in service of effective human oversight of AI. Comments, errata, and improvement proposals are welcome at standard@cohesionauth.com. The specification is maintained in public and will evolve in response to regulatory developments, empirical findings, and implementer experience.
End of Specification v1.3.0.
The Decision Risk Score (DRS) is a weighted composite of six 0–100 subscores, each answering a distinct question about whether a given AI decision is safe to finalise without human oversight. The six categories are: decision_impact_risk (how serious is this decision if it is wrong?), model_confidence_risk (how uncertain is the model?), bias_fairness_risk (could this disproportionately affect protected groups?), policy_compliance_risk (does this violate internal or regulatory policy?), data_quality_risk (is the input trustworthy enough?), and operational_anomaly_risk (is something unusual happening in the platform?). Per-org weights across all six categories are validated to sum to 1.00 ±0.01 and stored in the org's compliance profile snapshot; default weights are 0.30 / 0.10 / 0.20 / 0.15 / 0.10 / 0.15 respectively, derived from NIST AI RMF profile calibration and internal empirical data. Every request captures the active policy_version_id so that weight changes are non-destructive and historically traceable.
Every AI decision log row carries a non-null policy_version_id referencing a frozen snapshot row in org_compliance_profile_versions. Profile updates write a new version row (setting the prior row's effective_until to the new effective_from) and never overwrite or delete any prior row. The active profile is resolved via a view that returns the row where effective_from ≤ now() < effective_until (or effective_until IS NULL for the current version). This design means any historical decision is fully replayable against the exact policy configuration in force at the time it was made - enabling auditors to answer "why did this decision auto-pass in May and trigger review in September?" by diffing the two version snapshots. Replay is executed via GET /v1/decision/replay/{ai_decision_log_id}, which re-runs the DRS computation against the original policy_version_id, input_hash, and output_hash without calling the AI provider, and writes a new append-only replayed_for_audit row to the audit chain.
COHESION saves humanity by keeping human judgment alive in the age of AI. The Decision Risk Score is the mechanism that makes this mission operationally scalable: without DRS, every regulated AI decision would require human review to remain auditable - flooding reviewers with low-stakes work and producing sycophantic rubber-stamping at the margin where stakes are highest. DRS triages at the gateway: low-tier decisions auto-pass with full logging; medium-tier decisions are sampled for asynchronous review; high-tier decisions block AI output release entirely until a credentialed human reviewer acts and their Judgment Independence Score is captured. Forced-escalation rules override the weighted score for categories (irreversible decisions, credit denials, healthcare treatment recommendations, employment adverse actions, protected-class signals in high-stakes domains) where regulators and empirical evidence agree that human judgment is non-negotiable regardless of model confidence. The result is that human oversight is concentrated precisely where it matters - not diluted across the full decision stream - preserving the cognitive quality that the JIS measurement surface exists to protect.