Skip to content

PLAN — P14d Mastra Score Receipt Trust Basis Readiness Freeze (Q2 2026)

  • Date: 2026-05-02
  • Owner: Evidence / Trust Compiler
  • Status: Execution freeze slice
  • Scope: Freeze the semantic boundary for Mastra ScoreEvent receipts before any score-derived signal becomes Trust Basis claim-visible. This does not add a claim, Trust Card row, Harness recipe, or Mastra integration surface.

1. Why this exists

P14c made the Mastra ScoreEvent receipt lane operational:

bounded Mastra ScoreEvent JSONL
  -> assay evidence import mastra-score-event
  -> verifiable Assay receipt bundle
  -> assay trust-basis generate

That proves the import layer works. It does not prove that score receipts are ready to carry Trust Basis meaning.

The open question after P14c is therefore not:

Can Assay import Mastra score receipts?

The open question is:

What Trust Basis meaning may a score receipt ever carry?

P14d exists to keep that decision explicit before the score lane gains public claim weight.

2. Decision

assay.receipt.mastra.score_event.v1 remains importer-only for the current line.

The receipt is schema-covered, bundleable, verifiable, and readable by the Trust Basis path. It does not feed any current Trust Basis claim family:

  • not external_eval_receipt_boundary_visible
  • not external_decision_receipt_boundary_visible
  • not external_inventory_receipt_boundary_visible

The receipt family matrix must continue to record:

{
  "event_type": "assay.receipt.mastra.score_event.v1",
  "trust_basis_claim": null
}

This is the safe status until score-receipt claim semantics are deliberately accepted and tested in a later compatibility-expanding slice.

3. Non-goals

P14d does not add:

  • a new Trust Basis claim
  • a Trust Card row or schema bump
  • a Harness recipe
  • a Mastra runtime integration change
  • a receipt parsing or reducer-output change
  • a P14c importer behavior change
  • compatibility expansion for existing consumers

This slice is a semantic freeze, not hidden feature work.

4. Why not claim-visible now

Score receipts are tempting because the importer is real and Mastra maintainer guidance made the seam unusually strong:

  • ScoreEvent / onScoreEvent is the forward path for score export.
  • addScoreToTrace(...) is legacy / migration context.
  • scoreId has shipped and is now represented as bounded score_id_ref when naturally present.

That is enough for a receipt lane. It is not enough for a Trust Basis claim.

The word "score" is easy to overread as:

  • quality proof
  • safety proof
  • pass/fail proof
  • evaluator truth
  • scorer reliability
  • Mastra runtime truth
  • threshold or gate outcome

P14d keeps those meanings out of the claim table.

5. Current receipt meaning

Today, a valid Mastra score receipt means only:

a selected Mastra score-event outcome was reduced into a bounded, provenance-bearing evidence receipt

It does not mean:

  • the score is correct
  • the scorer is reliable
  • the target passed
  • the target is safe
  • the Mastra runtime behaved correctly
  • the trace or span anchor is complete
  • the score should pass or fail an Assay or Harness gate

6. Reserved future claim candidate

If this lane later becomes claim-visible, the likely candidate claim is:

external_score_receipt_boundary_visible

The name is reserved only in planning language. P14d does not add it to any registry, schema, enum, Trust Basis output, Trust Card output, CLI output, or Harness path.

The maximum acceptable v1 meaning for that claim is narrow:

the verified bundle contains at least one supported bounded external score receipt

For Mastra, the first supported event would be:

assay.receipt.mastra.score_event.v1

with the existing bounded receipt predicates from P14c:

  • exact event type
  • exact schema, source system, and source surface
  • reviewer-safe source artifact ref
  • digest-shaped source artifact binding
  • supported reducer version
  • UTC RFC3339 import timestamp
  • numeric score
  • bounded target reference
  • at least one bounded scorer identity
  • no raw metadata, correlation context, traces, spans, logs, metrics, feedback, prompts, request/response bodies, scorer configs, dashboard state, or legacy callback envelope

This claim, if ever added, is about receipt boundary visibility only. It is not about score quality, score interpretation, score thresholding, evaluator correctness, or target outcome.

Even then, the candidate claim must not say the score is correct, sufficient, safe, trusted, passed, or failed.

7. P14e readiness bar

A later P14e may add external_score_receipt_boundary_visible only if the compatibility cost is accepted deliberately.

Minimum readiness requirements:

  • exact claim id
  • exact Trust Basis source and boundary strings
  • exact supported event types
  • field-level predicate for valid supported score receipts
  • negative examples for what the claim does not mean
  • fixture where the claim becomes verified
  • fixture where malformed or wider score-like events remain absent
  • Trust Card schema impact and migration note
  • Harness decision: either a recipe is added intentionally, or Harness remains explicitly unchanged
  • consumer compatibility note for code that keys by claim.id

Until those are present, importer-only is the correct state.

8. Harness posture

Harness does not change in P14d.

Current Harness gate/report semantics consume assay.trust-basis.diff.v1 over the existing Trust Basis claim set. Since Mastra score receipts remain trust_basis_claim: null, there is no Harness recipe, report field, JUnit projection, or baseline/candidate comparison rule to add.

If P14e later adds a score receipt claim, Harness can be considered after the Trust Basis and Trust Card compatibility decision is already made. Harness should compare compiled Assay artifacts; it should not learn Mastra ScoreEvent payload semantics directly.

Existing Harness fixtures, report snapshots, JUnit projections, and diff outputs remain unchanged after P14d.

9. Artifacts touched

Expected P14d artifacts:

  • this architecture freeze note
  • P14c backreference to the freeze decision
  • architecture index, queue note, roadmap, CLI docs, and changelog alignment
  • receipt family matrix remains trust_basis_claim: null for Mastra score receipts, with an explanatory claim-readiness plan pointer
  • a matrix/registry test proving Mastra score receipts remain importer-only

No Assay Harness files are touched in this slice.

10. Acceptance criteria

P14d is complete when:

  • docs state that assay.receipt.mastra.score_event.v1 remains importer-only
  • the receipt family matrix still has trust_basis_claim: null for Mastra score receipts
  • a verification test asserts that the Mastra matrix entry remains claim-null
  • a verification test asserts that Mastra ScoreEvent receipts cannot emit any current eval, decision, or inventory Trust Basis claim
  • the P14c test posture remains true: Mastra score receipts do not mutate eval, decision, or inventory receipt claims
  • the possible future claim external_score_receipt_boundary_visible is named only as a future planning candidate, not registered in code or schema
  • P14e readiness requirements are recorded before any claim-visible work starts
  • Harness is explicitly recorded as unchanged for this freeze slice
  • Harness fixtures, snapshots, reports, and projections remain unchanged
  • release notes call this a semantic freeze, not feature expansion

11. Outward posture

No new Mastra comment is needed for P14d.

The Mastra thread already established the important seam:

  • ScoreEvent / onScoreEvent is the forward path
  • addScoreToTrace(...) is legacy context
  • scoreId has shipped

P14d is internal product semantics. It should not be framed as upstream support, an integration claim, or a request for new Mastra behavior.

12. References