Lab Objective

Create a strict status-receipt contract that records current task metadata without importing conversation content, rejects stale or malformed data, and never turns a status record into a completion claim.

Lab Environment

  • Environment: local JSON receipt, schema validator, and temporary ledger
  • Allowed fields: stable task ID, normalized state, timestamp, and project/workspace identifiers
  • Forbidden fields: previews, summaries, bodies, transcript paths, and raw session exports
  • Freshness limit: forty-eight hours for a current-state claim

Scenario

A daily brief needs to show what is currently active. Importing full task conversations would create an unnecessary privacy boundary and would make a short operational digest dependent on content it does not need.

Step 1 - Define the Allowlist

Write the accepted receipt schema before importing a producer. Reject unknown fields rather than silently storing them. Include a source timestamp and a stable adapter name so the origin of the observation remains visible.

Step 2 - Validate Good and Bad Fixtures

Test a valid metadata-only receipt, then reject fixtures containing a preview, summary, transcript path, duplicate task, malformed timestamp, or unsupported state. A filter that removes forbidden fields after persistence is too late for this boundary.

Step 3 - Enforce Freshness

At render time, compare the source timestamp with the current time. A receipt older than forty-eight hours must be labelled stale and excluded from current-state decisions. A fresh receipt is still only an observation.

Step 4 - Separate Status From Completion

Render wording such as “observed active” or “last status received.” Do not render “completed” unless a separate completion artifact proves the project outcome. A task title, state, or historical verdict is not enough.

Step 5 - Verify No Duplicate Delivery

Render a no-send preview and confirm that the ledger updates without sending the same daily report twice. Record the delivery mode in test metadata, not in the user-facing content.

Security Takeaways

  1. Data minimization should happen at the source contract.
  2. Freshness is part of the meaning of a status record.
  3. Current status and historical context are different evidence classes.
  4. Status is not completion.
  5. Preview and no-delivery modes are useful safety controls for scheduled reports.

Where This Applies Beyond the Lab

This pattern fits SOC dashboards, incident queues, deployment monitors, backup reports, and compliance evidence. Keep the record small enough that its privacy and truth conditions are easy to explain.