No Separate Interview Event Log

Decision

The app will not add a structured interview-event log table (e.g. interviewEvents recording interview.ask, interview.answer, interview.defer, interview.branch).

Both app and local workflows persist current extracted state; the app also relies on the Agent transcript for conversation history.

Context

The local skill is filesystem-based. It has no database and should stay easy to inspect and edit by hand, so current state lives in document_input/: module values, status, edited_at, and optional status_reason.

The app gets the same coverage from two existing surfaces:

• Live moduleVersions rows (convex/schema.ts) — the live head stores extracted data, interviewStatus, optional statusReason, editedAt, and createdBy. This records the current outcome and when it last changed.
• Convex Agent messages (Messages Schema) — the full conversational transcript per thread reconstructs what was said around each change.

Why not add the log anyway

A structured event log would mostly duplicate what current module state and the transcript already capture. Specifically:

• Current outcome ("what changed most recently") — covered by moduleVersions.editedAt and createdBy.
• Resume ("where was the user up to") — covered by saved data, interviewStatus, statusReason, and the Agent thread.
• Replay of the conversation — covered by Agent messages.

The only product questions a dedicated event log would answer better than the existing surfaces are:

• Defer/decline analytics across users ("which fields get deferred most?"). The Agent thread holds conversational context, not a structured analytics surface.
• Branch decisions that leave no data trace (e.g. "no backup executor" — the field is simply absent in moduleVersions, recoverable from the transcript but not queryable).

Until one of those questions is load-bearing for the product, the cost of a third write path on every interview turn is not justified.

Revisit when

• A product surface needs queryable defer/decline analytics that the Agent thread cannot answer.
• A compliance or audit requirement needs structured (non-transcript) interview events.
• Branch-decision history becomes a first-class product concept rather than a reconstruction.

If any of those land, model the new table on authEvents — append-only, typed eventType, metadata blob, indexed by the relevant scope keys.

The second condition landed on 2026-07-31 and took this prescription literally — see The Turn Audit Log Is a First-Party Table. The first and third remain open.