Device Source of Truth

One system of record for partner-device hardware, DRM, codec support, and operational readiness—built inside Disney, forked and reseeded with invented data to show publicly.

View Demo
Topics
AI · Enterprise · Data
Format
Internal platform tool
Focus
Partner platforms and device support
Status
ARCHIVED
Device Source of Truth product screenshot
StackReact · TypeScript · Vite · Tailwind · Zod · Firebase · Express · Vitest

The answer depended on who you asked

Can this device support Dolby Vision? Which partners are still running an ADK build that just went end-of-life? When a partner replaces its whole OS stack—Amazon moving Fire TV to Vega OS—which devices are affected, and what is their certification status? Inside Disney those questions arrive constantly, from partner engineering, certification, support, and platform teams, and every one of them is answerable. The trouble was where the answers lived.

They lived in Airtable, in Datadog, in partner-submitted Excel questionnaires, and in spreadsheets maintained by different teams on different cadences. What the fragmentation cost is my testimony rather than the repository’s: support tickets that should have been lookups, launch timelines that slipped during reconciliation, and partner conversations held without a shared factual foundation.

Device Source of Truth is the internal Disney answer: one system that imports from every source, normalizes against a shared schema, and turns loose operational memory into a queryable, auditable record. This is the partner-engineering work I spent a decade doing at Disney, and DST is the tool I wanted to exist before I sat down to build it. What is on this page is a fork of that system, running on data I invented for it. Not a reimplementation written from memory, and not the production instance either: the same codebase, with the real records replaced.

Five feeds, one gate

Five feeds land in the registry: an AllModels CSV of the device inventory, Airtable intake requests, partner-key mappings exported from Datadog, telemetry snapshots from Datadog, and the partner’s Excel questionnaire—a workbook commonly carrying 100–150 answered questions across sixteen sections, mapped onto a 260-field device model, with AI extraction reading it in 30-pair batches. Extraction shipped fire-and-forget once and was rebuilt as an idempotent per-device task queue with retry and stale-job recovery.

The feeds share one shape, and the shape is the judgment: every path previews before it commits, and every commit requires the admin role.

The product does not model those four teams as personas. It enforces three roles—a viewer reads everything, an editor authors records and stages imports, an admin alone commits or deletes—and forty of the API’s fifty role guards are admin-only, which is the codebase’s clearest statement about where it thinks the risk lives.

One exception is worth the sentence: on four feeds the preview is a workflow the interface imposes, and an admin calling the commit route directly is not made to look at anything first. On questionnaire intake the server itself refuses, holding the commit until every staged record has been reviewed.

Exceptions are work, not errors. What the registry cannot explain does not vanish and does not merely fail—it becomes a work item carrying the control that resolves it. A telemetry row naming a device the registry does not hold, or a partner key it does not know, raises an alert with Register Device or Create Key attached. Creating the key auto-dismisses every matching alert server-side; a registered device has its alert dismissed by hand. The other four feeds raise no alerts—they surface exceptions inline, in their own previews.

The exception queue on the deployed demo: fifteen alerts, every one of the two types the system actually emits—Unregistered Device and New Partner Key, both raised by telemetry uploads. Each alert carries its own remedy—Register Device, Create Key, or Dismiss—and a dismissed row keeps its reason and the actor who dismissed it, so a closed exception still explains itself.
Figure 1: The exception queue on the deployed demo: fifteen alerts, every one of the two types the system actually emits—Unregistered Device and New Partner Key, both raised by telemetry uploads. Each alert carries its own remedy—Register Device, Create Key, or Dismiss—and a dismissed row keeps its reason and the actor who dismissed it, so a closed exception still explains itself.
  • 260 fieldsthe device model a partner's questionnaire is normalized onto, from 100–150 answered questions
  • 5 feedsevery ingestion path previews before it commits, and every one of those commits is admin-only
  • 3 rolesviewer, editor, admin—forty of the API's fifty role guards are admin-only
  • Private repothe repository stays private and the demo stops at a restricted login—screenshots carry the evidence

The decisions

The AI trust boundary is where this product argues with the defaults, and the same codebase draws the line twice, differently. On the CSV disambiguation paths, a name the model resolves at 0.90 confidence stops asking its clarification question—though it still rides the preview-then-commit rail. On the questionnaire path, the model reports a confidence per extracted field and the number decides nothing: it colors the review screen, and review is unconditional. Extraction was allowed to be the labor and never the authority. The records below price that position and the others like it.

