← Back to directory

identity-and-governance.md

architecture/identity-and-governance.md · 72.7 KB · 2026-11-02 12:48

Identity and Governance

Status: settled semantic contract, 2026-09-11. Identity, Business context, authority, Policy enforcement and delegation are architectural requirements. The bounded registration, confirmation, authentication, Business-context and governed Business-creation runtime slices are implemented and focused-verified; broader identity and governance coverage remains incomplete.

Terminology correction, 2026-11-02 (project owner, Stu). There is no separate Principal concept. The platform identity and authority subject is the User: an authenticated account that signs into Idiosyncrasy. A Person is an individual profile defined within the context of one Business. Neither requires the other to exist. The existing persisted Type is named Principal, but its records represent User accounts. Principal is a legacy implementation identifier, not a current architectural concept or a separate identity Type. Identifiers such as principal_id and the Type name Principal remain as legacy implementation details until a separately authorized migration (see implementation architecture and PRR-061). This correction is not a numbered decision and does not reopen D01-D10.

Current versus target. Everything below that describes the commercial classification (Licensed and Guest Users), Business activation or delegated-authority succession is intended future architecture. Today all Businesses are treated as active and no subscription, entitlement, billing, activation or Guest enforcement exists. Nothing in this document restricts the current build or the Spearmint Design milestone.

Owns: Users (authenticated accounts and platform identity), the User-account versus Business-Person-profile boundary, membership, tenancy/isolation, permission evaluation, ownership and delegation authority, approvals, risk/autonomy enforcement, audit obligations and trust boundaries. The core object model and authority contract supplies the cross-cutting rule that authorship, description, connectivity and AI output do not grant authority. Objects and types owns typed declarations; semantics owns business policy meaning; workflows and automation executes governed actions.

Lineage: source 02's identity/tenancy layer and permission-aware engines, source 01's ownership/AI independence/suggestion principles, source 03's approvals and human-first workflows, and corresponding source 00 sections. Security and isolation principles are retained without importing the old marketing hierarchy. See the source ledger.

Users, Identity and Membership

A User is the authenticated account through which the platform attributes authority and actions. It is the platform identity and the sole authority subject: authentication, Membership, AuthorityGrant and Policy evaluation all refer to a User. There is no separate Principal, and no second identity or authority concept for automation, workflows or integrations (see Delegated Authority For Automation). The actual actor, the User whose authority applies and any technical executor remain distinguishable in provenance.

Authentication establishes a User in a particular request/session context. Authorization determines what that User may do in the relevant business and isolation context. Successful authentication is not general permission to read or mutate business data.

A Person is a Business-scoped profile of an individual, not automatically an authenticated User, and a User does not necessarily have a Person in any Business. An Organisation can be a customer, supplier or partner without being a Tenant. A customer relationship, project assignment or "owner" label does not by itself grant account membership or platform privileges. Likewise, creating or authoring an object, definition, relationship, Policy or workflow records provenance but does not create continuing authority over it. The relationship between the two is described in User Account And Person Profile.

Membership expresses an authorized association between a User and an access context. Business affiliations and account memberships must remain distinguishable even when both are represented through related shared-model objects.

Roles or permission groups may help express reusable authority, but no fixed administrator/client hierarchy is adopted here. Permission definitions, membership and addressable identity configuration follow the universal model, not a separate conceptual identity schema.

Addressability does not make authentication secrets publicly readable objects. The conceptual model and the operational credential boundary must be realized together without exposing secret material through generic retrieval or exports.

<a id="concept-map-person-principal-business-relationship-membership-authority-and-account"></a>

Concept Map: User, Person, Business, Relationship, Membership, Authority and Account

Status: PARTLY SETTLED, reconciled 2026-11-02. The conceptual distinction is settled by the project-owner correction of 2026-11-02 (see the terminology correction above): User is the established platform identity and sole authority subject; Person is a Business-scoped individual profile; a User-to-Person association is optional and always Business-scoped; neither requires the other; and Principal is superseded terminology, surviving only as a legacy implementation identifier. The Licensed and Guest principle, delegated authority and the User-account versus Person-profile model are recorded as owner-stated direction in their own sections. Not settled: the physical association mechanism, the privacy treatment and attribute transfer, the Licensed and Guest derivation, delegated-authority succession and every other item under the unresolved questions below remain open. The earlier 2026-10-28 proposal status ("pending project-owner approval") is superseded for the settled distinction only; it does not apply to the open items. This section introduces no decision number, Type, store, registry, Operation, account object or identity subsystem. It records which statements are already settled by the cited text, how each concept maps to existing platform mechanisms, and which questions are genuinely unresolved. It does not authorise identity or authority data changes.

