Christian Ullrich January 2026

This decision backbone lists the explicit decisions that must hold as an initiative approaches an irreversible commitment. Each sentence clarifies scope, ownership, and accepted downsides, ensuring contracts, plans, and slides remain consistent under scrutiny and that any decision that cannot survive review is corrected or removed before commitment.

Table of contents

Purpose & Scope

1. We decide to designate Airtable as the primary system of record for newly created structured operational data because this gives us a clear, authoritative location for new operational information instead of allowing teams to freely choose between Airtable, spreadsheets, or other tools and accept that existing data landscapes remain heterogeneous.
2. We decide to limit the initial rollout to internal teams only because this gives us manageable governance, security, and support boundaries instead of including external partners from the beginning and accept that cross-company collaboration workflows stay partially outside Airtable.
3. We decide to restrict the project scope to operational and planning data and explicitly exclude financial accounting and ERP-sourced data because this gives us a sharply bounded scope with lower compliance and integration risk instead of attempting enterprise-wide data consolidation and accept that operational and financial views remain separated.
4. We decide to include spreadsheets and generic record-keeping systems as in-scope migration sources because this gives us a concrete replacement target for most existing team data instead of limiting Airtable to net new use cases only and accept that migration effort competes with ongoing operational work.
5. We decide to require that all new cross-team data collections are created in Airtable by default because this gives us shared visibility and reuse across teams instead of allowing new spreadsheet-based coordination systems and accept that some teams must adapt their working methods.
6. We decide to allow exceptions for calculation-heavy use cases while still positioning Airtable as the primary data store because this gives us consistency of core data while accommodating advanced calculations instead of fully exempting these cases from Airtable usage and accept that workflows become more complex.
7. We decide not to define a fixed list of in-scope teams for the first rollout because this gives us open participation and faster organic adoption instead of a controlled phased onboarding plan and accept that prioritization of support becomes necessary.
8. We decide not to prohibit the parallel creation of new spreadsheet-based systems during rollout because this gives us lower resistance and smoother transitions instead of enforcing strict tool bans and accept that duplicate systems continue to exist temporarily.
9. We decide to treat historical data cleanup as out of scope, except where required for migration, because this gives us faster onboarding and reduced project effort instead of using the rollout to enforce broad data quality initiatives and accept that legacy data issues persist.
10. We decide to use Airtable dashboards as the default reporting surface for in-scope data because this gives us immediate visibility without additional tooling instead of relying on external business intelligence platforms and accept that advanced reporting capabilities are limited.
11. We decide to end the project once the rollout milestones are completed because this gives us a clear transition into steady state service ownership instead of maintaining an open-ended implementation initiative and accept that further adoption improvements must compete with other priorities.

Data strategy & Principles

1. We decide to require a clearly identified base owner for every Airtable base because this gives us unambiguous accountability for data quality, access, and lifecycle decisions instead of distributing ownership across multiple teams and accept that decision-making can become bottlenecked with a single person.
2. We decide to enforce a single source of truth per data entity across all bases because this gives us reduced duplication and clearer reuse paths instead of allowing parallel representations of the same entity and accept that coordination overhead increases when changes are needed.
3. We decide to require reuse of shared data entities rather than duplication because this gives us alignment and data consistency across teams instead of allowing local copies for convenience and accept that dependencies between bases increase.