Enterprise model access development preview

Work brought from the former 0.67 branch into the planned 0.71.0 release includes member model discovery, source creation and editing, protected inspection, bounded scalar calculation and a governed record workspace in the selected enterprise service. This remains an unshipped development preview. The workspace includes staged uploads and verified historical attachment downloads. Configured record review now includes browser submission, independent decisions and attributed history. Signature profiles, richer execution profiles and complete planning workspaces remain under development.

Record storage foundation

The native storage library now supports explicitly enrolled tables with version-checked create, update and tombstone commands. The selected enterprise service exposes this storage through current View/Edit permissions, signed audit, a fixed Node facade route and a browser workspace. Ordinary tables are not automatically enrolled.

For example, two inventory editors may both start from record version 3. Once one command commits version 4, the other receives a conflict identifying version 4. Retrying the successful command with the same identity and content returns its saved result without another edit. Reusing that identity with different content is refused. A tombstone removes the current row while retaining its versions and before/after history.

The storage transaction includes affected rows, record versions, attributed history, retry outcomes and the existing durable table change notification. Required columns cannot be absent or null, and declared unique indexes still apply. Declared record links must refer to live enrolled records in the same model. Referenced records cannot be retired while a live link remains. Ordinary source and bulk writes cannot change an enrolled table. The native service creates a table and enrolls it atomically; an exact repeat accepts the same descriptor without changing its schema. It refuses to convert an existing ordinary table or change an enrolled schema. The storage library also supports explicit enrollment of empty ordinary tables. This profile caps each command at 32 changes and 64 KiB, each record's encoded fields at 16 KiB, and history pages at 16 versions. It retains at most 100,000 commands per model before refusing further writes; it does not silently discard old history.

The storage library now supports versioned attachment references and immutable historical retention roots. It requires a host verifier before accepting a new reference, limits each record to eight attachments of at most 16 MiB each, and retains at most 4,096 distinct attachment identities per model. Detaching an attachment or retiring its record preserves historical references. These storage contracts now connect to the native/facade endpoint through current permissions, signed audit and guarded replies. The selected owner provides resumable staging, history-driven recovery and garbage-collection retention. The browser supports explicit upload, attachment changes and verified downloads. Configured record review connects the native/facade service to browser controls. Populated-table migration remains unfinished. This storage foundation does not establish an approved-plan or healthcare workflow, deployment qualification or measured performance guarantee.

Use the record workspace

Open My models, choose a project and model, then select Records after the source view loads. View permission allows table and record navigation. View plus Edit allows table creation and record changes. Administration alone does not grant either permission.

1. Choose Create record table, name the table and declare its fields. Names start with a letter and contain letters, numbers or underscores. Choose a scalar type and, where needed, a unit, Required or Unique. Link to record table declares a checked record reference to an enrolled table in the same model (or to the table being created). Link fields use Text with no unit. This profile keeps the schema fixed once created; it does not adopt populated ordinary tables.
2. Open the table and choose New record. Enter values and a reason. Optional fields have an explicit No value choice, which differs from empty text. The browser refuses whole numbers outside JavaScript's exact integer range (−9,007,199,254,740,991 through 9,007,199,254,740,991) rather than rounding them. Native type and uniqueness checks still own acceptance.
3. Open a record to see its version, actor, timestamp, reason, command reference and before/after values. Previous version and Next version inspect immutable history. Historical versions cannot be edited.
4. Edit record submits the displayed version as the expected version. If another writer changed it, the stale draft is cleared and the conflict names the current version. Reload records obtains the current state before a new edit; the browser never overwrites it automatically.
5. Retire record requires a reason and an explicit confirmation. It removes the active row while retaining history. This profile does not restore or edit retired records.

If a save response is lost, the browser clears the visible draft and offers Retry same change. Only that explicit action resends the same command identity and payload; the native service returns its saved outcome when already committed. No automatic mutation retry occurs. The bounded pending request stays only in memory while that view remains open. Leaving the view, refreshing the session or signing out discards it. Record the displayed command reference and inspect current history before preparing another change when the outcome is uncertain. Reload records also discards the pending retry.

Record lists show up to 64 stable record identities and versions per page, including retired records. Open a record for its field values. Schema and exact history revisions are assembled from at most eight bounded chunks and checked against one document hash and model binding before display. No record content, draft, retry or authority is saved in local or session storage. Reads occur on navigation; this workspace does not poll.

Record backup/restore and complete live acceptance still require integration. The browser review controls described below support saved-version submission and independent decisions. There is no hosted-service availability claim.

Checked record links

Create the target table first, then select it under Link to record table while declaring the referring table. In a linked field, enter the target's record ID from its record list. The ID must identify a live enrolled record in this model. Optional link fields can use No value; Required links cannot. Unique also applies to link fields when selected.

For example, an Orders.item field can link to a record in Inventory. Saving an order that names a missing or retired inventory record returns a link conflict and changes nothing. Retiring referenced inventory also returns a conflict that identifies a live referring record. Remove that live reference (or retire the referring record) before retiring its target. These are rejected changes, so the browser asks for correction/reload rather than offering an ambiguous-save retry.

