# AEGIS — Operational Trust Metrics (Trust Score)

- **Document ID:** ARCH-52
- **Phase:** E.3 — Adversarial/Defensive Teams
- **Status:** Draft for review (post four-reviewer discipline)
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect

---

## 1. Purpose

Codify the **Trust Score** exposed by every subsystem, derived from measurable inputs. Implements Phase-E.3 mandates #6 (Measurable Trust) and #7 (7-dimension Trust Score). Trust is measurable; trust is earned by evidence.

## 2. Trust Score Composition

The Trust Score is a 0–100 value composed from seven dimensions with published weights (weight catalog governed like Risk weights, per ARCH-11 §8):

| Dimension | Signals |
|---|---|
| **Integrity** | RIV state, integrity beacon freshness, signing key freshness |
| **Verification** | Verification Matrix coverage + evidence freshness + property/regression test currency |
| **Health** | SLO compliance, error/failure rate, resource pressure |
| **Operational History** | Recent incident rate, drill pass rate, ceremony cadence adherence |
| **Recovery Status** | Backup success rate, recent Recovery Integrity Attestations, air-gap copy freshness |
| **Threat Activity** | Recent red-team findings, threat-simulation results, live adversary signals |
| **Configuration Drift** | Consistency-checker deltas, DriftMonitor deltas, ARCH-* freshness |

## 3. Aggregation

- Per-subsystem `TrustScore_subsystem = weighted_sum(dimensions)`.
- Platform-wide `TrustScore_platform` = weighted composition across subsystems (weights per subsystem criticality, ARCH-27).
- Weights signed; changes ceremony-controlled.

## 4. Interpretation

- **90–100** — high trust; standard operations.
- **75–89** — attention; investigate anomaly.
- **50–74** — reduced trust; conservative posture (raise Approval requirements; may downgrade classification ceilings).
- **< 50** — degraded; incident-level; some operations suspended.

Trust Score is one input to policy decisions (ARCH-11); it does not by itself gate operations but shapes ceilings and approval requirements.

## 5. Reporting

- **Dashboard** per subsystem + platform-wide.
- **Weekly** ops review shows trend.
- **Monthly** council review shows platform score.
- **Public communication** — never publish exact score; publish "trust posture" descriptor after policy review.

## 6. Adversarial Considerations

- Trust Score is not tamper-resistant if any single dimension is compromised — cross-substrate reconciliation and watchdog quorum apply.
- Weights are governed like Risk weights; changes ceremony-controlled.

## 7. Assumption (hypothesis)

- **H-1.** *Trust Score correlates with actual defensive posture within ±10 points.*
   - Evidence: baseline vs. red-team engagements.
   - Validation: post-incident retrospective compares pre-incident score.
   - Confidence: Medium; tune with data.
   - Expiration: annually.
   - Review Date: quarterly.

## 8. Security-Control 8-Field Spec (mandate #2, applied to Trust Score)

- **Purpose.** Quantify + surface trust posture; input to policy + Adaptive Trust.
- **Threats Addressed.** Silent drift, hidden compromise, quiet degradation.
- **Residual Risk.** Score gaming, weight-catalog compromise.
- **Verification Method.** Cross-substrate reconciliation; auditor sample.
- **Operational Cost.** Aggregation + dashboarding.
- **Failure Mode.** Score becomes noisy; loses signal.
- **Recovery Method.** Weight-catalog rollback; noise-tuning.
- **Removal Criteria.** If replaced by a superior measure — no plan; permanent.

## 9. Independent Architecture Review

- **F-1.** *Score conflation with reality.* Documented as "signal not truth"; multiple signals feed decisions.
- **F-2.** *Dashboard fatigue.* Trend-focused; anomaly-triggered.

## 10. Adversarial Architect Review

- **A-1.** *Attacker manipulates one dimension.* Multi-dimension aggregation; watchdog cross-verify.
- **A-2.** *Insider tunes weights.* Ceremony-controlled; auditor.
- **A-3.** *Attacker fabricates evidence to inflate Verification dimension.* Signed evidence per ARCH-43; forgery detected.

## 11. Operational Reliability Review

- **O-1.** Aggregation cheap; bounded cardinality.
- **O-2.** Historical scores retained (baselines).

## 12. Self-Critique

- **S-1.** *Weights are opinionated.* Documented + auditor visibility.
- **S-2.** *Dimensions overlap.* Accepted — over-coverage safer than under.

## 13. First-Target Analysis and Redesign

**Target:** the weight catalog. Same as Risk Engine weights (ARCH-11 §8) — a small change alters all downstream. Response: ceremony-controlled + dual-store signed + drift monitor + rollback pin.

## 14. Future Risks / Known Limitations / Out-of-Scope / Retirement

- **Future Risks.** As new signals emerge (e.g., ML-driven detectors), Trust Score composition may need extension.
- **Known Limitations.** Score is one input; policy remains authoritative for decisions.
- **Out-of-Scope.** Public per-tenant score comparison (privacy).
- **Retirement Conditions.** Never — trust measurement is permanent.

## 15. Decisions

### D-52-1. Seven-dimension Trust Score with governed weight catalog

- **Reason.** Mandate #7.

### D-52-2. Trust Score influences policy ceilings but does not gate operations by itself

- **Reason.** Human Authority + Policy Engine remains authoritative.

## 16. Change Log

- **0.1 (2026-07-10)** — Initial draft.