Architecture

System map

Layer	Owns	Reads or writes
KPI base	Metrics, targets, objectives, tasks, schedules and observations	User configuration and collection persistence
Core Record Types mirrors	Shared people, organizations, membership, cadence, tags and campaigns	Local projections and links; Tags columns on every table
Tooling and Access	Person identities, Tool Account, Tool Workspace and Identity Binding	Recipient resolution and credential source
Communication	Message, Channel, Notification Rule and membership mirror	Delivery records
n8n Data Table	Workspace token cache	Cached credentials and freshness metadata
Slack	Requests, interactions and original uploaded evidence	Modal, digest and attachment source

Configuration → due items → recipient → workspace cache → Slack request → response → Observation → message refresh. Evaluation is a separate interpretation layer; no workflow in this system fills it.

Relationships that exist

Milestone ← Task → Metric Target → Metric connects objectives to measurable work. Recurrence Configuration → Metric Target and → Membership defines collection. Observation → Metric, Membership and Recurrence Configuration records the answer. Evaluation can link Observations and Metric Targets, and Milestone.Diagnostics can link Evaluations. There is no direct Milestone-to-Metric Target link or separate Key Result/Cycle table in the verified schema.

Version and implementation boundaries

The collection schema embedded in the workflows identifies itself as communication-collection.v5. It contains fixed base/table/field IDs. Workspace credential selection is dynamic, but KPI storage is still this configured base; it is not automatic multi-base tenant routing. Public references describe canonical entities while preserving current English UI labels and text placeholders. All 26 current tables are documented in Entities.

Legacy Operations base

The legacy base “Operations” is not part of this system. It held several systems that were later split into Core and the “- Pedro” bases. Its Set Recurring table was the old KPI model: each row was a template, and an automation cloned one Task per person per cycle.

On 2026-10-21 its 252 active rows (Stage Assigned, not archived) were migrated here. Identical rows were merged, giving 159 Metrics, 193 Metric Targets and 193 Recurrence Configurations, all Active, Version 1, starting 2026-10-21, with no Observation history. The old day of the week is kept as text in Event Schedule. Six rows were skipped: no assignee, or a test company. This base now asks through Daily Digest, without one Task per occurrence.

Pausing the Operations Set Recurring automation is still open: Work Item “Pause Operations Set Recurring so KPIs are not asked twice” was To Do on 2026-10-28. Until it is done, a person can be asked about the same KPI by both bases. Check in the legacy Operations base whether Set Recurring is still on. Field descriptions here that say @airtable_table: Operation V2 - Pedro[...] use an earlier name of this KPI base, not the legacy Operations base. The internal operation key in the Daily Digest workflow is also only a label; it points to this base.