Skip to main content
Jira progress: loading…

TG-SG

TrustGate Score Governance

1. Purpose​

The moment the trust score has consequences, the trust score becomes a target. Suppliers who learn that ≥ 0.90 auto-accepts and an EPD adds +0.15 will optimize for the number, not the substance — Goodhart's law with commercial incentives attached.

This specification does not attempt to prevent optimization (it cannot, and some optimization — actually obtaining EPDs — is the desired behavior). It ensures three things instead:

  1. Weights and thresholds are governed artifacts, changed only through an auditable process by a named authority — never tuned in production.
  2. Threshold visibility is a policy decision, made deliberately per audience, not leaked by accident.
  3. Gaming is detectable as telemetry, using the statistical fingerprints that threshold-optimization necessarily leaves behind.

2. Weights, Thresholds, and Modifiers as Governed Artifacts​

2.1. The Weight Bundle​

All scoring parameters live in a single versioned artifact: comp.FAGF.OUTPUT.WEIGHT-BUNDLE.v1_0, CMI-identified (fagf.TG-SG.BUNDLE.WEIGHTS.<major_minor_patch>), containing:

  • Dimension weights wC, wH, wX, wP, wF (per tenant profile / jurisdiction)
  • Routing thresholds (auto-accept, auto-validate, human-review, quarantine)
  • The full dynamic-modifier catalog with values
  • The BANDED replay tolerances ε (cross-reference: TG-RP §2.2)
  • Effective-from timestamp and predecessor bundle reference

2.2. Change Workflow​

Weight bundle changes SHALL follow: proposal → impact simulation → calibration authority approval → scheduled activation.

  • Impact simulation SHALL re-score a representative anchored sample under the proposed bundle and report the decision-exit migration matrix (how many claims would change exits).
  • Every activated bundle SHALL be DAL-anchored; the anchor is the audit answer to "what were the rules on date D".
  • Runtime engines SHALL consume weights exclusively via comp.TG.INPUT.POLICY-CONTEXT.v1_0. Implementations SHALL NOT read weights from configuration files, environment variables, or code constants. There is exactly one path, and it is governed.

2.3. The Calibration Authority​

A named role (initially: CTO; later: assurance calibration board) owns bundle approval. The authority's decisions are TG-AUDIT records. No bundle activates without an identified human approver — weight changes are constitutional amendments, not deployments.

3. Threshold Visibility Policy​

Visibility is stratified by audience. The default policy:

AudienceSeesDoes not see
Submitter (supplier)Qualitative band of own score (STRONG / SOLID / NEEDS REVIEW / INSUFFICIENT) + which dimensions are weakest + which evidence types would strengthen themNumeric score, numeric thresholds, modifier values
Buyer (relationship owner)Numeric score + dimension vector for consented suppliersTenant threshold configuration of other tenants
Auditor profileFull numeric decomposition, weight bundle version, replay manifest—
Regulator profileVerification of specific attestations (read-only, per federation profile)Population data beyond scope of inquiry

Rationale: the submitter feedback loop must be actionable but not solvable. "Your provenance dimension is weak; verifier-confirmed records would strengthen it" produces the desired behavior (better evidence). "You need +0.04 to auto-accept" produces threshold surfing. The first is guidance; the second is an answer key.

Exact cut-points are tenant-private governed values. Publishing them is a per-tenant policy decision that SHALL require an explicit FAGF flag, never a UI default.

4. Gaming Detection​

Optimization against thresholds leaves statistical fingerprints. TG-OBSERVE computes these continuously and publishes them to AII.

4.1. Bunching Detection (primary)​

For each governed threshold t and policy-resolved window δ:

B(t) = mass(scores ∈ [t, t+δ]) / mass(scores ∈ [t−δ, t))

Under no gaming, score density is locally smooth and B(t) ≈ its historical baseline. Threshold-aware submission strategies pile mass just above t — the same excess-bunching signature used in tax-kink and regulatory-notch econometrics. When B(t) exceeds its policy-resolved baseline multiple over a governed window, TG-OBSERVE SHALL emit comp.TG.EVENT.BUNCHING-ALERT.v1_0 scoped to tenant, threshold, and submitter cohort.

