Classify each data category using the controlled DOA baseline, then evaluate purpose, owner, users, flows, provider placement, access, retention, sharing, recovery, and risk. A classification label informs the review, but it does not by itself approve an application or provider placement.
Controlled baseline
Use four labels, then preserve uncertainty
The signed DOA policy supplies Public, Internal, Confidential, and Restricted classifications. Internal is the default for new or unlabeled DOA data in the controlled draft workflow. When classification is uncertain, use the higher reasonable level until the Data Owner or governance authority confirms it.
Public data still needs an accountable owner and authorized-release basis. Confidential and Restricted uses require deeper or separate review. The repository does not contain the controlling City DLP or classification standard with detailed handling rules, so do not invent those rules from an unpublished draft.
Placement
Follow the data through the whole system
Inventory data entering, created by, stored in, transformed by, transmitted from, exported from, and deleted by the application. Record sources, recipients, providers, regions, identities, integrations, APIs, notifications, backups, and downstream uses.
Provider capability does not prove that a configuration meets the data requirement. A placement decision needs a named purpose and owners, a matching architecture, implementable controls, triggered reviews, and evidence at the appropriate gate.
- Name the authoritative source and whether the application creates a new system of record.
- Map every role, privileged path, external user, anonymous exposure, export, and recipient.
- Record retention-series mapping, legal-hold handling, deletion, return, export, and verified disposal.
Decision routes
Let the use case trigger the right authority
External sharing, APIs, AI use, Confidential or Restricted data, external users, public exposure, privileged integrations, operational dependency, provider deviations, and unusual notification patterns can change the review route. Technology authorization does not replace these decisions.
The Aviation retention schedule is the controlling centralized schedule according to the captured CDO clarification. If a record does not match a series, Data Management or Data Governance coordinates with the applicable policy owner to amend the governing source. Do not invent a retention period.
- Reassess after a material change to data, purpose, source, recipient, provider, region, user population, integration, retention, sharing, or exposure.
- Keep decision authority, concurrence, conditions, expiration, review date, and evidence paths with the record.
- Do not introduce production data while required classification, placement, or exception evidence remains unresolved.
The Ember lens
The Ember baseline review excludes or separately routes high-risk uses such as HR and payroll data, personal financial data, security or life-safety workflows, airport operational dependency, and deviations from the reference architecture. The replacement classification and placement SOP is still APPROVAL NEEDED. Its approval, official form, system of record, exception authority, implementation RACI, and first completed application record are MISSING.
Responsibility remains
The Data Owner authorizes purpose and remains accountable for the data. The Data Steward maintains inventory and classification detail. The Data Custodian identifies technical controls and evidence. Engineering evaluates whether Ember can enforce the requirements. Data Governance, Cyber, Operations, and ARB record reviews when triggered. The draft role model does not create authority or approve placement.
Apply it
Route a new case-management dataset
A team proposes an Ember workflow containing employee contact details, internal case notes, file attachments, and email notifications to an approved external partner. The owner calls all of it 'Internal.'
- 01Separate the data into categories and identify the owner and permitted purpose for each.
- 02Mark classification uncertainties and state how they must be resolved without inventing a rule.
- 03Draw the data flow across users, Render, Supabase, SendGrid, exports, backups, and the external recipient.
- 04List the review triggers, lifecycle questions, and evidence required before production placement.
Check your understanding
Make the ideas usable
Source trace
Reviewable by design
Content owner: Wesley Almeida
Last reviewed: 2026-08-18
- Ember application data classification and placement SOP draft05-projects/vibe-coding-platform/resources/standards/
- CDO data policy clarification05-projects/vibe-coding-platform/resources/standards/cdo-data-policy-clarification-2026-08-11.md
- Ember platform project status and data guardrails05-projects/vibe-coding-platform/PROJECT.md
- Ember platform architecture and data classification boundary05-projects/vibe-coding-platform/resources/diagrams/platform-reference-architecture-and-data-flow-draft-2026-07-13.md