The check and link projection commit with the command's rows, versions, history and outcome. A batch is checked against its final state, so clearing a link and retiring its target in the same table does not depend on operation order. Self-links and cycles between live records are allowed. Commands still target one table; cross-table changes use separate commands and never expose a dangling committed link. Concurrent linking and target retirement cannot both succeed.

History preserves the original linked ID after a live link is cleared. Links identify records, not a pinned target version; inspect the target's history for past values. Planning snapshots that require exact input versions still have to pin those versions. This does not add cross-model references, multi-valued link fields, automatic cascading deletion or automatic target-record selection.

To declare Orders.item through the native or facade route, use this operation inside the same source-bound request envelope shown below:

{
  "kind": "enroll",
  "table": "Orders",
  "columns": [
    { "name": "item", "logicalType": "text", "unit": null, "unique": false, "required": true, "linkTable": "Inventory" }
  ]
}

linkTable is optional and is omitted for ordinary scalar columns. It cannot be null or point to an ordinary/unregistered table. The immutable schema document includes a links map only when links are declared. Link refusals return result.kind: "linkConflict" with a missingTarget or referencedTarget conflict; the full command remains uncommitted. Existing schemas and commands without links retain their wire representation.

Attach and download files

Open the latest active record. With View and Edit permission, choose one file under Choose attachment, then select Upload file. A file can contain up to 16 MiB; a record can reference up to eight files. Uploading verifies and stages the bytes. It does not change the record. Enter a Reason for attachment change and choose Attach uploaded file to commit a new record version. Concurrent changes are refused using the displayed record version. An uncertain save offers Retry same change, retaining the same command without uploading again.

An interrupted upload offers Resume upload for the same file while this view remains open. The service reports the durable prefix and checks repeated bytes. Stop transfer cancels browser work; it cannot undo work already accepted by the service. Discard upload explicitly releases unfinished staging. No failed network request is retried automatically.

Unfinished uploads lists upload references retained in memory for this model. Navigation away from a record cancels active transfer and clears its file bytes, but retains these references until the model/session view closes. Discard unwanted entries before leaving. If cleanup is uncertain, keep the reference: after reopening the model, use Discard an upload by reference. The native owner allows only the current member's unfinished upload in that model. Nothing is saved in browser local/session storage. Clean up unused upload files reclaims unreferenced artifact storage after cancellation; it preserves staged uploads and all historical attachments. There is no automatic upload expiry.

Choose Download beside an attachment in the exact revision you want. Download requires current View and Export permissions and an approved destination, as described below. The browser checks every page's identity, complete length and SHA-256 digest before showing Save verified file. Choose that link to save the file with its original name. Uploaded HTML and SVG are downloaded as bytes, never rendered inline. Partial downloads are unavailable; stopping or leaving clears partial buffers, and leaving revokes any prepared save link.

To remove a current attachment, enter a reason and choose Detach. This creates a new record version while retaining the earlier file. Use Previous version to inspect and download it. Historical versions have no attachment edit controls. Full-size transfer performance, production browser/native/provider integration and the broader review workflow remain unqualified.

Attachment service development contract

The browser and native/facade clients use the existing record endpoint for attachments. Each operation uses the same current security revision, model ID and source-hash envelope as record commands; neither actor nor sensitivity may be supplied by the client.

1. Choose a fresh 32-character lowercase hexadecimal uploadId. Submit uploadBegin with that ID and a declaration containing fileName, mediaType, byteCount and the complete file's lowercase SHA-256 sha256. The file is limited to 16 MiB; each model permits eight unfinished uploads.
2. Submit uploadChunk with uploadId, sequential byte offset and canonical dataBase64. Each decoded chunk is at most 48 KiB. Exact chunk retries are safe, including an identical prefix retained before interruption. Gaps and different overlapping bytes are refused. uploadStatus reports receivedBytes; it also requires current View and Edit.
3. Submit uploadFinish with the ID. The owner verifies the complete size and digest and returns result.kind: "uploaded" with an immutable attachment reference. Verify the returned file metadata against the declaration before using it. Repeating finish before record commit returns the same reference.
4. Submit a version-checked record command with this operation:

{
  "kind": "setAttachments",
  "recId": "rec00000000000001",
  "expectedVersion": 1,
  "attachments": []
}

The array is the complete intended set, up to eight references returned by uploadFinish or already present in this model's history. The empty array shown above detaches every current attachment. Use the actual record ID and version. The outer command still requires table, commandId and reason. Retain the exact command for an explicit retry after an uncertain response. Detachment or retirement preserves historical references and bytes; history documents add optional attachmentsBefore and attachmentsAfter arrays.

uploadCancel releases an unfinished upload owned by the current member. collectAttachments takes dryRun and reports retained/removed record counts and reclaimable/reclaimed bytes. Both require View and Edit. Collection respects all historical roots; it does not discard record history. No automatic upload expiry or background collection is enabled.

For a download, submit attachment with table, recId, exact historical version, artifactId and byte offset starting at zero. The response is attachmentBytes, with the same identities, complete content sha256, totalBytes, current offset, nextOffset and at most 8,192 decoded bytes in dataBase64. Continue until nextOffset is null; pin the model binding, sensitivity, identities, digest and length across pages, then verify the assembled file before making it available. Empty files have zero bytes and no continuation. Leaving the operation must discard partial content.

