🔄 Topic

I worked on a local capture path that turns a message containing a future commitment into a calendar event. The security lesson was that extraction is not enough. A write needs evidence, deterministic date handling, an update rule, and a visible receipt.

🎯 Goal

Make automated event capture conservative: write only when the source supports the claim, keep the original phrase available for audit, resolve dates with code where possible, and tell the owner what changed.

🛠 What I Did

The capture flow runs on a short interval and examines eligible messages for a commitment. It separates the extracted fields from the source evidence. The event title and time must be tied to words that actually appeared in the message or to a clearly identified message being updated. A vague sentence must not become a confident appointment.

Relative dates were a useful failure test. A model once resolved a phrase such as “this Friday” to an incorrect past date. The safer design keeps the phrase, then lets deterministic application code resolve it using the message timestamp and timezone. The model can identify the phrase; it should not silently own calendar arithmetic.

The update path also had to be explicit. A later message can provide a time for an event already identified, but it must update the right event instead of creating a duplicate. The owner receives a notice for each successful write, and a failed notice is itself recorded as a failure because an invisible calendar mutation is difficult to trust.

The work used synthetic fixtures and owner-controlled checks for the security-sensitive cases. No private message body or real contact is part of this public write-up.

🔗 Key Cybersecurity Connections

This is data integrity at an automation boundary:

provenance makes the event explainable
deterministic resolution reduces model guesswork
idempotent updates reduce duplicate effects
owner receipts make a silent failure visible
least privilege limits what the capture job can write

🔍 Investigation Questions

Which exact source phrase produced this field?
Is the date relative, and who resolved it?
Is this a new event or an update to an existing one?
Can the same message be processed twice without duplicate writes?
Does a successful write always produce a visible receipt?

🚨 Detection Opportunities

Alert or quarantine records with missing source phrases, dates in the past when the source implies a future event, duplicate event identifiers, writes without a receipt, and updates that change more fields than the new message supports.

Example:

source_phrase_present=true
date_resolution=deterministic
event_operation=update
duplicate_key=stable
owner_receipt=recorded

🧭 MITRE ATT&CK Techniques

No direct ATT&CK mapping is claimed. The exercise is about protecting an authorized automation path from bad input and silent state changes.

🗺 Visual Investigation Diagram

Message fixture
    ↓
Extract candidate commitment
    ↓
Preserve source phrase
    ↓
Resolve date/time deterministically
    ↓
Create or idempotently update event
    ↓
Record owner receipt

⚠ Challenges

Natural language is full of implied dates, follow-ups, corrections, and incomplete times. A model can be helpful at finding a candidate, but its confident wording is not proof. The design has to make unsupported fields impossible or visible.

📚 What I Learned

Every automated write needs a chain from input to effect. The chain is stronger when the uncertain part is kept as evidence and the deterministic part is handled by code.

➡ Next Steps

Add more timezone and daylight-saving fixtures
Test retries at every write boundary
Keep stable identifiers for updates and deduplication
Verify that the owner receipt describes the actual stored state

🧠 Reflection

The feature became safer when I stopped asking “can the model extract an event?” and started asking “can I explain and reproduce every field that was written?” That is a cybersecurity question even when the destination is a calendar.

🧩 Lessons Learned

What worked

Keeping source evidence, deterministic date resolution, and the write receipt in the same workflow.

What could go wrong

Turning a vague phrase into a precise event, or accepting a successful API response without proving the stored state and notification.

Takeaway

Automation should be evidence-gated at the moment it changes durable state.

📈 Skill Progression Context

This connects my work on auditability, approvals, and recovery to data integrity. It is a practical example of how security controls protect not only secrets, but also the correctness of records.

😄 TL;DR

Before an automation writes a calendar event, it needs source evidence, deterministic date handling, duplicate protection, and a receipt.