--- id: CON-PFM-OPS-002 name: Record Activity Event feature: FEAT-PFM-OPS-02 product_area: platform module: operations revision: 1 status: draft product_intent: confirmed implementation_evidence: observed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- A record activity event is an attributed, typed entry describing reported activity within a workspace. The shared trail retains references and bounded metadata. owned_by: MOD-PFM-OPS synonyms: - audit event - record view - view history not_to_be_confused_with: - Security-change history - Business-record revisions - A query of currently readable recent records facets: - name: Record view meaning: A reported visit to a supported record. used_for: Personal history and recent-work queries. - name: Occurrence key meaning: An identity shared by repeated deliveries of one visit. used_for: Keeping retries distinct from new navigation. - name: Viewable type meaning: A registered reporting target with required readership. used_for: Authorizing reports before storing them. - name: Event type meaning: The declared category of record activity. used_for: Selecting the relevant history without widening existing reads. - name: Metadata vocabulary meaning: Event-specific short values constrained by the store. used_for: Describing activity without copying record content. - name: Retention meaning: 'The period for which activity remains stored, currently unresolved.' used_for: Managing growth and the history horizon. relationships: - to: CON-PFM-SEC-003 statement: Activity retains actor references even when the account later disappears. provenance: documented source: 'services-platform:docs/audit-events.md#The table' - to: CON-PFM-SEC-002 statement: Workspace isolation and retirement govern the event’s storage lifetime. provenance: observed source: 'services-platform:modules/audit/services/lifecycle/tenant-participant.ts' - to: CON-CRM-ENT-001 statement: Contact reporting verifies the caller’s ability to read the target. provenance: test source: >- services-platform:modules/audit/tests/integration/services/record-views/record-view.integration.spec.js#refuses a contact when the caller does not hold the type’s read permission lifecycle: [] acted_on_by: - CAP-PFM-OPS-008 - CAP-PFM-OPS-009 - CAP-PFM-OPS-010 visible_to: - ACT-PFM-001 - ACT-PFM-002 evidence: - >- services-platform at ad3f6a6: docs/audit-events.md (all sections, the 2026-10-12 acceptance checkpoint); modules/audit (routes, schemas, registry, record-view and view-history services, persistence, table, lifecycle participant, tests). - >- react-console at baf6dae: lib/record-views/tracking/*, lib/api/audit.ts, contact and organization 360 live screens; e2e controlled and dev record-views specs. supersedes: [] --- # Record Activity Event ## What It Is A record activity event is a compact account of something reported about a record. It identifies the workspace, actor, affected record, activity type and time. Most visibly, visits let a person return to records they opened earlier. Other event types retain small descriptions of merges, governed changes and attention handling. The activity trail supplies a shared vocabulary and storage contract across modules. It keeps identifying references and permitted metadata rather than duplicating the business record. An event therefore remains useful as history even when its subject later changes or disappears. The append-only capability defines the protections on stored entries; owning modules remain responsible for the meaning of the activity they report. ## What It Is Not A reported view establishes that a client or supported server read reported a visit. It does not demonstrate that a person read, understood or acted on the contents. This distinction matters when administrators interpret a colleague’s history. Record revisions describe values before and after change and belong to the record owner. Security history describes changes to authority and licensing. Recent Items is another separate projection: it uses visit evidence to query currently readable records. None of these should be treated as interchangeable accounts of activity. ## How It Is Used Console navigation reports visits after readable records appear. The backend checks the target using the person’s authorized query context before retaining the report. Delivery retries can reuse a visit identity without becoming additional visits. This makes ordinary network recovery compatible with a useful personal history. A person can read their own raw visit history, while a separate administrative permission governs review of a colleague. The query layer builds recent-work lists from those events and current record data. Owning modules use shared mutation writers when a short attributed change entry is needed. They must place the writer inside the business transaction to obtain atomic change-and-event behavior. ## Its Facets **Record view.** A visit describes reported record navigation or a supported server read. Its narrow meaning prevents the trail from becoming an unsupported measure of attention. **Occurrence key.** The key distinguishes a delivery repeat from a new visit. Its scope includes actor and workspace, allowing separate people to establish their own history. **Viewable type.** The registry describes supported reporting targets and the authority required to open them. Registration alone does not mean every corresponding screen reports views. **Event type.** Typed entries distinguish viewing from merging, interventions, configuration changes and attention activity. Readers select the event category appropriate to their purpose. **Metadata vocabulary.** Small allowed tokens describe an event without copying record contents or embedding unbounded explanations. Each type has its own vocabulary. **Retention.** Stored events currently survive until workspace retirement. Duration is an unresolved product choice rather than a configurable history policy already operating. ## How It Relates Events refer to people and records without requiring those records to remain available forever. Their workspace provides the isolation boundary and eventual purge context. CRM contacts and organizations are supported view subjects, while committees are registered without a reporting screen established by this examination. Custom records report views through their server read. Recent Items consumes the trail through the general query layer and remains owned there. ## What It Could Become The product should choose a retention period and define how it affects personal history and administrative review. Future readers for non-view events need their own authority and interpretation rules. New record types can adopt reporting through the registry, but acceptance should cover the actual reporting screen as well as backend support. Broader activity analysis should preserve the distinction between reported navigation and evidence that a person completed work.