Implement the EventAnchor model and API #28

New issue

Open

opened 2026-07-28 04:57:28 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-07-28 04:57:28 +00:00

Context

EventAnchor is specified in the data model (spec section 8) but was not implemented in
Phase 1. It is user-supplied explicit date context â€” "Parents' wedding, June 1978" â€” and
the spec's evidence hierarchy ranks it High. The constraint propagation engine (#19)
needs anchors as inputs, so the model has to land in this milestone even though anchor
management UI is deferred to the admin panel in v0.4.0.

Scope

The EventAnchor model, migration, API, and the ability to associate photos with anchors.

Implementation notes

Fields per spec section 8: id, collection_id, label, date_low, date_high,
notes, created_by. Add a migration.
Anchors bound a range, not a point â€” a wedding is a day, a holiday might be a fortnight.
Keep date_low/date_high with an appropriate DatePrecision.
Associating a photo with an anchor produces DateEvidence with the anchor as source at
high reliability. Association is a reviewer act and must be auditable and reversible.
Editing an anchor's dates must invalidate and recompute constraints derived from it.
An anchor corrected from 1978 to 1979 that leaves stale derived dates behind is a silent
correctness bug affecting every photo in its range.
Basic CRUD API now; the management UI comes with the admin panel.
Deleting an anchor must not delete the evidence rows derived from it â€” supersede them,
consistent with the append-only rule.

Done when

EventAnchor model and migration exist per the spec
Photos can be associated with an anchor, producing high-reliability evidence
Editing anchor dates triggers recomputation of dependent constraints
Deleting an anchor supersedes rather than deletes derived evidence
CRUD API is covered by tests

References

docs/circa-spec.md section 8 (EventAnchor), evidence hierarchy table
backend/app/models/models.py

Blocks: #19 (constraint propagation). Related: the admin anchor management UI in v0.4.0.

## Context `EventAnchor` is specified in the data model (spec section 8) but was not implemented in Phase 1. It is user-supplied explicit date context â€” "Parents' wedding, June 1978" â€” and the spec's evidence hierarchy ranks it **High**. The constraint propagation engine (#19) needs anchors as inputs, so the model has to land in this milestone even though anchor management UI is deferred to the admin panel in v0.4.0. ## Scope The `EventAnchor` model, migration, API, and the ability to associate photos with anchors. ## Implementation notes - Fields per spec section 8: `id`, `collection_id`, `label`, `date_low`, `date_high`, `notes`, `created_by`. Add a migration. - Anchors bound a range, not a point â€” a wedding is a day, a holiday might be a fortnight. Keep `date_low`/`date_high` with an appropriate `DatePrecision`. - Associating a photo with an anchor produces `DateEvidence` with the anchor as source at high reliability. Association is a reviewer act and must be auditable and reversible. - Editing an anchor's dates must invalidate and recompute constraints derived from it. An anchor corrected from 1978 to 1979 that leaves stale derived dates behind is a silent correctness bug affecting every photo in its range. - Basic CRUD API now; the management UI comes with the admin panel. - Deleting an anchor must not delete the evidence rows derived from it â€” supersede them, consistent with the append-only rule. ## Done when - [ ] `EventAnchor` model and migration exist per the spec - [ ] Photos can be associated with an anchor, producing high-reliability evidence - [ ] Editing anchor dates triggers recomputation of dependent constraints - [ ] Deleting an anchor supersedes rather than deletes derived evidence - [ ] CRUD API is covered by tests ## References - `docs/circa-spec.md` section 8 (`EventAnchor`), evidence hierarchy table - `backend/app/models/models.py` Blocks: #19 (constraint propagation). Related: the admin anchor management UI in v0.4.0.

claude-bot added this to the v0.4.0 milestone

2026-07-28 04:57:28 +00:00

claude-bot added the

enhancement

backend

labels

2026-07-28 04:57:28 +00:00

claude-bot referenced this issue

2026-07-28 06:06:02 +00:00

Evidence schema cannot represent multi-parent provenance #108

claude-bot commented

2026-07-28 06:07:53 +00:00

Author

Amended by the audit of 2026-07-28.

EvidenceSource has no event_anchor member, despite the spec listing it (circa-spec.md:392).
Adding an enum member on SQLite means a table-rebuild migration, so it should go in the same
migration as the multi-parent provenance change — see #108.

**Amended by the audit of 2026-07-28.** `EvidenceSource` has no `event_anchor` member, despite the spec listing it (`circa-spec.md:392`). Adding an enum member on SQLite means a table-rebuild migration, so it should go in the same migration as the multi-parent provenance change — see #108.