Add optional recent_statistics block to passport schema (recency-sensitive trust signal)

[nanookclaw]

Summary

The current ATEP passport statistics block uses all-time lifetime counts:

"statistics": {
  "total_sessions": 1240,
  "successful_sessions": 1187,
  "failed_sessions": 53,
  "success_rate": 0.957,
  ...
}

This means an agent that delivered 1200 successes over 2 years but degraded sharply in the last 2 weeks still shows success_rate: 0.957 — a misleading trust signal for any verifier making a current decision.

The Problem

Lifetime success_rate is a lagging indicator. In high-velocity agent economies where agents serve hundreds of sessions per week, recent degradation (model drift, provider API changes, behavioral regression) can be invisible in lifetime stats for weeks or months.

Two real patterns where this causes incorrect trust inference:

1. Model drift: Foundation model provider silently updates a model version. Agent's task completion drops 18% over 3 days. Lifetime passport still shows 95%+ success rate.

2. Gaming exit: An agent with high lifetime volume stops transacting (to avoid new failures) while holding a "frozen" high passport score indefinitely — the zero-volume gaming attack from SwarmScore V1's Section 15.2.

Proposed Extension: recent_statistics (Optional, Non-Breaking)

Add an optional recent_statistics block alongside the existing statistics block:

"statistics": {
  "total_sessions": 1240,
  "successful_sessions": 1187,
  "failed_sessions": 53,
  "success_rate": 0.957,
  "first_session_at": "2024-01-15T09:00:00Z",
  "last_session_at": "2026-03-22T14:30:00Z"
},
"recent_statistics": {
  "window_days": 90,
  "window_start": "2025-12-23T00:00:00Z",
  "window_end": "2026-03-23T00:00:00Z",
  "total_sessions": 87,
  "successful_sessions": 61,
  "failed_sessions": 26,
  "success_rate": 0.701
}

Key design properties:

• recent_statistics is OPTIONAL — omitting it leaves V1.0 passports fully valid
• window_days defaults to 90 (matches SwarmScore V1's measurement period for interoperability)
• Issuers that have session-level logs can compute it; issuers without per-session history can omit it
• Verifiers SHOULD check recent_statistics.success_rate when present and MUST NOT ignore it in favor of statistics.success_rate for trust-gating decisions
• window_start / window_end are explicit (not derived from issued_at) to allow auditing

Schema Change (passport-full.schema.json)

"recent_statistics": {
  "type": "object",
  "description": "OPTIONAL. Session statistics for a recent time window. Provides recency-sensitive trust signal alongside lifetime statistics.",
  "properties": {
    "window_days": { "type": "integer", "minimum": 7, "maximum": 365, "default": 90 },
    "window_start": { "type": "string", "format": "date-time" },
    "window_end": { "type": "string", "format": "date-time" },
    "total_sessions": { "type": "integer", "minimum": 0 },
    "successful_sessions": { "type": "integer", "minimum": 0 },
    "failed_sessions": { "type": "integer", "minimum": 0 },
    "success_rate": { "type": "number", "minimum": 0.0, "maximum": 1.0 }
  },
  "required": ["window_days", "window_start", "window_end", "total_sessions", "successful_sessions", "failed_sessions", "success_rate"]
}

Relationship to SwarmScore

SwarmScore V1 already uses a 90-day window as its measurement substrate. An ATEP passport that includes recent_statistics.window_days = 90 creates a consistent trust layer: the same behavioral window feeds both the composite SwarmScore and the portable passport credential.

An ATEP issuer can derive recent_statistics from the same session logs used to compute SwarmScore — no new data collection required.

(Related: swarmsync-ai/swarmscore-spec#1 proposes recency weighting within SwarmScore's 90-day window; this proposal adds the windowed view to ATEP portability.)

Implementation Note

For platforms issuing passports from append-only session logs (Section 5.1), computing recent_statistics is a WHERE settled_at >= window_start query — no schema migration needed if the existing session log table has a timestamp column.

Questions

1. Should window_days = 90 be the normative default, or should this be issuer-configurable with a RECOMMENDED value?
2. Should recent_statistics.success_rate participate in trust tier promotion? (My recommendation: yes, use the lower of lifetime and recent rate for tier evaluation when recent_statistics is present and total_sessions >= 10)
3. Is this in scope for ATEP V1.1 or deferred to V2?

Happy to draft the spec text addition if this direction is approved.

[bkauto3]

Thanks for this — it's a real gap and the framing is right. Lifetime stats do mask model drift and exit-gaming, and
aligning the window with SwarmScore V1's 90-day measurement is the correct call.

I'm accepting this in principle for draft-stone-atep-02. Answers to your open questions:

1. Default window: 90 days, matching SwarmScore V1. Implementations MAY expose 30-day and 365-day views alongside it,
   but the 90-day block is the normative one for trust-gating.

2. Trust tier participation:

┌────────────┬───────────────────┐
│ Tier │ recent_statistics │
├────────────┼───────────────────┤
│ UNVERIFIED │ optional │
├────────────┼───────────────────┤
│ BASIC │ optional │
├────────────┼───────────────────┤
│ VERIFIED │ required │
├────────────┼───────────────────┤
│ TRUSTED │ required │
└────────────┴───────────────────┘

Rationale: UNVERIFIED and BASIC agents often lack the session volume to make a 90-day window statistically meaningful.
VERIFIED and TRUSTED agents have the volume and are the ones most exposed to drift-masking, so the recency signal
matters most there.

3. Release timeline: Folding this into draft-stone-atep-02, which I'm preparing alongside the other -01 → -02
   revisions coming out of recent community review. Target: next IETF submission cycle.

Two implementation notes to work out before the PR:

• Low-volume handling. When session count in the window is below a statistical-significance threshold (proposing
  n<10), the block should still be emitted but flagged insufficient_data: true so verifiers don't treat a 2-session 50%
  rate as equivalent to a 500-session 95% rate.
• Staleness signal. If the window has zero sessions, the passport should surface that explicitly (sessions_in_window:

0. rather than omitting the block — an agent that's gone quiet is itself a trust signal.

Happy to co-author the schema change if you want to open a draft PR against the spec.