π§ͺ Lab 30 β Letting Automation Add a Calendar Event Only When the Message Proves It
Lab Objective
Design a safe fixture-driven pipeline that extracts a future commitment from a message and writes a calendar event only when the source, date, time, and operation are supported by evidence.
Lab Environment
- Environment: local parser, deterministic date resolver, and fake calendar adapter
- Data: synthetic messages only
- Safety boundary: no real calendar, contact, or private message is used
- Evidence: source phrase, resolved fields, stable event key, operation, and receipt
Scenario
An automated job reads a message that may contain a commitment. A later message may supply a missing time or correct an existing event. The risks are false precision, duplicate writes, unsupported updates, and silent failures.
Step 1 - Preserve the Source Phrase
Require every extracted date, time, or title field to point back to text in the source fixture or to the specific message being updated. If there is no supporting phrase, keep the candidate pending instead of writing it.
Step 2 - Resolve Relative Dates in Code
Let the model identify a phrase such as βthis Friday,β but resolve it with deterministic code using the message timestamp and timezone. Include fixtures for week boundaries, daylight-saving changes, and phrases that resolve to a past date unexpectedly.
Step 3 - Separate Create and Update
Give each candidate a stable key. A later message that supplies a time should update the existing fixture event rather than create a second event. Test a retry of the same message and require exactly one durable event.
Step 4 - Require a Receipt
After the fake adapter accepts a write, record a receipt containing the event key, operation, changed fields, and source identifier. A failed receipt is a failed outcome even if the calendar adapter returned success.
Step 5 - Verify the Boundary
source_phrase_present=true
date_resolution=deterministic
stable_key=unchanged
duplicate_retry=one_event
receipt=present
Reject fixtures that omit evidence, invent a precise date, update an unrelated event, or complete without a receipt.
Security Takeaways
- Extraction is not authorization to write.
- Provenance makes durable state explainable.
- Deterministic date handling reduces model guesswork.
- Stable keys and idempotency prevent duplicate effects.
- A success response without a receipt is not delivery proof.
Where This Applies Beyond the Lab
The same controls apply to ticket creation, CRM updates, incident enrichment, expense processing, and any agent that turns natural language into durable records. Use a fixture and a fake adapter before connecting a real account.
