SENTINEL SIGNAL

Sentinel Signal

MCP Verify 1.0.629 trust-surface coherence

Source: docs/mcp-verify-v1.0.629-trust-surface-coherence.md

All documents Docs Home Home

Document Content

MCP Verify 1.0.629 trust-surface coherence

Date: 2026-08-14

Architecture

Verify now separates evidence identity from trust evaluation and response materialization:

Postgres evidence revision
  -> revision-keyed evidence/detail materialization
  -> request-time canonical trust evaluation
  -> HTML and machine-readable presenters

The server detail route no longer caches final HTML. Each request resolves the current validation revision, re-evaluates clock-dependent trust fields, and renders the page. The underlying detail cache is keyed by the latest validation ID, server fingerprint, build/trust version, and narrative hydration variant. Read and write keys use the same revision.

If current evidence cannot be loaded, the HTML route returns 503 with no-store headers instead of presenting an older judgment as current.

Public trust contract

  • snapshot_id remains evidence-lineage identity.
  • trust_evaluated_at records when clock-dependent trust was evaluated.
  • evidence_revision identifies the concrete cached evidence inputs.
  • materialization distinguishes complete and partial deep detail while

    • stating that the canonical trust core is complete.

  • active_alert_summary.high_or_critical is derived only from active alerts.
  • evidence_confidence.basis publishes evidence-bearing validation depth,

    • affirmative check count, evidence age, and the configured freshness window.

Partial report, policy, compare, and trust-summary responses synchronously overlay the canonical trust core. No numeric confidence placeholder is used. Dynamic trust routes no longer emit path/build-only ETags.

Responses expose X-MCP-Verify-Snapshot-ID, X-MCP-Verify-Trust-Evaluated-At, and X-MCP-Verify-Materialization-State. /version exposes non-secret runtime cache and trust-calculation settings plus process identity.

Presentation semantics

Technical compatibility, client readiness, and publishability policy are rendered as three separate questions. Publishability uses Policy ready, Review required, or Policy blocked; only the technical profile uses Technically compatible language.

Provenance divergence uses verify.provenance_divergence.v2. An unassessed probe has null comparison outcomes and a neutral explanation; the registry vs server-card comparison table is omitted. Independently evaluated alias or listing provenance remains separate.

Public freshness is still a 24-hour judgment. Scores retain the existing 30-day display window, now labeled explicitly as such.

Operations

scripts/verify_trust_surface_coherence.py compares the detail page, trust-summary, report, policy, and compact compare trust core. Deployment runs it twice for cold/warm behavior. IONOS installs a five-minute systemd timer for the same synthetic; failures are non-zero service runs retained in journald. The comparison treats request-current age as time-relative rather than exact cross-request identity, and validates each surface's age/freshness relationship independently.

No database migration or scoring-threshold change is included.