| Concept | Existing meaning and mapping | Evidence | |---|---|---| | User | The platform's authenticated account, identity and sole authority subject: platform-scoped (business_id null). Verified email, credentials and sessions stay in the protected identity boundary. Created only by the registration and confirmation Operations. A User is the subject of authentication, Membership, AuthorityGrant and Policy. A User need not have a Person in any Business, and a Person need not correspond to a User. The existing persisted Type is named Principal, but its records represent User accounts; Principal is a legacy implementation identifier, not a current architectural concept or a separate identity Type. | User-First Runtime Lifecycle; objects and types; Genesis descriptor named Principal (legacy) | | Person | A Business-scoped profile (Type a1000000-...-0101) of an individual within one Business. It is never automatically an authenticated User and carries no authority. A Person may exist with no User, and a User may have no Person in a Business. | This document (Users, Identity and Membership); business model (Alex the Person); implementation plan | | Business | An independent first-class object with its own identity, Graph and DNA. Not a tenant, Account or User-owned record; creator is historical provenance only. Created only through business.create. | Business model; product definition | | Relationship | A Business-owned, typed, addressable connection between objects (for example person-organisation, c2000000-...-0101). Its meaning is defined by its Relationship Type, never inferred from labels. A Business affiliation is a domain fact and conveys no access. The declared but inert Relationship Type c2000000-...-0106 was introduced as "Person to Principal"; it is reframed as a potential Business-scoped User-to-Person link, still uninstantiated and subject to the privacy rules below. No Person-to-Business Relationship Type is currently declared. | Relationship Identity and Meaning; capability configuration manifest | | Membership | A distinct authority-model object (Type d7031627-...) with business_id, principal_id (legacy identifier for the User reference), membership_kind, status. It associates an authenticated User with a Business access context and permits selecting that context only. It is not a Relationship and is not implied by one; business_administrator is descriptive, not ownership. | This document (Users, Identity and Membership; Shared-Model Governance Examples); implementation plan section 9 | | AuthorityGrant | Independently governed permission to perform named Operations against declared target Types/objects, bound to a Membership (Business scope) or directly to a User (platform scope), with a matching active Policy. Re-checked at commit. Neither Membership nor creation confers it. It may be retained, delegated, restricted, transferred or revoked only through governed mechanisms. | Permission, Scope and Ownership; Platform Governance Foundation Mechanism | | Account / operating context | No Account, payer, agency or tenant object exists, and no new User object or second identity model is introduced. The shell's "account control" is the single User control, not an object. Operating context is derived per request from authenticated User, selected Business and current Membership, Grant, Policy and entitlement. The commercial payer or manager is a separately approved future decision. | Subscriptions and entitlements; objects and types; User Profile and Account Control |

