Trust Methodology

Quick Math Reference

One-page, no-prose math card. Every number on every Evidence card and plaque is produced by these formulas and these formulas alone. If a row's math doesn't match, the row is wrong — not the math.

1 · Per-row score (every Evidence row)

This is what the MAG bar on every Evidence card displays (pre-plateau approximation — the plateau factor is applied only when summing).

2 · Skill aggregate (Trust Magnitude)

3 · Per-row Grade (S / A / B / C)

Floors are calibrated per type so an S row corresponds to top-tier evidence in that type's natural distribution. Ceilings prevent self-producible types (repo-own, self-attestation) from ever reaching S alone.

4 · Overall Skill Grade

5 · The 10 evidence types — base formula at a glance

6 · Worked numbers from real 5★ skills

These match scripts/inspectTrustMagnitude.py exactly. If a frontend card disagrees, the frontend is wrong — file an issue, do not edit data.

If you change a formula, you must update — in this exact order: docs/js/tm-config.js (frontend SoT) → src/gaia_cli/trustMagnitude.py (backend) → this page → registry/schema/meta.json (perRowGradeThresholds, gradeCeiling) → tests/test_row_grading.py + tests/test_calibrate_evidence_grades.py → python scripts/build_docs.py. Then run gaia dev calibrate-evidence-grades --yes to refresh stored grades.

Trust Magnitude Formula

Trust Magnitude (TM) is the aggregate numeric signal for a skill's trustworthiness. It is computed at build time from a skill's evidence inventory, never stored on a node.

The three sub-functions are type-specific and documented in full in the Evidence Types table below. Key invariants:

• Plateau: successive rows of the same type yield diminishing returns via a plateau multiplier sequence (e.g. 1.0 / 0.5 / 0.25).
• Cap: a hard ceiling per row after the magnitude function is applied, before the weight multiplier.
• Freshness: some types decay over time (e.g. benchmark-result at 50 % / year); others are time-invariant.
• Dedup: duplicate URL rows are collapsed to a single entry before any scoring begins.
• Role guard: certain types are only valid for specific skill roles (e.g. fusion-recipe only scores when role='origin').

Evidence Types

Ten canonical Evidence Types, each measuring a distinct provenance signal. Weights and caps set the raw contribution ceiling; plateau limits how many rows of the same type can stack.

N counts only role='origin' components graded ≥C. A 20-origin skill scores 200 + 20×√10 ≈ 263 × 1.5; a 10-origin skill scores 200 × 1.5 = 300. The sqrt-softening prevents pathological 35-component fusions from running away with the leaderboard.

Evidence Inheritance — Generic and Named Layers

Every evidence row carries a layer designation — generic or named — that governs whether it can cross the generic→named boundary when computing Trust Magnitude for a Named Skill.

Layer Model

Layer is a property of an evidence row, not of the evidence type. Named Skills — those with a genericSkillRef pointing to a parent generic skill — can inherit generic-layer rows from that parent. Generic skills (no genericSkillRef) compute Trust Magnitude from their own rows only and the inheritance path is never traversed.

Effective Pool

A Named Skill’s Trust Magnitude is computed over its effective pool: the union of its own rows and all generic-layer rows inherited from the parent generic skill, deduped by source URL. Own-layer rows always receive an inheritMultiplier of 1.0 — no discount is applied. Inherited rows receive the per-type discount documented in the table below.

allowedLayers per Type

Each evidence type declares which layers it may sit at and what discount applies when a row is inherited across the generic→named boundary. Types pinned to [named] only cannot be inherited.

Pinned to named layer — cannot be inherited

Flexible — can sit at either layer; discount applied when inherited

Rationale

The discount reflects that a capability claim (for example, an arxiv paper describing a generic algorithm) projects less cleanly onto a specific named implementation. A lower multiplier signals that the evidence type binds less tightly to individual Named Skills. benchmark-result carries the lowest multiplier (0.15) because it already carries a high artifact weight (1.4) in the scoring formula — allowing full inheritance would disproportionately amplify benchmark rows that were published against the generic capability rather than the specific named implementation.

