Detection event indexing: define the record before searching it

1. Distinguish a detection from an event

A detector proposes a class and bounding region in an image. DETR formulates detection as set prediction, but its output does not by itself establish an event duration, a relationship or a searchable business record. First document what each observation represents, which source frame produced it and what information remains unavailable. Model confidence is not automatically a probability that the entire event description is correct.

An event is an application-defined grouping of observations with explicit rules. A person carrying a box may span many frames, include an occlusion and end when the relationship is no longer supported. Describe how gaps, start and end boundaries, and contradictory observations are handled. Do not convert every similar frame into a separate event or merge unrelated appearances simply because their embeddings are close.

2. Preserve values, provenance and unknown states

Give every event a stable event identifier, camera or source identifier, evidence references and schema version. Store observations separately enough to reconstruct why an attribute or relationship was proposed. A red shirt should refer to the relevant person region; a holding relation should name the person observation and the same box observation. Co-occurrence in a scene is weaker evidence and needs a different state.

Missing, invalid and zero are different values. An unreadable numerical measurement can have a null value and an invalid status; a valid zero needs its own status, unit and provenance. Likewise, an unseen box is not necessarily an absent box. Use explicit supported, contradicted and unknown states instead of treating every unfilled attribute as false. Validate types, units, allowed statuses and reference integrity when records enter the index.

{
  "event_id": "evt-0042",
  "camera_id": "cam-03",
  "source_time": "2026-10-30T13:02:10+07:00",
  "ingested_at": "2026-10-30T06:02:18Z",
  "track_scope": "cam-03/segment-017",
  "track_id": "track-12",
  "measurement": {"value": null, "status": "invalid", "unit": "count"},
  "relation": {"subject": "obs-person-1", "type": "holding", "object": "obs-box-2", "state": "unknown"},
  "schema_version": "1",
  "model_version": "detector-example-v1"
}

3. Keep source clocks and track scope explicit

Store source capture time separately from ingestion time. A delayed upload should not appear to have happened when it reached the server. Preserve timezone or offset, clock-quality information and any correction provenance; normalized timestamps can aid comparisons without erasing the original clock context. An approximate search around 13:00 still needs a confirmed date, timezone and window. Index design must not silently supply those missing choices.

ByteTrack illustrates associating detections over video, including useful lower-score observations. A track identifier is local to a bounded camera or sequence scope, not proof of personal identity. Restarts, occlusion and crossings can fragment or switch associations. Record the scope and association uncertainty, and retain source evidence for review. Do not turn a track number into a cross-camera identity or infer protected traits from apparent presentation.

4. Make delayed arrivals and reprocessing predictable

Late footage can add observations to an earlier time range and alter an event boundary. Keep a coverage record that distinguishes expected, received, processed and searchable intervals. A watermark can summarize processing progress, but should not conceal known gaps. When a query overlaps incomplete coverage, the search layer needs that state rather than an apparently definitive empty result.

Deduplication should use documented source identifiers, frame or segment references and processing lineage, not just a guessed timestamp or visual similarity. Repeated delivery of the same input should not multiply events. Reprocessing with a new model may legitimately produce different boundaries; preserve the relationship between revisions and define which version is active. Avoid silently mixing old attributes with new vectors that describe different evidence.

• Validate the schema before accepting an observation; quarantine malformed records without inventing substitute values.
• Use a stable source key and revision rule for idempotent ingestion, then inspect collisions rather than discarding them blindly.
• Version detector, tracker, preprocessing and embedding generation so changes can be traced to their evidence.
• Record searchable coverage and late updates so consumers can distinguish an absent match from unfinished indexing.

5. Separate retrieval aids from authority

Structured indexes can support exact camera, time and numerical-value constraints, while vector indexes help rank semantic similarity. These structures are retrieval aids, not independent sources of truth. Store stable links back to authorized evidence and preserve the status of each field. An embedding cannot certify that all requested attributes belong to one person or that the person holds the specified box.

Permissions must restrict the candidate universe before retrieval and candidate ranking, not merely hide unauthorized results afterward. Playback needs a fresh check because rights can change between search and viewing. Treat user text, OCR and generated descriptions as untrusted data. Query execution should use schema-validated, allowlisted, parameterized read-only operations; neither stored descriptions nor generated SQL should acquire authority to alter access rules.

6. Maintain a consistent lifecycle across copies

Expiry and deletion involve source media, event records, structured indexes, embeddings and caches. Define how derived copies become unavailable together, how queued reprocessing avoids recreating deleted material, and how failed cleanup is detected. A stale vector pointing at expired evidence should not remain a normal candidate. Lifecycle design also needs to address cached snippets and result pages, not only the primary media store.

For an authorized review, record the active schema and model versions, query constraints and evidence revision without retaining unnecessary personal data. Reproduce failures against the appropriate version rather than assuming the latest index represents the earlier search. This article describes engineering principles relevant to the planned AIFacon Detection direction; it does not claim an implemented schema, deployment guarantee or certified event-search accuracy.