Licensed and Guest classification (intended future architecture; not implemented). A User associated with a Business is, for commercial purposes, either Licensed (counts towards that Business's subscription) or Guest (does not count). Classification is derived wherever possible from existing Membership, AuthorityGrant, Policy and entitlement evidence and must not become duplicated stored state. Licensed status never grants operational authority: authority stays with Membership, AuthorityGrant and Policy, independently of classification. A Guest cannot execute Business operations. The derivation mechanism and edge cases are unresolved (see the questions below). The commercial consequences are owned by subscriptions and entitlements.

Current Stuart Mayne case. The authenticated User (Stuart Mayne; the persisted record uses the legacy Principal Type and principal_kind human) is connected to the Spearmint Design Business through a business_administrator Membership created atomically by business.create. Business authority comes from the three Membership-bound Grants and Policies that handler creates (inspection, configuration install and demonstrator operations). Platform authority comes from User-bound grants: the bounded business.create onboarding grant and the configured definition.publish grant. These are independent revocable objects; none follows from Membership, creator provenance or the Person record. The demonstrator population creates fictitious Person objects and no Person for Stuart; the model does not require one. This case is derived from the handler and installation contracts and from earlier status evidence, not from a fresh read of live grant objects.

Support for future cases. A User with limited authority holds a Membership with narrower Grants and Policies. A User with several Businesses holds one Membership per Business, with no Business-to-Business inheritance, and may have a different Person profile, position, contact details and authority in each. A User with no Person is valid, and a Person with no User is the normal case. Delegation is the addressable arrangement defined in Approval and Delegation, constrained by delegator authority. Transfer and revocation use governed authority changes. No Operation, Type or Presentation yet realises delegation, restriction, transfer or revocation.

Unresolved questions (owner decision required before any identity/authority data or new primitive):

1. Whether and how a User may be associated with a Person in a Business (always Business-scoped), and by what mechanism. A Business-scoped Relationship to a platform-scoped User needs an isolation and privacy rule that does not yet exist. Whether the association is one-to-one is not assumed. 2. Which Relationship Types express a Person's relationship with a Business, and whether the platform-typed Business object may be an endpoint of Business-owned Relationship Types. 3. The vocabulary of membership_kind beyond business_administrator, and the Operations that change Membership status. Authority-management Operations are deferred. 4. Whether and how a Business may see other Users, Memberships and Grants, and which Business Grants authorise inspecting these platform-adjacent Types. 5. Any commercial Account or payer concept, which remains an explicitly separate approval. 6. The derivation mechanism and edge cases for Licensed and Guest classification: Memberships with no grant, pending, suspended or revoked Memberships, a User who may execute only one operation, and the point in time at which billing determines the count. The principle above is recorded; the mechanism is open. 7. Whether principal_kind survives, since every User is presently a human account, and how the legacy Principal identifiers are reconciled with User (migration blocked by Stage 3D; PRR-061). 8. The open items in Delegated Authority For Automation and User Account And Person Profile.

Governed presentation route. User (legacy Type Principal) and Business are presented only through /objects/{id} using the data-defined core-object Presentation profile provisioned per Business. Their detail view currently shows display_name and status. Richer presentation is limited to that governed Presentation profile and to fields the existing Types already declare. Membership and Grant links are value references, not Relationship objects, so a generic relationship section cannot list them. Showing them would need an approved reverse-reference mechanism.

Temporary restrictions and revisit conditions.

| Restriction | Revisit condition | |---|---| | The demonstrator population creates no User, Membership, AuthorityGrant, Policy or Person-for-Stuart. | Owner approval of unresolved questions 1-3, plus a governed admission path. | | No User-to-Person or Person-to-Business Relationship Type is instantiated. | Owner decision on questions 1-2. | | User and Business detail pages stay minimal (display_name, status). | Core-object profile revision through its governed provisioning route. | | No UI lists Memberships or Grants for a User or Business. | An approved reverse-reference or inspection mechanism and an answer to question 4. | | Delegation, restriction, transfer and revocation are not implemented. | Owner approval of an authority-management Operation contract. | | No Account, payer or agency object. | A separately approved commercial-actor decision. | | No Licensed or Guest classification, Guest restriction or subscription counting exists; all Businesses are treated as active. | A separately authorised build of the entitlement gate after question 6 and the pricing-transition decisions are settled; it must not interfere with the Spearmint Design milestone. | | The legacy Principal Type and principal_id identifiers persist. | A separately authorized migration after Stage 3D (PRR-002, PRR-061). |

User, Person and Business detail: verified current state and blocked implementation route (2026-10-28). Recorded as PRR-052; this subsection is the authoritative plan and introduces no decision number, Type or Operation. Historical wording below that uses "Principal" refers to the legacy Type and identifiers that represent User accounts; it is retained as dated evidence.

Verified from source (InitializationVocabulary::descriptors() and platformDefinitions()), not from live data:

Required changes for the requested attributes (all blocked, none attempted):

| Requirement | Mechanism required | Gate | |---|---|---| | Person date of birth, sex, contact details, biography | Person Type revision 2 with optional properties, then Person Definition revision 2 constituents. Sex needs a stated purpose, access rule and minimisation decision before it is modelled at all; date of birth needs the same. | Governed Type revision (Stage 3D, PRR-002) and, for pinned Views, View revision 2 (PRR-009) | | Person qualifications | Recommended as related Objects (a Qualification Type plus a Person-to-Qualification Relationship Type), not an array on Person, so each qualification keeps its own identity and provenance. This is a modelling proposal for the owner, not a decision. | New Type and Relationship Type, both governed | | Business trading and registered address, registration details, contact information, website | Either Type revision of the platform Business Type, or extension of the Business Definition constituents (existing route). Owner must choose; the two have different privacy and tenancy consequences because Business is platform-scoped. | Owner decision, then governed Type revision or definition.publish | | Principal to Person (legacy wording; now User to Person) | A Business-scoped Relationship Type or reference rule between a platform-scoped User and a Business-scoped Person that respects isolation (open question 1). User and Person remain distinct Objects. | Open question 1 | | Person-to-Business affiliation versus authority-conferring Membership | Affiliation is a Relationship (open question 2); authority remains Membership plus AuthorityGrant plus Policy, per Business and per Operation (open question 3). No change to Membership semantics is proposed. | Open questions 2 and 3 |

Admission and write mechanisms: Users are admitted only through the existing Operations principal.register and principal.confirm (legacy-named Operations; they admit Users, not a separate class of Principals), Businesses only by business.create, and Persons through the ordinary governed Object create and update commands, which validate against the pinned Type revision and retain provenance. Authority records are never created to populate a page. Demonstration Person values may be added only through SpearmintDemoPopulationService once a Type revision exists, and must be visibly synthetic.

Implementation sequence once unblocked: (1) owner answers questions 1-5 and approves the attribute list and privacy treatment; (2) Stage 3D is authorised for build; (3) governed Type revisions and Definition revisions are published; (4) View revision 2 pins them (PRR-009); (5) core-profile revision 2 and Person detail Presentation add the new fields, with edit through the existing governed update command; (6) synthetic Person demo data, then STAGING verification of create, edit, concurrency conflict and read isolation. Nothing in steps 3-6 may start before steps 1-2.

Blocker classification (2026-10-28, after a read-only STAGING inspection). STAGING shows the Principal, Business, Person and Organisation Definitions in the Definition Explorer; their detail Views show only a name and Type reference; the constituent Type has no Presentation Definition (Explorer 404), and the Business, Principal and Person Views declare no relationship section (/relationships and /graph return 404). No Principal, Membership, Authority or Person data was created or changed.

| Class | Item | Status | |---|---|---| | Technical blocker | Person, Organisation and platform Type revisions cannot be published: Stage 3D (platform.type_revision) is NO-GO (PRR-002); the Person Type rejects unknown properties | Blocked | | Technical blocker | Pinned Views cannot adopt new Type revisions without View revision 2 (PRR-009) | Blocked on Stage 3D | | Missing decision | Open questions 1-5 above; privacy, purpose and access rule for date of birth and sex; whether Business attributes live on the Type or as Definition constituents | Needs Stu | | Missing governed mechanism | An authorised, bounded read of constituent Objects by subject_id and constituent_key so existing Business and Principal constituents can be presented. STAGING probe 2026-10-29: the Business contact_email constituent exists but is refused by the reader because the administrator's inspection grants name no Constituent Type target; the Business address and Principal profile_note constituents do not exist. Needs (a) a governed inspection grant for the Constituent Type, approved by Stu (PRR-056), and (b) a record-bound source filter in the projector. Business and Principal detail already presents every existing Type property through record templates (profile revision 19); a reverse-reference or inspection mechanism for Memberships and Grants is also not built | Not built; (a) needs Stu | | Can proceed now | Documentation (this record); the display-only presentation of values the existing Types already hold (already shown: display_name, status) | Done; nothing further is unblocked without the decision above |

The model comparison is the concept map above: Person (Business-scoped, no authority), User (platform-scoped authenticated subject, may or may not have a Person in a Business), Business (independent first-class object), Relationship (Business-owned domain fact, no access), Membership (access context only, not authority) and AuthorityGrant plus Policy (authority, per Business and per Operation). Membership is not treated as the universal authority model.

Identity model route decision (2026-10-29, Stu; supersedes the "blocked" route above for the properties below). Terminology clarification, 2026-11-02: "Principal" in this dated decision means User; it is the legacy Type name, not a separate concept. The decision's substance, Type and Relationship identifiers and dated evidence are retained; only descriptive wording that named the actor or identity subject has been aligned to User, and literal legacy names are kept and marked as such. Recorded as PRR-052, PRR-056, PRR-057, PRR-058 and PRR-059; it introduces no decision number and no new platform Type or Operation.

User-First Runtime Lifecycle

Normal runtime begins with the distinct lifecycle registration -> confirmation -> authentication -> bounded onboarding -> business.create. User identity, normalized identity association, credential, confirmation eligibility, authentication, authorization and revocation remain separate concepts. A pending User is not an authenticated or authorized User; a credential never implies confirmation or authority. User registration is free and requires no subscription (intended architecture; no entitlement check exists today).

Registration is a narrowly bounded server-owned admission operation. It creates a pending User, a normalized identity association, separate credential material and a protected confirmation challenge atomically. It creates no Business, Membership, AuthorityGrant or unrestricted platform privilege. Confirmation consumes one correctly bound, unexpired challenge exactly once, rejects replay and invalid or concurrently losing attempts, transitions the User to confirmed/active state and atomically issues the bounded onboarding grant with durable Event/evidence/provenance. Registration and confirmation are not workflow execution and do not bypass the Command, evidence or fail-closed governance boundaries.

The confirmation challenge is server-side verification material, not a registration credential that a person is expected to possess or submit as a normal account-creation input. Registration returns only a non-secret admission result to the browser and requests an out-of-band confirmation message through communication. The message contains a purpose-bound, User/identity-bound, expiring single-use verification link or equivalent confirmation action. The raw challenge is never exposed through generic object retrieval, ordinary authentication responses, logs or durable business data. A failed, delayed or unknown delivery result leaves the User pending; the recipient may request a bounded replacement challenge, while each consumed, expired or superseded challenge is permanently unusable. Duplicate registration for an existing normalized identity is a controlled conflict and must not disclose whether a different account exists; a product-level resend path may issue a fresh challenge without activating the User.

Before confirmation, the User may use only the explicitly bounded admission/recovery surfaces needed to complete confirmation. It cannot authenticate into the application, select a Business, invoke business.create or receive ordinary Business authority. After confirmation, authentication establishes a session identity but still does not grant Business access; Business reads and operations require active Membership, applicable AuthorityGrant and Policy. Intended future architecture (not implemented; all Businesses are currently treated as active): Business-scoped operations additionally require the Business's subscription entitlement, while User registration and business.create remain free of any entitlement requirement. Confirmation is therefore not a general-purpose login credential and cannot be replayed as one.

The onboarding AuthorityGrant is platform-scoped, User-bound, Business-null and Membership-null. It authorizes only business.create against Type Business; it is bounded, revocable, auditable and provenance-bearing. It grants no ownership, general administration, Policy management, grant issuance, arbitrary platform operation or Business access. business.create additionally requires authenticated User context, the active exact Operation revision and active platform Policy. Business-scoped authority cannot authorize this platform operation and no implicit platform allow exists.

Platform Definition Publication Authority

The already-established, active project-owner User receives the narrow platform permission to publish Definitions through normal installation/configuration. Installation binds this permission to that User's exact identity; it does not create a User or credential and is not a bootstrap protocol, self-authorising request, HTTP privilege path or Genesis effect. A missing, malformed, unresolved or inactive configured identity fails closed. No other User receives this permission by default. The selected configuration mechanism is specified in Security and Operations.

Each publication requires the acting User's direct User-bound platform AuthorityGrant for definition.publish on the Definition Type and a matching active platform Policy. The existing platform authorization model checks both and rechecks them at commit; neither the Operation nor its input grants permission. Permission establishment uses the existing platform grant and Policy Objects through normal installation/configuration. Publisher reassignment and revocation are deferred and are not part of this foundation; no authority-management Operation is introduced.

Publication remains distinct from draft authoring and Business application. It creates or revises only the platform Definition Object and its exact-revision publication evidence. Genesis, User onboarding, the Explorer, and IDY-008 do not silently publish Definitions or grant this permission.

Tenancy and Isolation

A Business-scoped isolation boundary separates an authorised Business/access context from others. If the term tenant is used, it is only an implementation shorthand for that isolation boundary; Business is not a tenant identity and no User or Account is a tenant owner. The initial implementation requires an explicit Business context and durable membership/authority checks on each operation. An Organisation relationship or selected browser value cannot establish that access context. The mechanism does not redefine Business as an old marketing client account.

Do not inherit the legacy selected-client mechanism as the target model, assume one organisation equals one Business, or assume a User can belong to only one Business. Single-business, multi-business, agency and multi-tenant descriptions are not Business identity models. The absence of a selected hierarchy does not weaken isolation requirements.

Every applicable read, query, relationship traversal, change, export and executable action must preserve the authorized isolation context. That context must be checked at the authoritative boundary, not trusted because a browser submitted a tenant identifier or displayed the right navigation.

Isolation extends to knowledge, configuration, workflow definitions/executions, events, history, analytics, files, integration tools and optional AI context. Search results, counts, relationship existence, caches and derived indexes can disclose information even when a full object is not returned.

Retrieval must constrain candidate selection and assembled context by permission. Views and content must present only permitted data and actions. Neither a hidden button nor filtering after an AI provider has already received data is sufficient enforcement.

Cross-business sharing, platform-managed reusable configuration and delegated access require explicit authority and boundaries. Initial membership/grant/definition references are typed objects under the chosen mechanism; unsupported cross-business sharing is refused. Shared infrastructure is not permission to share every object.

Business Creation And Administration

Existing architectural rule: An authorised User may create a Business through the normal governed mutation path. The creation operation establishes the Business entity, records creator provenance, assigns initial administrative authority and creates the initial governance required for that authority to operate. It does not establish permanent ownership or an Account-to-Business ownership relationship. Genesis does not create a Business and there is no special first-Business path. Business creation is free: it requires no subscription or entitlement (intended architecture; no entitlement check exists today, and none may be added to business.create).

Newly resolved governance decision: Normal Business creation is a platform-scoped capability named business.create. It is not Genesis provisioning, external tenant provisioning, a generic object.create alias or Business-scoped administration. The target Business does not exist before this operation, so ordinary Business-scoped Membership, AuthorityGrant and Policy checks cannot authorize its creation. The authenticated User must instead hold the separately governed platform-level authority to invoke business.create.

The operation creates exactly one active, Business-scoped Membership for the authenticated creating User. Its descriptive Membership kind is business_administrator. This label does not establish a permanent administrator hierarchy, immutable role system or ownership primitive. The Membership is an ordinary governed object and may be restricted, replaced, delegated or revoked.

The operation also creates explicit AuthorityGrant object(s) for that Membership and Business. Each grant has explicit operation scope and, where applicable, explicit target-Type scope. The grants are the minimum explicit capability set required to administer the newly created Business and its governance. They are independently revocable and do not arise from relationships or imply ownership.

The operation creates at least one explicit active, Business-scoped, versioned Policy before normal Business-scoped administration becomes usable. Policy remains independent from Membership and AuthorityGrant and is evaluated by the existing Policy mechanism. Missing or conflicting required Policy resolution fails closed; there is no undocumented intrinsic allow Policy. The concrete initial Policy configuration and its rule inventory are an implementation/configuration dependency and must be created atomically with the Business bootstrap.

The created Business root object is platform-scoped and therefore has business_id = null. Authorized Business identity is exposed through the governed Business projection used by Business selection, which resolves active Memberships and returns the permitted Business identity fields. The Business-Type inspection grant does not make this platform-root object appear in the ordinary Business-scoped object list, but an authorized current Business may now be inspected through the same canonical /objects/{id} detail and revision mechanisms as other Objects. Business-scoped /objects lists continue to contain only Objects owned by the selected Business.

For platform business.create, Command admission evidence and the resulting Business bootstrap effects are one atomic transaction. The Command, Action Execution, Attempt, Provenance and admission evidence are not durable independently of the Business, Membership, AuthorityGrant and Policy effects: any Business-effect failure rolls back the admission evidence and all partial bootstrap state together.

The concrete AuthorityGrant operation and target-Type inventory, the platform-level authority source for business.create, and the concrete Operation Contract revision and trusted handler registration are implementation/configuration dependencies. They must not be inferred from Genesis values or invented as universal administrator privileges. Any previous bootstrap_operator or platform.inspect_foundation implementation values are superseded historical evidence; they are not human Genesis state, normal Business-administration semantics or continuing runtime authority.

Required security and evidence boundary: The server resolves the authenticated initiating User and generates the Business identity. The request cannot supply User identity, Business scope, Membership, AuthorityGrant or Policy authorization. Business, Membership, grants, Policies and required provenance/history evidence commit atomically or no usable partially governed Business remains. The durable evidence identifies the Business and revision, initiating User, governance object revisions, exact business.create Operation revision, Command, Action Execution, Attempt, Outcome, Provenance and Business-creation Event where the Event contract supplies the applicable naming convention. Duplicate delivery uses the existing Command identity, fingerprint and idempotency rules.

Creator provenance is historical attribution. Current Business administration is an independent, scope-bound authority relationship. That authority may be retained, delegated, restricted, transferred or revoked under the same server-side Membership, AuthorityGrant and Policy checks as other consequential governance. A different User may become the current administrator without changing Business identity.

Business existence, network participation, User association, authority to act on behalf of a Business and subscription entitlement remain orthogonal. Authority determines who may act for B; it does not determine whether B exists. A relationship, assertion, creator record, accessible observation or network connection may provide information about B without creating a User association or authority. Conversely, absence of authority must not be treated as absence of information, and absence of a User must not be treated as absence of a Business. These conclusions are derived from the underlying graph, evidence, Membership, AuthorityGrant, Policy, entitlement and history; they must not be encoded as one combined lifecycle classification.

Subscription entitlement is a separate operational prerequisite. Intended future architecture; not implemented, and all Businesses are currently treated as active. Inactive entitlement does not revoke authority or destroy governance; it blocks Business-scoped operational execution under subscriptions and entitlements. Authorised Users may retain permitted inspection, subscription/reactivation and governance actions during suspension.

Licensed and Guest Users

Intended future architecture; not implemented. Commercial classification is a property of a User's association with one Business, not a platform-wide User attribute and not a separate identity. A Licensed User counts towards that Business's subscription; a Guest User does not. A User may be Licensed in one Business and a Guest in another, and is counted independently per Business.

A Guest's read access to a Business is ordinary authorised inspection and is bounded by the same isolation and authority rules as any User. Presentation is never authority. Guest access must be enforced at the retrieval, authorization and projection boundaries, including aggregates, counts, search results, relationship existence, caches, exports and API responses, and must be revocable. Per-instance or relationship-specific Guest visibility is not expressible with the current grant and Policy model (PRR-060, PRR-064).

Delegated Authority For Automation

Intended architectural direction (project owner, 2026-11-02); detailed execution model unresolved. There is no independent non-human identity or authority subject. Automation, workflows and integrations operate under authority delegated by a User. The User is the authority subject; the technical executor (worker, workflow engine, integration adapter) is recorded separately as execution provenance and evidence. An automation does not become an identity in its own right, and no new identity concept replaces the superseded Principal.

Proposed succession behaviour (not a settled decision; recorded for further discussion):

Open questions (no answers are assumed):

1. What constitutes an appropriate replacement authority. 2. Whether the replacement must explicitly accept responsibility. 3. Which staff members receive notifications. 4. Whether different workflow and automation types require different authority models. 5. Whether existing queued or in-progress operations are suspended, cancelled or allowed to complete. 6. The wider execution model, revocation behaviour, User departure and disablement, and inbound-callback authorization.

Until these are decided, existing statements about a runtime worker's technical identity describe execution provenance only. Nothing here is implemented; the current runtime does not pause executions on loss of authority.

User Account And Person Profile

Intended conceptual model (project owner, 2026-11-02); mechanisms unresolved. A User-to-Person relationship is always Business-scoped. The User account is the source of truth for an individual's personal information. A Person profile represents that individual's identity and information within one particular Business.

| | User account (personal information) | Person profile (Business-specific information) | |---|---|---| | Scope | Platform | One Business | | Potential attributes | Home address, personal email, personal telephone, date of birth, sex, ethnicity where appropriate and lawfully required, personal biography, other personal profile information | Position or role, business email, direct business telephone, department or team, business biography, other information relevant to participation in that Business | | Determination | By platform requirements and privacy considerations | By the Business's needs, under its Business-scoped access and privacy rules |

These attribute lists are illustrative. Current evidence is narrower: the Person Contact Profile Type holds only display_name, email, telephone and biography, and date of birth and sex are deliberately excluded pending a purpose, access rule and minimisation decision (PRR-057).

Principles:

Unresolved mechanisms: which User attributes may be copied into a Person profile; whether a transfer is a copy or a move; whether changes to User information automatically update linked Person profiles; whether the User must explicitly authorise disclosure of particular attributes; how deletion, retention and privacy requests affect copied information; and whether the link is a Relationship, a reference or another existing mechanism (the declared Relationship Type c2000000-...-0106 is inert and cannot yet have a platform-scoped endpoint, PRR-059). Recorded as PRR-066.

<a id="principal-profile-and-account-control"></a>

User Profile and Account Control

The persisted profile described here belongs to the User account. Business-specific information about the same individual belongs to a Person profile (see above) and is never implied by the User profile.

Definition-driven User initialization (the legacy principal_initialization workflow) may configure only authorized profile constituents. Credentials, confirmation verifiers, session material and verified authentication associations remain in their protected boundaries. The initialization workflow does not create authority: Membership, AuthorityGrant and Policy continue to be resolved explicitly at the governed mutation boundary.

The authenticated User profile is a projection and mutation surface over the existing User identity, not a second account or profile data model. The User remains the typed universal object (legacy Type name Principal) and, when a Business context is selected, its self Object resolves through the canonical /objects/{user_id} pipeline. Its initial profile value may contain the required display_name and approved personal display fields such as given/family name; these are ordinary typed values, not credentials. The verified email address remains in the protected identity boundary (principal_identities, legacy table name), outside the User value, because it is security-sensitive identity state with uniqueness, confirmation and authentication semantics. It is shown as a read-only verified identity until a separately approved email-change/re-verification operation exists.

An optional profile image is represented by a typed reference to an addressable Media/Asset object. Binary bytes, storage names, processing metadata and access decisions remain in the protected media boundary; they are not embedded in a generic primitive and a public URL is not authority. The reference may be removed or replaced only by the authenticated User through the normal mutation path, with authorized reads, safe rendering, replacement cleanup and provenance. The image object must not expose credentials or become a route around Business isolation.

Profile edits use an approved User-profile Operation and the existing Command -> Validation -> Authority/Policy -> Commit boundary. The server resolves the User from the authenticated session; the browser cannot choose another User, identity, Business, media owner or security field. At minimum, display-name edits and image attach/replace/remove are self-service mutations. Each successful revision records actor, target, before/after references, exact Operation revision, Command, result and relevant media provenance; rejected and failed Attempts remain distinguishable. Validation covers required/length limits, Unicode normalization policy where selected, media size/type/content checks and ownership/accessibility of the referenced image.

The authenticated shell exposes one persistent User account control in the top-right area. It shows the profile image when authorized and available, otherwise an accessible deterministic fallback, plus appropriate display information. Its menu links to the User profile and submits the existing CSRF-protected logout action. It is the single account control for profile and logout; it is not a Business selector or an authority grant. Keyboard operation, focus management, responsive overflow and unauthenticated omission are presentation requirements owned by views and content and UI system.

Permission, Scope and Ownership

Permission evaluation concerns an identified User, requested action, target objects/types/relationships, business/isolation context and applicable authority. State, relevant configuration, time and required approvals can also affect admissibility.

For an external Action without a local business-object mutation target, authorize the governed Operation identity rather than inventing a target Type or authorizing a generic Communication Connection. The existing Business authority model requires active Membership in the exact Business, an active AuthorityGrant matching the Operation name and Operation Type and containing the exact Operation Object ID, and a matching active allowing Policy for that same Operation identity and name. A broad-only grant or Policy, a mismatched Operation identity, missing or conflicting authority, revoked Policy, or another Business's membership does not authorize execution. The Operation Contract and its reference do not grant permission. Admission-time authorization is not an execution token: resolve the exact current Operation revision and recheck its availability, Membership, Grant and Policy at the Command execution/commit boundary. A superseded or stale Operation revision is rejected rather than silently rebound. No Connection Type or parallel Action authorization system is introduced.

Scope must support the distinctions needed by the business: permission to define a type is not permission to change every instance, and permission to read a Person does not automatically permit traversing private relationships or changing their Organisation.

Useful action distinctions include reading, creating, updating, ending/deleting, relating, configuring, executing, approving, publishing, sharing and exporting. This is not a frozen permission vocabulary; approved types and operations must expose meaningful authority requirements.

Authority may eventually be constrained by the operation, object or capability scope, quantity, duration, approval context or other explicit conditions. This is an exploratory direction for governed grants and Policy evaluation, not a final quota model, subscription tier, pricing rule, remaining counter or universal access matrix. For example, a proposal to permit three campaign actions is illustrative of a bounded condition only; it does not establish a fixed campaign limit or free-plan behavior.

Business ownership, responsibility and permission ownership are related but different. A project may belong commercially to a customer, be assigned to a coordinator and be governed by a separate access policy. Those meanings must not collapse into one unrestricted owner flag.

Any ownership-based grants or inheritance through types and relationships must be explicitly defined. The direction does not assume that all children inherit access, that the creator has permanent control, or that a privileged role can bypass every constraint.

Typed validity and permission are independent checks. A schema-valid change can be unauthorized; an authorized person can submit invalid data. A satisfied business goal cannot grant access or override an applicable constraint.

Where authority cannot be established, the operation must not proceed on an invented grant. Apply the settled Policy composition and conflict contract, with an authorised human determination when no defined deterministic rule resolves the case.

Identity and Permission Responsibility

The Identity/Permission responsibility supplies consistent identity, access and governance decisions across capabilities. It is not a prescribed class, module, authentication provider or separate service.

| Contract aspect | Required concern | |---|---| | Inputs | User/authentication context, relevant membership, isolation context, action, target references, applicable configuration and required approval context. | | Identity and access | Establish attributable identity/context and evaluate authority for supported operations on objects, types, relationships and executable capabilities. | | Configuration changes | Control membership, permission and ownership/delegation changes through the same validity, authority and audit boundaries as other consequential configuration. | | Outcomes | Return a usable authorization result or an explicit unresolved/denied condition without leaking protected information in the explanation. | | Enforcement | Require successful checks at the point that controls data access or effects; a prior UI check, event or AI suggestion is not an authorization token. | | History/events | Make consequential access and authority changes attributable with relevant source, approval and temporal context. | | Failures | Refuse unsupported or unauthorized operations and surface missing context, invalid declarations and unresolved governance conditions through controlled errors. |

Permission declarations use objects and types; their business meaning references Policies and constraints. Explicit governed composition determines their combined effect. Where no defined deterministic resolution applies to a conflict, an authorised human Decision is required; the operation cannot proceed on invented authority.

Decisions must remain valid for the context in which effects occur. The commit mechanism rechecks authoritative versions, revocation and dependencies while serializing governance changes; implementation must not silently reuse stale authority as an unlimited grant.

Approval and Delegation

An approval is an authorized determination that a specified proposal or action may proceed within its stated scope and conditions. It is not the action itself, a global permission grant, or evidence that execution succeeded.

Approval must be connected to an identifiable proposal/change, the approving authority, relevant business context and recorded determination. A rejection, a pending request and an executed result must remain distinguishable. Semantics owns the broader Decision concept.

The approver needs authority to approve the relevant scope; a person who can draft a campaign or workflow does not necessarily have authority to publish or activate it. The required separation of requester, approver and executor depends on approved governance, not a universal role scheme invented here.

If the proposal, Policy, underlying facts or execution context changes after review, the platform must not assume approval covers the new situation. Re-evaluate the approval's explicit scope, relevant versions, conditions and expiry at commit; obtain a new determination when the changed operation is not covered. An approval does not remove type validity or other Policy requirements.

Delegation is an explicit addressable authority arrangement identifying delegator, delegate, authority delegated, scope, effective period, conditions/restrictions and governing provenance. The delegate obtains no more authority than explicitly delegated and no more than the delegator may delegate. Delegation cannot bypass Policy or authentication assurance. Onward delegation requires explicit authority; it is never implied.

Keep the original authority grant context visible and attribute the actual actor. A runtime worker records the delegated business authority chain, which identifies the User whose authority applies, and separately records its own technical identity as execution provenance only; the worker is never an authority subject. See Delegated Authority For Automation for the proposed succession behaviour and its open questions. Delegation can be revoked, expire or become inapplicable through governed addressable state transitions. Historical Actions performed under valid delegation remain historical occurrences; later revocation does not erase their authority evidence.

Example: Stu delegates ApproveProject to Manager within an explicit scope. Decision D91 records Actor: Manager; Authority: delegated ApproveProject; Delegated by: Stu; Technical executor: Worker-17. The record neither impersonates Stu nor gives Worker-17 or Manager permanent ownership of Stu's authority.

Workflows and automation owns requesting and waiting for approval and executing approved actions; views and content owns review presentation. Neither owns a competing definition of approval.

Risk and Autonomy Configuration

Autonomy levels are a configuration dimension governing how much action a User-delegated automated process may undertake without a new human determination in the applicable context. They are not hard-coded product tiers or an intrinsic privilege of AI.

No universal tier names, numeric risk ladder or automatic execution grant is inferred. The initial implementation permits only explicitly configured operations and requires recorded human determinations for proposal acceptance or unresolved Policy conflicts. Configuration parameters implement the settled authority model; absence of a tier catalogue does not reopen it.

Governance configuration may need to express allowed action scope, approval requirements, relevant constraints and risk context. Consequences, external visibility, reversibility and sensitive information are considerations for human risk design, not an already-approved scoring model.

An automation operating within an agreed scope may eventually be permitted to perform bounded actions; a significant business-model change normally requires a reviewable proposal. The exact boundary between these cases must be decided, not inferred from whether an action was suggested by AI.

Autonomy never removes type validation, isolation, authority or audit obligations. A high-confidence recommendation is not a permission, and a goal to improve efficiency does not authorize changing business policy.

Changes to autonomy or approval configuration are themselves consequential configuration changes requiring appropriate authority and traceability. Do not let a workflow or model raise its own privileges by editing the rules that govern it.

Consequence and Reversibility

Operations are not equivalent merely because they technically change data. Governance should distinguish reversible internal state changes, consequential internal changes, externally consequential actions and irreversible operations when determining whether an action may execute automatically, should produce a proposal, must create a workflow decision or requires explicit authorization and additional provenance.

Examples of externally consequential operations include sending communication, publishing content, submitting an order, modifying an external system or initiating a transaction. The applicable operation and integration contracts own the precise effect and recovery semantics. This document owns the governance requirement that consequence, external visibility, reversibility and sensitive context inform authority and approval decisions without creating a universal risk score or fixed tier catalogue.

An approval authorizes a scoped proposed action; it does not prove that the effect occurred. Reversible or low-risk automation may execute when explicitly permitted, while consequential, irreversible or uncertain work remains subject to the applicable approval, commit, Attempt, Outcome, reconciliation and provenance boundaries.

Authorized AI and Automation

AI has no independent authority merely because it can generate a plausible action or configuration. The platform must authorize and validate an AI invocation and its context before execution, and validate and authorize proposed outputs before they cause business effects.

The governed path must cover these distinct checks, without prescribing a particular transaction implementation:

1. Identify the initiating User (or the User whose delegated authority the automation or integration uses), business/isolation context and requested operation, whether initiated by a human, event, schedule or integration. 2. Establish permission to invoke the configured capability or AI action, validate its supported inputs, and satisfy any required approval before invocation. 3. Retrieve only authorized information and restrict provider/tool access to the permitted purpose and context; an instruction inside retrieved content does not grant authority. 4. Treat returned text, content, classifications, knowledge or configuration as untrusted/proposed input with its source and derivation recorded. 5. Validate proposed typed values, relationships, references and supported actions, including applicable business constraints and lifecycle requirements. 6. Establish action authority, risk/autonomy conditions and any required human approval for applying the proposal; authorization for the original AI call is not approval of arbitrary resulting changes. 7. Execute only through the controlled runtime and record the attempt, result and relevant decision/provenance context. Failed, rejected and unexecuted proposals must not appear as successful changes.

Provider responses must not directly rewrite arbitrary runtime code, install new engine behavior or bypass validation. The AI owner governs optional inference and provider boundaries; this document owns authority for its use.

The same controls apply to deterministic automation and human-authored configuration. Every scoped business capability must remain operable without AI, including human editing, review, approval, retrieval and ordinary execution. Provider failure must not turn into permission escalation or loss of the manual operating path.

Shared-Model Governance Examples

The following are illustrative typed objects and connections, not a selected identifier format, field schema, role library or policy precedence rule:

| Address and semantic type | Example typed content and connections | |---|---| | membership/alex-business, type Membership | Relates an authenticated User to an explicitly authorized business/access context, with source and relevant applicability dates. It is not implied by a Person-to-Organisation contact relationship. | | permission/review-service-plan, type Permission | Describes a bounded review action and applicable target type/context; does not implicitly allow editing membership or publishing unrelated content. | | policy/service-plan-review, type Policy | Links business intent, source knowledge and relevant approval requirements under the meanings in semantics. | | proposal/service-reminders, type ConfigurationProposal | References the proposed workflow change, affected business context and evidence; it remains separate from active configuration. | | decision/service-reminders, type Decision | Records a hypothetical authorized approval or rejection of that proposal, with authority and rationale. Execution has its own result and history. |

Each independently addressable item follows id + type + value, with type definitions themselves addressable. Membership, permission and decision relationships participate in the same Business Graph; governance does not create a separate foundation.

Audit and Trust Boundaries

Consequential operations must be explainable: who or what acted, in which context, on what subjects, using which relevant authority/configuration, with what approval and result. Rejected or failed attempts need the audit coverage selected for their risk and operational purpose, without collecting secrets as evidence.

Time and events owns events, versions, recorded/effective time and causal history. Audit evidence is not simply a notification or activity feed. Access to historical authority and Decisions is controlled; operations specifies initial retention and access controls without implying a universal legal retention duration.

Operational enforcement must preserve authentication and session security, CSRF verification for state-changing browser requests, parameterized database access, safe output encoding/rich-content sanitization, validated uploads and protected credentials. Existing PHP sessions are neither mandated nor prohibited by this architectural direction.

Scope uploaded content by authority; validate size and server-detected type and avoid trusting submitted storage names. Keep secrets out of source control, generic exports, AI prompts, ordinary business data projections and unredacted logs. Imported content, webhooks and provider output cross trust boundaries and must be validated.

Security and operations owns concrete mechanisms and operational checks. Implementation architecture owns the selected runtime/persistence realization. Reusing old security lessons does not impose old client/admin assumptions, stack choices or deployment commitments.

Human-Operated Conformance

Nonconforming examples include trusting browser-selected tenancy, treating hidden UI controls as security, using a fixed "admin bypass" without an approved contract, granting access from a business role alone, or silently executing AI output because it appears schema-valid.

Implementation and Evidence

D01-D10 are settled; their identity, authority and delegation contracts apply regardless of implementation depth. Implementation architecture specifies sessions, explicit Business membership, bounded grants, Policy evaluation and commit-time enforcement. Development requires negative tests for unauthorised mutation, graph-only authority, revoked delegation, conflicting Policies and forged AI authority. Status records the absence of new-runtime evidence; old login screens do not verify this contract.

Platform Governance Foundation Mechanism

The initial runtime uses one explicit scope abstraction with mutually exclusive platform and business values. Platform AuthorityGrant objects bind directly to a User (legacy Type Principal) with no Membership or Business; platform Policies have no Business and are resolved only at platform scope. Business Membership, grants and Policies remain Business-scoped. No authority inheritance exists in either direction.

The approved business.create capability is an exact platform Operation dispatched through the trusted handler registry and the single CommandHandler. The handler generates the Business, Membership, grant and Policy identities; callers cannot supply those identities or an effect plan. Its initial Business governance includes one Business-scoped allowing inspection grant/policy for platform.inspect_foundation targeting only the Business Type, and one Business-scoped allowing configuration-install grant/policy for platform.install_configuration targeting TYPE_OF_TYPE. The former operation means ordinary governed Business-scoped object inspection, not Genesis inspection. These effects do not grant arbitrary Type inspection, credential or platform inspection, traversal, unrestricted mutation, cross-Business access or platform administration.