The disclosure policy must explicitly register browser-download:<configured browser origin> on the Download channel, permitting the record-attachment purpose, Identified mode and the model's sensitivity. For Care Operations models, the runtime selects care-operations and requires the additional identified-care export grant. These values come from native configuration/model authority; a request cannot choose another destination, purpose or weaker classification. Unregistered destinations are refused, even with Export. This does not add an administration UI for destination registration. Every page rechecks current permission and policy; revocation suppresses pending publication. Sensitive values and file names are excluded from audit text.

The native reader verifies the complete file when preparing a page-hash index, then reads and verifies each requested range against that proof. The selected owner retains at most eight indexes across models, holding hashes and bounded identities rather than file bytes or permission decisions. Eviction or restart requires complete verification again. Every request still checks the exact historical reference, current metadata/sensitivity, committed visibility and private storage paths, as well as the native permission/disclosure boundary. Unaligned requests verify both intersected blocks. A corrupt requested block is refused; corruption elsewhere is detected when that range is read. The browser also verifies the assembled whole-file digest before offering a save link.

Complete transfer performance, per-page audit/storage-scan costs and accepted budgets still require evidence. This is not a throughput or full-workflow completion claim.

Review a record version

Open a record's history and choose Review this version. This explicit action loads the deployment's configured review eligibility and the journal for that exact version. There is no review polling or automatic submission. If review is not configured, historical journals remain readable and new actions are absent.

• For a live latest version with no journal, enter Reason for review and choose Submit for review. Submission requires current View/Edit permissions and the configured author roles.
• For a submitted latest version, an independent human with View/Approve and an eligible review role can Approve record version or Reject record version with a reason. Reviewers do not need Edit permission. Direct-role eligibility is advisory: the native service checks actual authority and every contributor when saving, including delegated role origins.
• If your administrator supplied an eligible delegation, enter its exact Delegation reference. Leaving this empty selects your direct roles. The review form cannot create a delegation or choose a different policy. An expired, revoked, author-derived or service-derived review delegation is refused.

The journal shows submitted/approved/rejected status, actors, reasons, times and selected delegation origins. Review identity and contributors expands the exact subject, model-source and policy-manifest hashes and contributor list. The record's fields and retained attachments remain in the surrounding revision view. The browser verifies all bounded pages before displaying journal contents; partial or changed pages are discarded.

Historical versions have no action controls. A source replacement makes the old journal explicitly historical, even when it says the old record was approved. Approval covers the submitted record, retained attachments and source identity; it does not approve the complete model, linked-record contents or a planning scenario. To reconsider a terminal decision or changed source/policy, create a new content revision and submit that draft under current authority.

If a decision cannot be confirmed, Retry same review change sends the same in-memory request and command ID. It never silently creates a second decision. Reload review history explicitly abandons that pending request and loads the current journal before another decision. A confirmed save followed by a failed history read is reported separately. Navigation, source/session changes and sign-out abort pending browser work and retire the panel; cancellation cannot undo a native commit that already happened. Keep the displayed change reference if leaving before its outcome is confirmed. No review draft or journal is written to browser storage.

These controls have local browser tests and shared native-serialized/replayed journal fixtures. The complete live identity-provider/browser/native journey, group/policy administration, signature-required profiles, full planning approval and quantitative performance acceptance remain outstanding.

Manage review roles and delegations

Your roles shows your own direct role assignments and roles inherited from groups. Inspect delegations lists loans involving your account, including expired and permanently revoked entries. Delegated roles shows a loan's exact roles. These views expose scoped security metadata, not model contents or credentials. Ordinary members cannot inspect another account's directory entry.

A security administrator can open Accounts, choose an account's Roles, and use Assign direct role or Remove direct role. Supply the exact policy role and a reason, review the proposed change, then confirm it. Project administration alone does not grant this organization-wide authority. A role does not grant project membership, model View/Edit/Approve permissions, a human account kind or permission to change the selected workflow policy. Assign those separate permissions explicitly. An account must be enabled before receiving a new role.

For example, this request to /api/enterprise/administration/change assigns the review role to a previously enrolled account. Replace the revision with the observed current security revision and use the role required by your selected policy:

{
  "schemaVersion": 1,
  "expectedRevision": 42,
  "command": {
    "kind": "setGovernanceRole",
    "actorId": "inventory-reviewer",
    "role": "record-reviewer",
    "enabled": true,
    "reason": "Inventory review staffing"
  }
}

To lend roles temporarily, open the lending account's Delegations, choose Create delegation, and supply a new reference, receiving account, unique roles (one per line), time window and reason. The form accepts local times and displays the exact UTC window in confirmation. Both accounts must be enabled, the end must be in the future, and every lent role must currently belong to the lender directly or through a group. Borrowed roles cannot be lent onward. This metadata cannot turn a service account or author-derived authority into an independent human reviewer; the record service checks those constraints at the actual decision.

A member selects the saved reference in the review form when exercising a loan. The delegation listing's scheduled/expired indication uses the device clock and refreshes only on navigation; native operation time remains authoritative. No polling is added. Governance metadata uses one bounded row per browser page so maximum-length escaped identities still fit the existing 16 KiB response bound.

