Logical models for review

Boxes describe concepts, not required tables. Relationship labels state the meaning. These are separate choices/views; do not combine all boxes into a universal schema. Each linked spec defines minimum workflow information, its authority and conditional recovery values. Fields stay there so these diagrams cannot be mistaken for physical schema templates.

Identity

erDiagram
    USER ||--o{ IDENTITY : recognized_by
    USER ||--o{ SESSION : authenticated_by

Every accepted identity/session belongs to one user. A legacy user can exist before a provider identity is linked. Multiple identities are optional. The provider's existing user record may already supply the identity relationship; sessions normally remain provider-managed. Zero new tables can be sufficient. Contract.

Ownership

Private personal data — start here when users do not share work.

erDiagram
    USER ||--o{ RESOURCE : owns

Each protected resource has one owner, directly or through its existing parent. RESOURCE means an existing app entity, such as a project or note; it is not a generic resource table. Public data is handled explicitly outside this private slice.

Shared teams — use only when the app needs them.

erDiagram
    USER ||--o{ MEMBERSHIP : holds
    WORKSPACE ||--o{ MEMBERSHIP : includes
    WORKSPACE ||--o{ RESOURCE : owns

Each membership is one user/workspace pair. Use an existing team, account or project as WORKSPACE if it is the sharing boundary. The diagram permits an empty workspace structurally; an active workspace that requires an administrator must preserve that business rule in its mutation workflow. Sharing adds at most two logical concepts to the personal model, often already present. Contract.

Subscriptions

erDiagram
    ACCESS_OWNER ||--o| CURRENT_SUBSCRIPTION : receives_access_from

ACCESS_OWNER is the existing USER or WORKSPACE selected by the product; it is not an additional entity. Each owner has zero or one current subscription; each current subscription belongs to one owner. Subscription history is optional only when the host needs it. The app owner is the merchant. The provider customer reference identifies the payer, who may be different from the access owner. If the host already models payers, reuse it; don't add a payer table just for this graph.

The subscription is provider-owned; the host's canonical subscription representation retains the provider subscription ID, associated provider customer ID and chosen plan/price reference, directly or through existing durable relationships. Resolve the offering through existing configuration/provider state; many owners can use the same offering without a separate PLAN entity. Fixed provider/account/environment context may remain configuration. Reuse the host's subscription/payer mapping; no separate customer table or copied customer profile is required. Capability policy plus verified subscription facts produces effective access, including a cutoff where applicable. A zero-price subscription can qualify under app policy. No separate entitlement table is required. Contract and field guidance.

flowchart LR
    A[Verified subscription facts] --> C[Effective paid access]
    B[App plan and recovery policy] --> C
    C --> E[Allow paid operation]
    D[Current actor and data permission] --> E

Both paid access and native data permission are required. The two inputs must be checked at the actual enforcing boundary; this diagram is not a replacement for that check.

Credits

This optional view supports free accounts with credit-gated services; it does not require a subscription.

flowchart LR
    G[Trusted grant or verified top-up] --> A[Available credits of existing user or workspace]
    A --> C[Authorized service consumption]
    O[Existing payment or job operation identity] --> G
    O --> C

Available credits are host-owned state or a derivation from existing credit history. Grant and consumption describe effects on the existing owner's credits, not new required entities. Reuse payment/job records to recognize applied operations. Native atomic changes must prevent duplicate additions/debits and concurrent overdrawing. A separate wallet, ledger or billing engine is not required. External work still needs bounded recovery for uncertain results; a local transaction cannot make a paid remote effect atomic. Contract and inline mapping.

Management

This is an operation-mapping diagram, not an additional LDM.

flowchart LR
    A[Screen or dashboard action] --> B[Existing query or command]
    B --> C[Actor and ownership check]
    C --> D[Existing app entities]

Map fields, pagination, scoped totals and allowed actions to native operations. Where the operation is gated, apply the product's chosen subscription or credit policy. Zero new domain entities. Contract.

Connections and background work

flowchart LR
    O[Existing user or workspace] --> C[Service connection]
    C --> S[Imported source identity]
    S --> B[Existing business record]
    B --> I[Search or index result]
    W[Existing background operation] --> C

The arrows describe how authority is resolved, not required owner columns or tables. A source identity can be fields on the business record; an index result can be derived. The worker resolves its connection's current owner and authority before committing. Provider account identity and credential reference belong to the connection contract, not every downstream record.

Imported facts may change; user-managed business progress survives replay. For example, re-importing an email can refresh its subject while preserving the requisition's fulfilled state and manual notes. See connections, background work and the global personal-app example.

Simplicity decisions

No universal owner hierarchy, event bus, trigger framework, payment ledger or generalized role engine is implied. A concrete host can still need an extra record to preserve a real relationship; it must earn that addition in its bridge plan.