EmberApplication Platform
Menu
Back to path
Draft complete12 minutes

Security, privacy, records, and data authorities

Inherited, shared, and application controls

Assign each control to the boundary where it is implemented, operated, verified, and evidenced.

The short answer

A control is inherited only when a reusable control applies to the application's actual scope and current evidence demonstrates that relationship. Shared controls divide work across provider, platform, application, and oversight roles. Anything application-specific must be designed and proven by the application team.

01

Control model

Start with four responsibility buckets

A provider can operate secure infrastructure while an application exposes records through an overly broad role. A platform can publish a supported identity pattern while an application fails to enforce it. Control language must identify the exact boundary and the part each party performs.

Avoid assigning an entire control family to one party. Break the control into implementation, operation, monitoring, review, exception handling, and evidence so shared work becomes visible.

Four control bucketsThe right bucket depends on scope and evidence, not on which provider advertises the feature.
01Provider-operatedA supplier operates a defined provider-layer capability under its service boundary.
02Platform-inheritedA reusable Ember control applies to the application scope and has current evidence.
03SharedSeveral parties perform distinct parts of one control outcome.
04Application-specificThe application must design, configure, test, operate, and evidence its own behavior.
02

Inheritance test

Ask four questions before giving credit

Inheritance is a scoped claim. It must connect an approved control, a matching architecture and use case, a responsible operator, and current evidence to the specific application boundary.

If the application changes provider, identity pattern, data class, exposure, runtime, or operational impact, reassess the claim. A platform statement should never conceal application-specific configuration or testing that is still MISSING.

  • Applicability: Does the reusable control cover this component, environment, user population, and data use?
  • Implementation: Is the required configuration present in the application path?
  • Operation: Is an owner performing the required review, response, or maintenance activity?
  • Evidence: Can a reviewer trace the claim to current artifacts and test results?
Control inheritance gateA 'no' or unknown answer stops automatic inheritance and creates a gap or application action.
01Control definedThe requirement and outcome are precise.
02Scope matchesArchitecture, data, identity, and exposure remain inside the supported boundary.
03Implementation verifiedConfiguration and behavior are demonstrated, not assumed.
04Evidence retainedOwner, artifact, date, result, and limitations are traceable.
03

Review practice

Build a claim-to-evidence chain

Write the control claim in plain language, state who performs each part, then cite the artifact that demonstrates the implementation and operating result. Provider reports, tenant screenshots, configuration exports, tests, tickets, and review records answer different questions.

Mark absent evidence MISSING. Mark evidence that is partial, stale, out of scope, or unable to prove implementation INSUFFICIENT. Do not upgrade a control because the intended design appears reasonable.

  • Record assumptions and limitations beside the claim.
  • Separate design evidence from implementation and operating evidence.
  • Set a trigger for revalidation after material application or platform change.

The Ember lens

Ember is under review and final accreditation is MISSING. The project identifies candidate inherited capabilities and application-specific controls, but identity governance, monitoring, secrets, reference application, environment, data placement, and recovery evidence contain material MISSING or INSUFFICIENT items. Reviewers must evaluate the exact application delta rather than treating provider membership or Ember use as blanket control inheritance.

Responsibility remains

The platform owner must describe reusable controls and their evidence boundaries. Application owners must identify application purpose, users, data, roles, integrations, operations, and deviations. Security and data authorities interpret requirements and record concurrence or objections within their authority. None of these roles may infer approval from an unapproved draft.

Apply it

Challenge an inherited-control claim

An application team says, 'Supabase has audit logs and row-level security, so our logging and authorization controls are inherited from Ember.' No application configuration or tests are attached.

  1. 01Split the statement into provider capability, platform responsibility, and application-specific implementation claims.
  2. 02Mark the evidence status for each claim and explain why.
  3. 03List the minimum configuration, test, ownership, and review evidence needed before inheritance can be considered.
  4. 04Identify one change that would trigger revalidation.

Check your understanding

Make the ideas usable

2 questions
01When can an application inherit an Ember control?
02How should a sensible design with no implementation proof be marked?

Source trace

Reviewable by design

Content owner: Wesley Almeida
Last reviewed: 2026-08-18

  • Ember platform project status and control boundary05-projects/vibe-coding-platform/PROJECT.md
  • Ember platform reference architecture and data flow draft05-projects/vibe-coding-platform/resources/diagrams/platform-reference-architecture-and-data-flow-draft-2026-07-13.md
  • Ember platform foundations course05-projects/vibe-coding-platform/resources/learning/ember-learn-platform-foundations-course-2026-08-11.md