Delegation references are immutable and retained. Revoke delegation requires a reason and confirmation. Replacing a recipient, roles or expiry requires a new reference; an existing reference cannot be edited, deleted or reused. Removing a lender's role permanently revokes every loan that loses its authority, in the same security transaction. An independent group grant can still supply that role. Disabling either participant permanently revokes incoming/outgoing loans, and reenabling the account or restoring a role does not revive them. Historical approvals and role-origin evidence remain intact. Group grants are visible here, but group membership/role editing remains an operator-owned directory operation; removing a direct assignment does not remove an inherited group grant.

All three mutation commands (setGovernanceRole, createGovernanceDelegation, revokeGovernanceDelegation) use the existing protected administration endpoint, current native session and exact security revision. Their request—including the reason—is bound into the signed audit metadata digest; this does not add readable reason text to the audit projection. Security, access and affected governance revisions advance atomically. Prepared replies and effect permits affected by that change are retired through the existing publication guard. The UI refreshes the session and listing after a confirmed save and clears stale editors. An uncertain administration save is not automatically retried: refresh and inspect current state before preparing another change.

Direct role names and reasons allow up to 1,024 UTF-8 bytes. New delegation references allow 128 bytes, at most 1,000 unique roles and a finite millisecond window within the browser's date range, subject to the existing 96 KiB request bound. The directory retains at most 100,000 delegations and revocations and refuses capacity overflow rather than deleting history. Native unit/controller and browser tests use synthetic identities; they do not establish live company identity-provider integration, independent assurance or a performance budget.

Configured record review service

An operator may select recordReview in the trusted enterprise startup configuration. Omitting it, or using null, disables review mutations. The selector names one installed catalog entry and its exact workflow/governance artifacts; the browser cannot choose a different policy:

{
  "recordReview": {
    "catalogPath": "/var/lib/grid/domain-packs/catalog.json",
    "packId": "company-records",
    "packVersion": "1.0.0",
    "manifestSha256": "0000000000000000000000000000000000000000000000000000000000000000",
    "workflowId": "review-record",
    "governanceId": "record-governance"
  }
}

Replace these illustrative identities and the all-zero digest with an actual verified installed package. Startup verifies the complete catalog through the existing Domain Pack loader, compiles the exact policy and retains that immutable definition before opening or reconciling durable enterprise owners. A configured missing, mismatched or unsupported policy refuses startup. Later catalog-file edits do not change a running process's policy; a restart admits the configured bytes again. Historical reviews remain readable if review mutations are disabled.

This profile supports one human step and one reason-required independent decision with quorum one. Signature-required, machine, rollback, release-evidence and redaction policies are refused rather than weakened. Accounts need the real workflow roles in the governance directory as well as model permissions. Security administrators can now assign direct roles and create/revoke bounded delegations through the account screens described above. Group grants and the selected workflow policy remain operator-managed.

All operations below use the current model/security/source envelope described under the native service contract. reviewPolicy reports whether a policy is selected and whether the current account has direct submission/review eligibility. It is advisory: the actual decision also checks the exact submitted subject, contributors, selected delegation and current authority.

A submission uses this operation (replace the example IDs and version):

{
  "kind": "reviewCommand",
  "table": "Inventory",
  "recId": "rec00000000000001",
  "commandId": "inventory-submit-001",
  "reason": "Ready for independent inventory review",
  "expectedVersion": 3,
  "expectedReviewSequence": 0,
  "expectedSubjectSha256": null,
  "delegationId": null,
  "action": "submit"
}

Submission requires View/Edit and the policy's initiating/human-step roles. The reviewed response gives the exact subjectSha256 and review sequence 2. An independent reviewer uses a new command ID, action approve or reject, that same content version and subject digest, review sequence 2, and a reason. A decision requires View/Approve and the policy's eligible review role; Edit is not required. A successful decision returns review sequence 3 and approved or rejected. The content version does not change merely because review advances.

A client may select a delegation ID already present in the trusted directory; it cannot provide actor identity, roles, human-account claims or policy bytes. Current directory evidence and actual account kinds govern the operation. The reviewer and all eligible role origins must be active human accounts. Every prior content/attachment writer and submission authority is excluded, including an author's delegated role even when the recipient also holds it directly. Delegation expiry bounds the commit and response-publication window.

review reads a journal by table, record ID, content version and byte offset. It returns the existing bytes reply shape with document kind review: at most 8 KiB of decoded data per page and a complete-document hash. The complete JSON is bounded at 256 KiB and is null when no journal is retained for that version. Clients must keep one identity/hash across pages and verify the complete document before using it. Historical source and content coordinates remain explicit; an old approved journal or retry receipt cannot authorize current changed data.

Review commands verify every retained attachment and commit the immutable subject, existing-workflow events, retry receipt and durable notification in one model transaction. Current source/session/permissions, signed intent/completion audit, the archive allowance and commit/publication fences surround the action. Restart marks unfinished audit attempts as interrupted without replaying them; an uncertain caller may explicitly retry the exact command under current authority. A changed policy/source requires a new draft, not relabelling an old approval. Full scenario approval, signature profiles, group/policy administration controls and quantitative review cost acceptance remain outstanding.