A bunching alert is not an accusation; it is a calibration trigger. The response is an investigation task and, where confirmed, a bundle revision — typically threshold randomization within a governed band (§4.4) or modifier re-weighting.

4.2. Modifier-Abuse Detection​

For each dynamic modifier (e.g., EPD +0.15, verifier +0.10), TG-OBSERVE tracks the attach rate per submitter cohort over time. A step-change in attach rate that coincides with scores crossing from just-below to just-above a threshold — without corresponding change in underlying evidence quality signals — SHALL emit comp.TG.EVENT.MODIFIER-ANOMALY.v1_0. Cross-check: modifier claims whose supporting evidence repeatedly lands in BANDED replay drift (TG-RP §5) are escalated with priority.

4.3. Population Drift Monitoring​

Score distributions per tenant are snapshotted (comp.AII.INPUT.SCORE-DISTRIBUTION.v1_0) at a governed cadence. Drift analysis distinguishes:

  • Expected drift — distribution shifts aligned with weight-bundle changepoints (the migration matrix from §2.2 predicts these).
  • Unexplained drift — shifts without a bundle changepoint, which are either genuine population improvement (good) or learned gaming (bad); the bunching and modifier detectors disambiguate.

4.4. Structural Countermeasures (governed options)​

Available to the calibration authority, all as FAGF bundle options:

  • Threshold banding: the auto-accept boundary is drawn per-claim from a narrow governed band (e.g., 0.90 ± 0.01) rather than a fixed point, making the exact target unlearnable while keeping decisions deterministic and replayable (the drawn value is recorded in the replay manifest).
  • Modifier caps: total dynamic-modifier contribution capped by a governed Weight Bundle value so no evidence-shopping strategy substitutes for dimension quality.
  • Cohort-relative review sampling: a governed percentage of auto-accepts from bunching-flagged cohorts is silently routed to human review.

5. Normative Rules​

  1. Weights, thresholds, modifiers, and ε values SHALL exist only inside versioned, DAL-anchored weight bundles. Hardcoded scoring parameters are a docs-lint / code-review ERROR.
  2. Bundle activation SHALL require impact simulation output and a named human approval, both TG-AUDIT-recorded.
  3. Submitter-facing surfaces SHALL NOT display numeric thresholds or modifier values unless the tenant's FAGF policy explicitly enables it.
  4. TG-OBSERVE SHALL compute bunching statistics for every governed threshold; a threshold without a bunching monitor is a deployment ERROR.
  5. Bunching and modifier alerts SHALL create investigation tasks; they SHALL NOT automatically penalize a submitter's score. Detection is telemetry; consequence is governance.
  6. Threshold banding, where enabled, SHALL record the drawn boundary in the replay manifest so decisions remain EXACT-replayable (TG-RP §3.1).

6. New CSIs Introduced​

CSIDirectionPurpose
comp.FAGF.OUTPUT.WEIGHT-BUNDLE.v1_0OutputVersioned scoring parameters, DAL-anchored
comp.AII.INPUT.SCORE-DISTRIBUTION.v1_0Output → AIIPopulation score snapshots per tenant/cohort
comp.TG.EVENT.BUNCHING-ALERT.v1_0EventExcess mass above a governed threshold
comp.TG.EVENT.MODIFIER-ANOMALY.v1_0EventModifier attach-rate anomaly near thresholds

7. ZRR Ruleset Entry​

ruleset: ZRR-TG-SCORE-001
invariant: scoring-parameters-are-governed-artifacts
scope: all scoring, routing, and modifier logic
enforcement: docs-lint DL-105 (ERROR) + code review checklist + runtime
  assertion that POLICY-CONTEXT is the sole weight source

The Goodhart problem is never solved; it is managed. This specification turns it from a latent surprise into governed telemetry with named owners. Source of truth: Docusaurus.



GitHub RepoRequest for Change (RFC)