The same launch date exists in a Drive brief, a Notion checklist, a Slack thread and a Linear milestone. Search can find all four. It cannot tell your team which one wins unless you define that rule.
Do not centralise company data by copying everything into one app. Assign one authoritative system per record class and business process. Keep the original there; index or link it elsewhere. Copy only for a declared reason, with provenance and an expiry or reconciliation rule.
This article provides a conditional decision method, not a universal tool hierarchy or a client migration result. Your processes, permissions, product plans and record obligations need organisation-specific review.
The answer in 60 seconds
- Authority is a governance role, not a software feature.
- Classify each record: keep, index, link, copy or exclude.
- Allow one maintained authority per record class or process.
- Give every integration stable identity, access and freshness rules.
- Write changes through the authority, then record the result.
- Stop new duplicates before migrating legacy content.
In this article
- Authority is a role, not an app feature
- Choose one of five placement actions
- Use a conditional tool-ownership matrix
- Give authority an operational contract
- Place one product launch across five systems
- Repair an ownership conflict
- Migrate without a big-bang move
- Run the five-question governance test
1. Authority is a role, not an app feature
IBM describes a system of record as the authoritative source for a domain or process, while a source of truth may harmonise data from several systems. The distinction is functional. Buying a search tool or creating a master Notion space does not assign operational authority.
For each record class, answer: where is it created, who maintains it and which version resolves a conflict? “We usually look in Slack first” is a habit, not a rule. “The release manager maintains the approved launch date in the launch record” is a rule.
NIST’s enterprise-architecture definition includes how systems are configured, integrated, operated and related to security and mission. For an SME, that can begin with a one-page record map. You do not need an enterprise programme to stop two tools owning the same field.
2. Choose one of five placement actions
Give every in-scope record one primary action:
| Action | Meaning | Example |
|---|---|---|
| Keep | Leave the maintained authority in its native system | Signed brief in Drive |
| Index | Make permitted content searchable without independent authority | Brief text in a retrieval index |
| Link | Point to the current native record | Notion launch page links the Linear project |
| Copy | Store a justified snapshot | Approved terms attached to a delivery record |
| Exclude | Deliberately keep it outside the memory | Secrets or unsupported private content |
Link when people can reach the current source. Index when cross-system retrieval needs content. A copy is the expensive option because it can drift. Require source_id, source URL/version, copied time, purpose, owner and expiry or reconciliation rule.
“Copy for convenience” is not enough. If nobody can say which copy may be edited or how it expires, you have created another authority contest.
3. Use a conditional tool-ownership matrix
| Tool | Often owns when… | Prefer index/link when… | Do not assume |
|---|---|---|---|
| Drive | A governed file is reviewed and maintained there | Another system needs discovery or workflow context | Every file is approved |
| Notion | A structured operating record is actively maintained there | It is aggregating records owned elsewhere | Search makes Notion authoritative |
| Slack | The organisation deliberately governs a conversation record | A thread is evidence or context for a maintained decision | Chat is always temporary - or durable |
| GitHub | Work is repository-scoped: code, PR, issue, release evidence | Product/delivery approval is cross-functional | All engineering work belongs there |
| Linear | The team runs delivery ownership and state there | The record is code-specific or documentary | Every organisation needs Linear as delivery truth |
Google says shared-drive files belong to the team, subject to edition and policy. Notion can query structured data sources, but API search is not exhaustive. GitHub supports issues; Linear issues belong to one team and require title and status. Capabilities make a role possible; your process assigns it.
Slack deserves precision. It is searchable, retention is configurable and messages can be edited or deleted. So “Slack is temporary” is not a reliable architecture rule. Decide whether a thread is governed evidence or whether a decision must be promoted to a maintained record, then document that promotion.
4. Give authority an operational contract
For each authoritative record class, capture:
- native and cross-system identity;
- creator, maintainer and conflict owner;
- permitted readers and writers;
- fields it governs - and fields it does not;
- source update time and required freshness;
- downstream indexes, links and copies;
- write-back and retirement rules.
Use stable native IDs, not editable titles. Google Drive exposes file IDs, metadata and permissions. In Linear, moving an issue between teams can change its human-facing identifier and URL while old links redirect; integrations need redirect-aware or immutable mappings.
Freshness is a contract, not a webhook checkbox. Drive notifications tell a consumer to read the change feed. GitHub and Linear publish webhooks for supported events. Delivery, signature validation, renewal, retry and downstream failure still need handling.
Store source_updated_at, event_received_at, downstream_updated_at and sync_state. If a copy or index is behind, show that state rather than serving it as current.
Write through the authority whenever possible. After an approved write, record the native ID, URL, result and timestamp in the coordinating record - the same discipline that keeps meeting notes from becoming duplicate tickets. If a second system needs an editable field, specify direction: Linear → Notion, not “two-way sync”. Two-way editing without field ownership is conflict automation.
5. Place one product launch across five systems
Consider the Atlas launch:
| Record | Governing system | Other placement |
|---|---|---|
| Approved brief and acceptance criteria | Drive | Indexed; linked from Notion |
| Launch control page and decision log | Notion | Links to all native records |
| Pricing discussion | Slack | Indexed as context; approved outcome promoted |
| Release branch, PRs and security fix | GitHub | Status linked into launch control |
| Delivery work, owners and milestone | Linear | Summary linked into launch control |
There is no universal “launch record”. There are accountable records for different questions. “What was approved?” resolves to Drive/Notion according to the decision policy. “Is the fix merged?” resolves to GitHub. “Who owns the remaining work?” resolves to Linear.
The searchable operating memory can retrieve across all five. It must preserve these roles. The Notion launch page may coordinate the view, but it should not silently copy five editable launch dates.
6. Repair an ownership conflict
Suppose Drive says launch on 14 October, Notion says 21 October and Linear says 18 October.
- Freeze automatic propagation for that field.
- Gather each value, source ID, editor and update time.
- Apply the documented conflict rule - or escalate to the named owner.
- Update the authoritative record through its normal approval path.
- Replace downstream editable copies with links or controlled projections.
- Write back the resolution and test the next update.
Do not resolve the conflict by choosing the newest timestamp unless that is the agreed rule. A recent Slack message can still be an unapproved proposal.
Make conflict, partial_write, denied and replay_required visible workflow states. Error routing and duplicate comparison can support the repair, but they do not decide which business value wins.
7. Migrate without a big-bang move
Start with record classes, not folders. Inventory five to ten high-consequence examples: launch date, customer commitment, price, contract version, release approval, incident owner or delivery deadline. Record all current locations and editors.
Then stop creating new duplicates. Change templates, automation and team instructions so new records use the chosen authority. A migration that moves history while workflows keep producing parallel records cannot converge.
Move or redirect one class at a time:
- Declare the target authority and transition owner.
- Add native identity and backlinks.
- Redirect integrations and search.
- Reconcile active records.
- Mark old copies read-only, archived or superseded.
- Test permission, freshness, conflict and rollback.
Do not delete historical sources merely to make the architecture diagram tidy. Retention and evidence needs require separate review.
8. Run the five-question governance test
Before a record class enters the operating memory, ask:
- Where is the record created?
- Who is accountable for maintaining it?
- Which version wins a conflict?
- How do permitted changes reach indexes, links or copies?
- How is the record retired or superseded?
If the team cannot answer one question, mark the class unresolved and keep automation read-only. Search may still expose evidence, but the answer should say that authority could not be verified.
Review the map when a tool, team, workflow, permission model or record obligation changes. Governance that exists only in a launch workshop will drift as quickly as the copies it was meant to control.
Conclusion: one operating memory, many accountable systems
One company brain does not require one database. It requires clear record roles.
Keep authority close to the people and workflow that maintain it. Index and link for discovery. Copy with provenance and expiry. Exclude deliberately. Then make identity, access, freshness, conflict and write-back observable.
Map five representative records
Bring five records that currently appear in more than one tool, their locations and one unresolved conflict. IZZY can map authority, placement and workflow boundaries before recommending migration or automation. The useful result may be fewer integrations, not more.
This is exactly the scope of our n8n AI Automation service.
Frequently asked questions
A system of record maintains authoritative data for a domain or process. A source-of-truth view may reconcile data across several systems.
Only for record classes the team deliberately creates and maintains there. It can index or coordinate records owned elsewhere.
Not inherently. Retention and editing are configurable. Decide whether Slack is governed evidence or whether decisions must be promoted.
No. A copy can be justified, but needs provenance, purpose, owner, access, freshness and expiry or reconciliation.
Choose a high-consequence record that already conflicts, name its maintainer and governing workflow, then stop new duplicates.
Sources and method
Research was checked on 2026-07-27 using current official Google, Notion, Slack, GitHub, Linear and n8n documentation plus IBM and NIST architecture definitions. Links sit beside material claims.
This is IZZY architecture guidance. No client data model, tenant, migration, sync or permissions were tested. Completeness, latency, security, outcomes, ROI and legal compliance remain unverified.