Native record service contract

The selected native control endpoint is POST /internal/runtime/enterprise/models/records. It requires the same private facade transport proof, browser session, CSRF proof and approved browser origin as the other enterprise native endpoints. The selected Node facade exposes the same bounded contract at POST /api/enterprise/models/records; it forwards current browser proof to that fixed native endpoint. Requests cannot supply actor identity or a database path. There is no generic table-RPC fallback.

Every request carries the current security revision and committed source hash. Record reads require View; table enrollment, record commands and upload operations require both View and Edit. Attachment downloads additionally require Export and an exact registered disclosure destination. For example, a native service client can prepare an inventory table with:

{
  "schemaVersion": 1,
  "expectedRevision": 2,
  "modelId": "forecast",
  "expectedSourceSha256": "0000000000000000000000000000000000000000000000000000000000000000",
  "operation": {
    "kind": "enroll",
    "table": "Inventory",
    "columns": [
      { "name": "item", "logicalType": "text", "unit": null, "unique": true, "required": true },
      { "name": "quantity", "logicalType": "integer", "unit": null, "unique": false, "required": false }
    ]
  }
}

Replace the example revision and all-zero hash with the actual current binding; the service refuses stale or unbound requests. This first service profile accepts scalar column types and optional unit labels. Select choices and buttons are not admitted. Configured record review is available through this service and its fixed Node facade and the selected browser record view. A record approval does not establish a complete reviewed manufacturing or care plan, including the contents of linked records.

Replace operation with a command to create the first record:

{
  "kind": "command",
  "table": "Inventory",
  "commandId": "stock-receipt-001",
  "reason": "Received stock",
  "operations": [
    {
      "kind": "create",
      "fields": {
        "item": { "kind": "text", "value": "Widget" },
        "quantity": { "kind": "integer", "value": 7 }
      }
    }
  ]
}

Save the returned record ID and version for later updates. Exact retries retain the command ID, reason and actions; the current authorization envelope must still pass. A version conflict returns the current version; a reused command ID with different content returns an idempotency conflict. Neither conflict writes a record. An interrupted connection or refused reply is not proof of rollback: inspect the command's outcome by submitting its exact identity/content again under current permission, rather than inventing a new command ID.

The catalog operation lists enrolled tables. records takes table and a nullable afterRecId, returning at most 64 version descriptors, including tombstones. Follow nextAfterRecId until null; this is a live inventory, not a whole-table snapshot. schema takes table and byte offset. revision takes table, recId, a positive exact version, and byte offset. Schema and exact revision content arrive as at most 8,192-byte base64 chunks with a complete content hash, byte count and continuation offset. Assemble and verify the full UTF-8 JSON before displaying it. A later record edit does not alter an earlier revision's chunks. Revocation or source replacement can refuse continuation.

The service checks permission again around the database commit and protects each response write. Signed audit describes attempts and terminal outcomes without storing field values or free-text reasons. Startup marks unfinished attempts as interrupted and never replays writes; the model database owns exact retry outcomes. Each native response stays within the existing 16 KiB bound. The selected process admits at most 64 model record databases; failed openings retain their slot until restart, and further models are refused once that limit is reached.

Finding and opening a model

After sign-in, My models lists your projects. Choose Open project, then Open model. Only projects you belong to and models for which you have View permission appear. An explicit model grant set replaces the project's inherited grants. Paging counts visible entries only; it does not report hidden totals.

Manage access opens the separate administration screens. Project or security administration alone does not grant membership or permission to model contents. The same native access checks still apply when an administrator uses View model from that screen. All catalog pages require current session, browser proof, signed access audit and the response-publication fence.

The Source view displays the exact committed text and its source revision and sensitivity. It assembles bounded source pages without splitting displayed UTF-8 characters. Cell inventory lists the admitted cell identifiers without rounding large integers. Opening that view does not calculate results.

Changing the view, closing the model, refreshing the session or signing out cancels pending reads and calculations. A refused continuation discards the incomplete source. The viewer does not persist model content in browser storage or poll for updates. Previously disclosed content cannot be made unknown to its recipient.

Access, audit and changes

Each page requires the native browser session, explicit CSRF proof, the approved browser origin and the current security revision. Grid refuses stale revisions, unbound models, missing View grants and unverifiable saved source artifacts. Only the signed current source binding selects a version; the request cannot choose a filesystem path or retrieve an older retained artifact.

Signed access records precede publication. Revocation, source replacement and loss of the audit archive allowance invalidate prepared responses. The access record identifies the source and operation; it does not contain source text or credentials, and it does not prove that the browser received every byte. Responses prohibit shared caching. Errors do not echo source text or native failure details.

Bounded API example

The selected facade accepts POST /api/enterprise/models/inspect with the same session cookie, CSRF header and browser-origin checks as access administration:

{
  "schemaVersion": 1,
  "expectedRevision": 2,
  "modelId": "forecast",
  "query": { "kind": "source", "offset": 0 }
}