One boundary applies to all four and is not repeated inside them: the workflows shipped and the deployed instance runs them end to end, but no artifact records a team adopting the tool. Each record is therefore evaluated against what the product demonstrably does, not against a usage outcome—which are different questions, and only the second one is missing.

  1. TrustPending

    Extraction proposes; a human signs

    What I encountered
    The heaviest intake is a partner's Excel questionnaire—commonly 100–150 answered questions across sixteen sections, mapped onto a 260-field device model. AI extraction reads the workbook in 30-pair batches and returns a proposed value and a self-reported confidence for every field, and the obvious next step is to let a high enough confidence commit the record.
    Over
    Auto-commit above a threshold. Not a straw man, and the parallel is worth stating precisely: on the CSV path the same codebase does let confidence decide, auto-resolving a name match at 0.90 without asking anyone—I set that threshold, then gave the number no power at all here. That path still lands in an admin-confirmed preview, so what I declined on the heavier feed was letting confidence settle anything, rather than merely declining to skip a gate.
    What I decided
    Confidence decides nothing here. The number is stored once and rendered as a badge for the reviewer; review is unconditional, and the only path by which extracted data reaches the registry is an admin-only approve route that refuses to commit until every intake partner is reviewed, a partner is assigned, every device is approved or rejected, and every conflict with existing registry data is resolved.
    Why
    A CSV mapping resolved wrong mislabels one row, and the import preview still fronts it. A questionnaire field committed wrong becomes the registry's answer about a device's DRM or codec support—the exact answer this system exists to make trustworthy. The spec says it without hedging: no questionnaire data enters the database without my explicit review.
    Cost
    Intake cannot run unattended. Every questionnaire waits on an admin walking a four-step wizard, so throughput is bounded by one reviewer's attention—the labor the AI saves is capped at drafting, because deciding still costs a human pass over every device.
    Validation boundary
    The gate is real rather than advisory: the approve route refuses server-side while anything is unreviewed, and the model's confidence has exactly one consumer—the review screen. What a live intake queue would settle is the open question: does mandatory review actually catch extraction errors, or does it only add reviewer friction?
Extraction proposes; a human signs, on the deployed demo. A four-step wizard—Assign Partner, Review Devices, Resolve Conflicts, Sign Off—holds three intake partners at pending review. Each extracted device carries its own Approve and Reject, a 44-fields-extracted count, and the registry's verdict on whether it matches an existing record. The server enforces what the wizard shows: the approve route refuses while any of it is unresolved.
Figure 2: Extraction proposes; a human signs, on the deployed demo. A four-step wizard—Assign Partner, Review Devices, Resolve Conflicts, Sign Off—holds three intake partners at pending review. Each extracted device carries its own Approve and Reject, a 44-fields-extracted count, and the registry's verdict on whether it matches an existing record. The server enforces what the wizard shows: the approve route refuses while any of it is unresolved.
  1. IntegrityPending

    An older snapshot does not silently win

    What I encountered
    Telemetry arrives as CSV snapshots, and snapshots arrive out of order—a re-upload of last month's export is one careless click from overwriting this month's record. Nearly every importer resolves this with last-write-wins, because last-write-wins is what you get for free.
    Over
    Last-write-wins, the one-line default. It is right most of the time, which is what makes it dangerous: the corruption only shows the day someone re-uploads an old export.
    What I decided
    The preview marks any row whose snapshot date predates the stored record and warns that committing it would overwrite newer data with older. At commit those rows are skipped unless the admin overrides them—per row, by index—and the count of stale rows overwritten is tallied and returned in the result rather than buried.
    Why
    A registry that a well-formed file can silently regress is not a source of truth; it is a cache with better branding. If older data is going to replace newer data, a person should have to say so, row by row, and the record should show that they did.
    Cost
    Backfilling history stopped being a single action. A stale row is not queued for anyone—the commit counts it as no-change and moves on—so an unattended import still finishes, quietly minus the rows it declined. Loading older snapshots on purpose means overriding them one at a time, by row index, and the only sign anything was skipped is a count in the response nobody is required to read.
  2. FreshnessPending

    Freshness is shown, never enforced

    What I encountered
    The registry's answers age on partner upload cadence, and a system calling itself a source of truth is usually built to do something about that—hide stale devices, block the query, force a refresh before answering.
    Over
    Enforcement—excluding stale records from queries and exports, alerting on age, or gating answers on a re-import.
    What I decided
    A badge, and only a badge: fresh under 48 hours, aging under seven days, stale beyond. Two thresholds hardcoded in one client function, computed in the browser at render time from the stored telemetry timestamp, persisted nowhere, consulted by nothing else.
    Why
    The reader's question is rarely whether the data is current; it is how old it is and whether that matters for this decision. Nine-day-old telemetry is disqualifying for an incident and fine for a planning meeting. The system knows the age; only the reader knows the stakes.
    Cost
    A badge nobody is required to look at changes nothing. No alert fires on staleness, no export excludes it, no workflow blocks on it—the product carries no mechanism that makes anyone act on age.
