Skip to documentation
Browse documentation

Organizational governance

Projects and accountable ownership

Record who is responsible without silently granting execution or financial authority.

AvailableIn DevelopmentImplementation review · November 6, 2026
In this document

Register a purpose and an owner#

A project has a stable identity, a name and purpose, and one accountable current tenant member. Technical, governance, sponsor and finance responsibilities can be recorded separately. These fields explain responsibility; they are not new permission roles.

The registry initially represents draft projects. Managers can manage the tenant's records, while responsible members have scoped read access. A project record does not prove that its workload is observed, governed or permitted to execute.

Bind declared scope carefully#

An application/environment reference connects a project to a known workload. Revision checks prevent a stale editor from silently replacing newer changes, and the service and database enforce the supported uniqueness rules. Changes are retained in append-only history.

An exception response can refer to actual original assessment evidence and record an accountable owner, status and supporting response. Closing that record does not rewrite the finding or turn a past BLOCKED or HELD result into a release.

Treat execution authorization separately#

The project execution mechanism is In Development and default-off. Its controlled payload flow separates owner acknowledgement, an independent authorized officer's approval and manager activation. The subject pins exact project, workload, policy, authority and membership revisions for a bounded period.

Changing a pinned revision can require reassessment. Suspension, expiry, revocation or lost authority holds the enrolled application. Removing enablement does not restore legacy fallback. The current qualified boundary is deterministic payload sanitization, not general agent orchestration.

Read event-time accountability#

Where a supported execution records project context, the evidence preserves the context at the event time. Later owner or policy changes do not rewrite the historical record. Legacy decisions without this context remain unattributed; the system must not assign them to today's owner by inference.

D03 · Scope and accountable ownership

Organization, project, workload and exact policy references constrain interpretation; inventory alone never grants permission.

Registry is implemented; project execution authority is default-off and limited to payload-sanitize-v1.

Organization, project, workload and exact policy references constrain interpretation; inventory alone never grants permission. Registry is implemented; project execution authority is default-off and limited to payload-sanitize-v1.
Read the diagram description

Organization, project, workload and exact policy references constrain interpretation; inventory alone never grants permission. Registry is implemented; project execution authority is default-off and limited to payload-sanitize-v1.

D18 · Permission, content and final release

Execution authority, content policy and final publication are separate gates; a hold never becomes permission through a UI override.

Current supported boundaries; public teaching simulations do not resume real effects.

Execution authority, content policy and final publication are separate gates; a hold never becomes permission through a UI override. Current supported boundaries; public teaching simulations do not resume real effects.
Read the diagram description

Execution authority, content policy and final publication are separate gates; a hold never becomes permission through a UI override. Current supported boundaries; public teaching simulations do not resume real effects.