Use the actual current security revision. Source pages contain up to 8,192 raw UTF-8 bytes encoded as canonical base64; continuation offsets are byte offsets. The selected source profile caps total source at 65,536 bytes. The cells query returns at most 64 ordered decimal-string identifiers per page, from an admitted inventory of at most 4,096 cells. A null continuation means that page is final. Response binding metadata identifies the exact source and compiled model.

The native service uses the existing compiler, source store, session authority, audit and response-publication fence. No ordinary Runtime route becomes an enterprise bypass. Real Keycloak/AWS/Linux deployment verification and measured performance budgets remain outstanding; local fixtures establish neither.

Calculating selected cells

Open Cell inventory, select the cells you need, and choose Run selected cells. This action requires both View and Run permission. The default selection is the current page, with at most 64 cells. You can deselect cells to request a smaller result. Source inspection alone never triggers a calculation.

Results retain Grid's values and type labels, including units or currencies, and show any returned diagnostics. A result belongs to the displayed source revision; replacing the source or changing access invalidates an in-flight run. Selecting different cells clears the previous result. Cancel run, changing views, closing the model, refreshing the session and signing out cancel pending work. A failed or refused run discards its results; it does not retry automatically. Nothing is saved in browser storage.

Grid calculates with its existing calculation engine. This initial profile accepts bounded scalar workbook models; richer planning models and external effects remain unavailable here. Only one run is admitted at a time, with a five-second native operation deadline and a 16 KiB response bound. If a result exceeds the bound, select fewer cells. The deadline uses cooperative cancellation; it is not a promise of forced process termination.

Signed audit history records completion, failure or cancellation. A completed record means evaluation finished, not that the browser received its response. Interrupted runs are accounted for after restart without being repeated.

The facade accepts POST /api/enterprise/models/run, using the same session, CSRF and origin proof as inspection:

{
  "schemaVersion": 1,
  "expectedRevision": 2,
  "modelId": "forecast",
  "expectedSourceSha256": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
  "cellIds": ["9007199254740993"]
}

The hash and cell identifier above are placeholders. Use the exact source hash, current security revision and cell identifiers returned by inspection. Cell identifiers remain decimal strings throughout; converting them to JavaScript numbers may lose precision. The response binds each typed result to its requested identifier, source, sensitivity and current security revision.

Creating and editing source

Members with project View and Edit grants see Create model inside a project. Supply a model name and Grid source. New models default to Internal sensitivity; the selected source profile accepts names of up to 128 ASCII letters, digits, dots, hyphens or underscores, excluding . and ...

For an existing model, Edit source appears in the Source view when current permissions allow editing. A permitted model with no saved source instead shows Add source. The editor starts from the exact inspected source revision. Sensitivity may increase but cannot decrease. Save source compiles and commits a new immutable source revision through the existing native owner; it does not run calculations. Saving checks both the security revision and the previous source revision. Changes made by another writer therefore cause a stale draft to be refused instead of overwritten.

The source limit is 65,536 UTF-8 bytes. This preview supports the admitted scalar workbook profile; unsupported functions or richer capabilities are refused. After a confirmed save, Grid refreshes the actual current security revision. Open the model again to inspect its saved source and calculate selected cells. Drafts are not persisted in browser storage; Discard draft, navigation and sign-out remove them. Discard is disabled while saving. Leaving during a save cancels the client request but cannot undo a server commit that already happened. If confirmation fails, the draft is cleared and no retry is made automatically; refresh and inspect the saved model before making another change. Failure messages remain generic and do not expose private native diagnostics.

A member's catalog uses POST /api/enterprise/models/catalog:

{
  "schemaVersion": 1,
  "expectedRevision": 2,
  "offset": 0,
  "query": { "kind": "models", "projectId": "planning-team" }
}

Use { "kind": "projects" } to list the caller's projects. Pages contain at most four entries; nextOffset is null on the final page. Capability flags are hints for the interface, not permission tokens or promises that a source profile will be admitted. A model operation checks authority again.

Creation and editing use POST /api/enterprise/models/source:

{
  "schemaVersion": 1,
  "expectedRevision": 2,
  "operation": {
    "kind": "create",
    "modelId": "forecast",
    "projectId": "planning-team",
    "sensitivity": "Internal"
  },
  "source": "A1 = 7\nA2 = A1 * 2"
}

Replace the project and revision with current catalog/session values. For an edit, use operation kind replace, the existing modelId, the inspected expectedSourceRevision, and an equal or higher sensitivity; omit projectId. The native transaction compiles, stages and commits the source and records its identity. The browser supplies neither compiled model bytes nor authority hashes.

Exercise a separate Human workflow

The selected General enterprise API also exposes a separate Human workflow at POST /api/enterprise/models/workflows. This is an API journey; it does not add a workflow editor or change the record-review controls described above. Record review and a separate workflow retain different subjects and histories.

Use the enterprise enrollment and activation instructions on Linux Server Pro with enterprise-security. Enrollment needs the actual protected Linux roots, current OIDC provider, signing authority and archive; the local controller test fixtures are not production deployment credentials. After enrollment, the maintained service commands are:

GRID_AUTH_MODE=enterprise grid-runtime-host enterprise-http --config /opt/grid/enterprise.json
GRID_AUTH_MODE=enterprise pnpm start:enterprise --config /opt/grid/enterprise-facade.json