Freshness is shown, never enforced, on the deployed demo. This device wears its own doubts: the badge reads "Updated 9 days ago" against a 28-day telemetry window—past the seven-day threshold, so the record presents as stale rather than being hidden or blocked. Nothing downstream acts on that badge. The record stays usable and its uncertainty stays visible, which is the whole of the decision The reader decides whether nine days is fine for planning or unacceptable mid-incident.
Figure 3: Freshness is shown, never enforced, on the deployed demo. This device wears its own doubts: the badge reads "Updated 9 days ago" against a 28-day telemetry window—past the seven-day threshold, so the record presents as stale rather than being hidden or blocked. Nothing downstream acts on that badge. The record stays usable and its uncertainty stays visible, which is the whole of the decision The reader decides whether nine days is fine for planning or unacceptable mid-incident.
  1. IdentityPending

    Aliases resolve; they do not merge

    What I encountered
    The same commercial operator arrives under different names depending on the feed—the telemetry export, the key mapping, and the questionnaire header each have their own idea of what a partner is called. The clean-database instinct is deduplication: pick a canonical name, merge the records, delete the variants.
    What I decided
    An alias registry in front of the partner records. Resolution runs a chain—exact match, then registered alias, then fuzzy similarity at 0.90—with each hit tagged direct or contextual, because some raw names only resolve correctly given the feed they arrived in, and an unmatched name on CSV import creates a partner rather than failing the file.
    Why
    The variant names are not errors to clean; they are what the next export will say again. Merge the records and the next import recreates the duplicate. Keep every raw name resolvable to a canonical partner and the mess stays at the boundary instead of settling into the registry.
    Cost
    The ambiguity is managed forever instead of eliminated once. Every consumer of partner data goes through the resolver, the alias rules are one more registry an admin maintains by hand, and the product can never show a naive flat partner list with nothing standing in front of it. The unresolved question is whether that registry absorbs real upstream drift or simply becomes permanent admin toil.

Nothing real is on display

Everything in those screenshots is invented. Forking a working internal system is the cheap half; making it safe to show is the rest. The deployed instance has run entirely on synthetic seed data since a scrub replaced the real records in August 2026—invented operators under an invented streaming group, every seeded document carrying a synthetic marker, and a dataset header that opens “Every name in this file is invented.” Where production said ADK, the demo says SEK, an invented kit name: a display-layer rename, not a data change. SEK on a screenshot is itself the tell that the data is fake.

The repository is private and stays private, which is why this page’s evidence is screenshots: a scrub of deployed data does not reach specs and history, and those still carry real partner identities. So the page offers no repository link rather than a 404 only its owner can pass, and its one live button stops at a domain-restricted login. The captures are the inspectable evidence: real workflows, invented data.

What I learned

A source of truth is not a database with all the data in it. It is a system that decides three things and says them out loud: what is allowed to become authoritative, what requires a human, and what happens when two sources disagree.

DST did not eliminate ambiguity. It gave ambiguity somewhere to live. Stale records stay visible carrying their age instead of being hidden or blocked. Aliases stay at the ingestion boundary instead of being merged away, because the messy names are not historical accidents—they are stable properties of the systems upstream, and the next export will send them again. Devices nobody can explain become work items with the control that resolves them attached. AI extraction stays a proposal until someone signs it.

The mistake would have been treating normalization as tidying up. Every one of those decisions cost something real: a badge nobody must read, an alias registry maintained by hand forever, a queue that only closes when a person works it, an intake pipeline that cannot run unattended. What they buy is a registry that never asserts more than it can defend—and for a system whose entire job is being believed, that is the only trade worth making.