Overall Trust Grade Thresholds

The Overall Trust Grade is derived from a skill's Trust Magnitude and a diversity gate. It is computed at build time and surfaces in generated catalogs — never stored on a node.

The diversity gate at S is the primary anti-gaming control at the highest grade. It ensures that a Platinum grade requires external validation — a skill cannot reach S through self-producible signals alone, regardless of how many stars are stacked.

Per-Evidence Row Grade Thresholds

Each evidence type has its own artifact_score floor for each grade. Grades above a type's ceiling are not achievable — the ceiling is a hard cap, not a rounding rule.

Floors are against artifact_score (magnitude × weight × freshness × multipliers). A "—" means that grade is not achievable for this type regardless of score.

Suite vs Fusion

Two orthogonal dimensions of skill composition that share an origin-count axis but serve entirely different purposes.

The Apex Gate

The Apex Gate is a 6-predicate hard gate that must be fully satisfied before a skill can ascend to the 6★ Transcendent ★ (Apex) rank. All six predicates must evaluate to true. Partial satisfaction is logged but does not advance promotion.

• aGradedOriginsGte5 At least 5 fusion-origin components (role='origin') each hold an Overall Trust Grade of A or higher. Pure suite variants do not count.
• directNestedSuiteGte1 At least 1 directly-nested suite (a child with its own suite components) exists among the role='origin' children. This is a graph-shape signal: true composition depth, not just a flat list of origins.
• depth2OnlyReachableGte1 At least 1 fusion-origin component is reachable only at depth-2 (i.e. accessible exclusively via a nested path, not via a top-level suite install). Suite-only reachability is excluded — installation breadth alone is not accepted as evidence of provenance depth.
• overallGradeS The skill's formula-computed Trust Magnitude places it at Overall Trust Grade S (TM ≥ 250 with diversity gate satisfied). The Apex Gate cannot be passed on a grade below S.
• sourceTenureDaysGte180AorS At least 1 evidence row graded A or S has a public source that has been continuously available for ≥ 180 days. Freshly-published evidence that immediately satisfies the TM threshold cannot trigger Apex promotion.
• apexPromotionPrSigned The promotion pull request is signed by the maintainer at promotion time. This is the sole human-attestation gate during the bootstrap period. When the ecosystem matures (cross-org cosigners present in the registry), this predicate is satisfied by a cosigner quorum instead.

Any predicate that fails produces a named diagnostic in the promotion candidate output. The failure is logged against the skill's timeline as a gate-fail event so the history is auditable.

Feature-flagged OFF — deferred to 2026-Q4

Two additional predicates exist in the implementation but are excluded from gate evaluation until ecosystem conditions justify them. They return None (skipped) rather than False (failed) so callers can distinguish "not yet active" from "failed":

• crossOrgVerifier (OFF) Requires ≥2 cosigning verifiers from distinct GitHub organisations. Disabled until the registry has enough active cross-org verifiers to make the requirement non-trivial. Re-enable at 2026-Q4 review.
• systemWideCap (OFF) Enforces a registry-wide cap on the number of active Apex skills (cap = 5). Disabled as a per-skill predicate; cap enforcement lives in CI (Phase 1.5 I4), not in the apexGateStatus object. Re-enable at 2026-Q4 review.

Removed predicates — 2026-06-17 amendments (historical context)

The following predicates existed in earlier drafts of the Apex Gate specification and were removed or consolidated in the 2026-06-17 amendments. They are recorded here for auditability — they are not active and must not be re-introduced:

• transitiveOriginsGte12 Required ≥12 transitively-reachable A-graded origin components. Consolidated into the more precise aGradedOriginsGte5 (direct origins, threshold lowered to 5) to eliminate double-counting via suite-component paths.
• aGradedClosureGte8 Required ≥8 A-graded skills in the transitive closure. Also consolidated into aGradedOriginsGte5; the two checks overlapped in practice.
• tenureDaysGte180 Checked source tenure on all evidence rows regardless of grade. Replaced by sourceTenureDaysGte180AorS which applies the tenure check only to A- or S-graded rows for precision.

Worked Example — mattpocock/skills

A concrete application of the Trust Magnitude formula and Apex Gate to an existing named skill. The table below shows a pre-G7-cutover synthesis projection — see the post-migration baseline callout for the actual registry values after I3 merged.

The table below uses the synthesis projection. Once 10-type evidence rows are ingested the registry will recompute TM automatically.

Apex Gate evaluation

• aGradedOriginsGte5 ✗ 4 role='origin' components graded A+ — requires 5. One short. The gate does not partially credit partial satisfaction.
• directNestedSuiteGte1 ✓ 1 directly-nested suite (TypeScript utility sub-suite) confirmed among origin children.
• depth2OnlyReachableGte1 ✗ 0 origins are reachable exclusively at depth-2. All origins are also accessible via top-level suite install paths, which are excluded from this predicate.
• overallGradeS ✓ Synthesis projection TM ≈ 1 187 ≫ threshold 250. Diversity gate passed (3 types, verifier-attestation present, 1 S-tier row). Overall Trust Grade S in the synthesis projection. Post-I3 registry grade is B (no 10-type evidence ingested yet — this predicate will re-evaluate as evidence is entered).
• sourceTenureDaysGte180AorS ✓ github-stars-own row (Grade S) — TypeScript repo is > 4 years old. Tenure well above 180-day floor.
• apexPromotionPrSigned ✗ No signed PR submitted for Apex promotion. This is intentional — the maintainer has not initiated the promotion flow.

Synthesis projection result: 3 / 6 predicates pass. Under the synthesis estimate, the skill holds Overall Trust Grade S and would satisfy three gate conditions immediately upon a valid promotion PR, but the structural gaps (aGradedOriginsGte5 and depth2OnlyReachableGte1) require genuine fusion-graph work — they cannot be satisfied by adding self-producible evidence rows or suite variants. Post-I3 registry baseline: TM 0.0 / grade B. All gate evaluations above will re-run automatically as 10-type evidence rows are ingested.

Gameability Vectors Closed

The trust model is designed with explicit closures against known inflation strategies. Five primary vectors are addressed by structural rules, not policy.

• variant-padding Registering many role='variant' sub-skills in a suite to inflate the fusion-recipe origin count. Blocked structurally: the fusion-recipe formula reads role='origin' exclusively; variant count has zero effect on TM.
• single-author origin inflation A contributor creating many thin named skills and fusing them to themselves to boost aGradedOriginsGte5. Each origin must independently hold grade A+, which requires external or non-self-producible evidence on each child. Self- attestation caps at flat 10 × 0.4 = 4 TM per skill — far below the A-grade threshold of 100 TM.
• phantom rows Adding fictitious or duplicate evidence URLs to stack TM. Blocked by the dedup rule (duplicate URLs collapse before scoring), the Verifier attestation model (a 4★+ Verifier must confirm disputed rows), and CI's schema validation.
• plateau-stacking Submitting many rows of the same high-weight type (e.g. dozens of verifier-attestation rows). Blocked by per-type plateau sequences and maximum row counts: verifier-attestation accepts at most 5 attestations with rapidly diminishing returns (1.0 / 0.85 / 0.7 / …).
• social-signal smurfing Creating many low-follower accounts to generate social-signal rows at full weight. Blocked by the per-row engagement cap (60), the total type cap (80), and the 3-row maximum with 1.0 / 0.5 / 0.25 plateau — the practical ceiling for all social evidence combined is 80 TM regardless of row count.

Further Reading

Related pages and canonical references for this methodology.