Before starting the native service, add optional workflows to its trusted configuration. It selects one verified installed catalog entry, separately from optional recordReview:

{
  "workflows": {
    "catalogPath": "/var/lib/grid/domain-packs/catalog.json",
    "packId": "company-records",
    "packVersion": "1.0.0",
    "manifestSha256": "0000000000000000000000000000000000000000000000000000000000000000",
    "workflowId": "review-record",
    "governanceId": "record-governance"
  }
}

These IDs and the all-zero digest are placeholders: replace them with exact verified installed identities. Startup verifies the catalog and compiles the policy before opening durable owners. Missing, changed or unsupported selected artifacts refuse startup. Omitted/null workflows disables this capability; there is no ordinary workflow-route fallback.

For the example below, the installed policy has one Human review step, initiator and step role record-author, and an independent approval policy requiring one record-reviewer, separation of duties and a reason, without a signature. Use the actual step and role names from your installed policy. The enterprise selection refuses machine/process steps, signing, publish/release, release evidence and rollback profiles. Artifact contracts, when present, must use the admitted native grid.record.attachment.v1 family.

Enroll two enabled Human accounts and assign actual governance roles through the existing administration controls. Give the author model View, Run and Edit; give the independent reviewer View and Approve. Security-administrator status does not grant model access. Delegated role origins must also be enabled Human accounts; they cannot evade the policy's separation rules. Sign each person in through the company sign-in flow. Every request uses that person's current session cookie, X-Grid-Enterprise-CSRF proof and exact approved Origin. Clients never send the native facade bearer or choose actor/role/policy fields.

Create and inspect a General model as described above. Take expectedRevision from current session/security state and expectedSourceSha256 from its actual committed source binding. Send this envelope to the fixed enterprise route:

{
  "schemaVersion": 1,
  "expectedRevision": 2,
  "modelId": "forecast",
  "expectedSourceSha256": "0000000000000000000000000000000000000000000000000000000000000000",
  "delegationId": null,
  "operation": {
    "kind": "start",
    "runId": "inventory-review-001",
    "branchId": "main",
    "inputs": []
  }
}

Replace the revision/hash placeholders with the current values. Start requires View and Run and the installed initiating role. Retain the returned model incarnation, policy/source identity, run sequence and frontierSha256. No raw source, policy definition, account kind or caller-supplied authority belongs in the request.

The author completes the Human step by replacing only operation with:

{
  "kind": "completeHumanStep",
  "runId": "inventory-review-001",
  "expectedSequence": 1,
  "stepId": "review",
  "reason": "Checked the saved inventory revision",
  "outputs": [],
  "evidence": []
}

Completion requires View/Edit and current step eligibility. Empty bindings work only when the installed policy requires none. Otherwise use exact retained, verified attachment bindings; a client cannot invent an artifact identity or relabel sensitivity. The native service derives the step's inputs from the existing run. Use the returned sequence for the next action rather than assuming the sequence in an example is current.

The independent reviewer signs in as the second Human and sends a fresh current envelope with this operation:

{
  "kind": "approveStep",
  "runId": "inventory-review-001",
  "expectedSequence": 2,
  "stepId": "review",
  "reason": "Independently checked the saved review",
  "evidence": []
}

Approve, reject and revoke-approval require View/Approve and actual current policy eligibility. The reducer checks the real participant and delegated role origins. Cancellation requires View/Run and reducer eligibility; it is not an administrator override. Permissions are checked again at effect/publication, so revocation can refuse a response even after a durable event was committed.

Read one run with { "kind": "get", "runId": "inventory-review-001" } inside the same envelope. List runs with { "kind": "snapshot", "cursor": null }; pass the exact returned nextCursor for continuation until it is null. Pages are bounded to 32 runs; model/source/security scope or history changes refuse a stale continuation. Requests are limited to 96 KiB and the facade accepts at most 1 MiB plus 16 KiB per response, matching the native workflow envelope; a response exceeding that bound is refused.

An uncertain mutation is not proof of rollback. Read the run under current authority before choosing another action; do not blindly start another run or increment a guessed sequence. Completed signed history is verified on restart. An unfinished signed action can refuse normal startup and requires the explicit original-intent maintenance operation described in the Human workflow recovery contract. Recovery does not substitute a new actor, event or terminal. Source replacement after workflow history is currently refused to preserve that original history.

The facade transport tests use an independent synthetic public reply fixture; native controller/restart tests exercise real local owners with declared trusted fixtures. Neither establishes live Linux encryption, OIDC/archive networking, end-user QA or measured production performance.

Recover a workflow after an uncertain mutation or read

Normal enterprise startup refuses an incomplete signed workflow intent. Do not retry the action with a new run or replace its source/policy files. The separate General maintenance commands below open the retained owners; they do not start model execution. They require the same Linux Server Pro deployment, protected roots, current OIDC provider and installed all-Human workflow policy. Providers, Care, manufacturing, record-invariant and record-solution profiles are refused by this recovery sign-in mode.

Stop the normal native enterprise process first. Create a mode-0600 private selector inside the deployment's admitted Credentials root. It names the model and optionally the actual run; omit runId or set it to null for a captured Get/Snapshot read, or to select the unique pending operation for a model:

{"schemaVersion":1,"modelId":"forecast","runId":"original"}

Run the read-only plan before authentication:

GRID_AUTH_MODE=enterprise grid-runtime-host enterprise-workflow-recovery-plan \
  --config /opt/grid/enterprise.json --request /protected/credentials/workflow-target.json

The plan derives operationId, originalIntentRecordSha256 and preparationSha256 from the actual signed intent and immutable native preparation. It reports the current securityRevision and classification. Ambiguous, missing, completed, corrupt or substituted originals refuse; matching caller hashes do not grant recovery authority. Keep this private output with the operator request. No preparation body, source bytes or historical event is rewritten by the plan.

If the original Human's session has expired, run the auth-only listener using the same selector, listen address and facade configuration:

GRID_AUTH_MODE=enterprise grid-runtime-host enterprise-workflow-recovery-auth \
  --config /opt/grid/enterprise.json --request /protected/credentials/workflow-target.json
GRID_AUTH_MODE=enterprise pnpm start:enterprise --config /opt/grid/enterprise-facade.json

Use the existing browser sign-in flow as the same original Human. The native listener accepts login begin/callback, current-session inspection and logout; all model, administration and provider endpoints refuse. The callback verifies current enabled Human identity, model View plus the original action permission, role origins, delegation and unchanged source/scope before issuing a new session. It does not extend an expired session. Original workflow completion capacity is reserved before startup recovery, retirement or authentication can append other signed records.

Inspect the new current session and retain its cookie, CSRF proof, exact browser origin and current revision in a mode-0600 reconciliation request. A fresh login advances the security revision, so use this current revision as expectedRevision, not the earlier plan revision. Stop the auth-only native process and wait for it to release all owners before running the existing reconciliation command:

{
  "schemaVersion":1,
  "session":"ACTUAL_CURRENT_SESSION_COOKIE",
  "csrf":"ACTUAL_CURRENT_CSRF_PROOF",
  "origin":"https://grid.example",
  "expectedRevision":1,
  "modelId":"forecast",
  "operationId":"ACTUAL_PLAN_OPERATION_ID",
  "originalIntentRecordSha256":"ACTUAL_PLAN_INTENT_RECORD_SHA256",
  "preparationSha256":"ACTUAL_PLAN_PREPARATION_SHA256"
}

GRID_AUTH_MODE=enterprise grid-runtime-host enterprise-workflow-reconcile \
  --config /opt/grid/enterprise.json --request /protected/credentials/workflow-reconcile.json

Replace every placeholder and revision with the actual retained/current values. The CLI reopens and revalidates the original, reserves its terminal debt before provider/archive work, and publishes only that original event/read and exact historical response. After successful reconciliation, restart normal enterprise HTTP. If sign-in stopped at a complete signed logical before/after security cut, restart the same auth-only command: it reserves the workflow obligation before exact security/session journal reconciliation. A staged native audit anchor or partial physical append refuses the read-only maintenance opener. Normal enterprise startup uses its existing authenticated original-prefix repair before workflow admission; it may repair that physical prefix and then still refuse the pending workflow. Re-run the plan to establish that the exact retained owner is readable. If it still refuses, use the existing audit-owner recovery procedure; this sign-in mode cannot turn ambiguous physical bytes into authority. Never delete or manually edit an intent, preparation, vault entry or signed audit record to unblock startup.

The terminal reservation preserves one exact completion obligation. Fresh login, credential retirement and reconciliation authorization require additional audit record and WAL capacity. Their existing native preflights refuse when it is unavailable. An operator may increase the trusted configuration's audit limits within the existing admitted bounds, preserving every record and protected root, then restart maintenance. Increasing capacity never permits deleting, overwriting or synthesizing the original history.

The General recovery plan and authentication startup also inspect exact signed logical sign-in and keycloak-backchannel logout cuts, plus session retirement cuts backed by the original encrypted vault receipt. They verify governed record and workflow history before reserving the unknown workflow’s original terminal; existing security and receipt-aware retirement reconciliation then runs before a full current history check and before the listener opens. A completed workflow can resume normal General startup after those logical cuts. An unknown workflow still refuses normal startup before any recovery append.

A missing or rolled-back committed retirement receipt, an after-state without its applied receipt, an unrelated pending authority transaction, or ambiguous physical audit append is refused. The plan remains read-only, including during supported logical security cuts. These checks do not extend old sessions or permit a caller to select a different Human, source, role, delegation or workflow scope.

Exercise the bounded API journey

The General enterprise QA client drives the documented Source, atomic record/retry, independent record review and separate Human workflow routes against an existing isolated service. Supply two current Human sessions, the exact source/security binding, an empty dedicated record table and the actual installed policy identities. Select both review and workflow for the complete bounded journey; omitted capabilities remain untested. The client records the exact request before each mutation and stops on an uncertain reply. Follow its retained intents and the recovery instructions above instead of rerunning the whole journey.

The separate atomic API Performance client measures the admitted 32-change workload. Neither tool provisions an environment or compiles product bytes. Their mocked Testing results establish client behavior; live Linux/provider QA and performance measurements remain unrun. These tools are independent of Build, Release, Deploy and Verify.