Record one (entry, code, segment) assignment to the live tracker
Source:R/live_tracking.R
live_record_assignment.RdAppends a JSONL line to code_assignments.jsonl. Safe to call with
tracker = NULL (no-op).
Usage
live_record_assignment(
tracker,
entry_id,
code_key,
code_name,
segment,
is_new_code = FALSE,
entry_index = NA_integer_
)Arguments
- tracker
A
LiveTrackeror NULL- entry_id
Character entry id (std_id)
- code_key
Codebook key (sanitized id)
- code_name
Human-readable code name
- segment
List with
text,start_char,end_char- is_new_code
Logical; whether this assignment created the code
- entry_index
Integer position of the entry in the input (for ordering)
Details
schema relationship to the audit log.
code_assignment events live in TWO places by design:
outputs/<run>/live/code_assignments.jsonl(this writer): append-only EVENT log. One JSONL line per (entry_id, code_key, segment) triple. Carries text + offsets + verification_status inline so a researcher cantail -Fthe file mid-run.outputs/<run>/ai_decisions.jsonl(R/audit_log.R): append-only DECISION log. One JSONL line per audit event;step = "coding"+decision_type = "code_assignment"records the same logical event. Carries methodology stamp + AI metadata (model, request_id, methodology_mode) but NOT segment text or offsets.
The two are joined by (entry_id, code_key). The split is
intentional: the audit log is the methodology-of-record (provenance,
AC9 stamping, replay) while the live tracker is the researcher's
real-time view (text + offsets + verification status for
tail -F). An earlier docstring was silent on
this; downstream consumers had to infer the join from the field
names. Now documented.