How should Modeling Session-driven single and bulk modeling use the owning ISAC actions and permissions, honor contribution moderation, reject stale source descriptions, choose per-record versus run-level transaction boundaries, emit useful append-only audit evidence, and determine compensating-reversal eligibility without bypassing canonical source ownership or validation?
Part of #1
Blocked by: #4
## Question
How should Modeling Session-driven single and bulk modeling use the owning ISAC actions and permissions, honor contribution moderation, reject stale source descriptions, choose per-record versus run-level transaction boundaries, emit useful append-only audit evidence, and determine compensating-reversal eligibility without bypassing canonical source ownership or validation?
A Modeling Session runs under a Registered Agent's authenticated browser session. Every mechanic update requires that Agent to confirm the exact record in chat before submission. The session then uses browser-harness to post the owning ISAC action.
The action requires data.manage. The Modeling Session does not create a Contribution Proposal, enter Data Oversight, issue a special token, or gain authority from chat confirmation. If the authenticated Agent lacks direct mutation permission, the session stops.
SHD.build does not persist chat confirmation. The existing owner audit event remains the durable account of the canonical mutation and does not add Modeling Session provenance.
Source ownership and stale-write protection
The Modeling Session posts the complete owner form expected by the existing action, including the validated Mechanic Program and the source fingerprint shown during confirmation. The server reloads canonical authored inputs and recomputes the fingerprint inside the owner transaction.
A mismatch returns a source-changed error and writes nothing. The session reloads the owner, regenerates or revalidates the program, shows the changed record in chat, and obtains another confirmation. It must not reuse approval for a different fingerprint.
The owner action remains the only canonical write path. Shared mutation functions may be extracted from route actions for maintainability, but the session does not write mechanic tables or audit rows directly.
Per-record transaction
Each confirmed owner update uses one transaction containing:
source-fingerprint comparison;
owner and authored-projection updates included in that action;
immutable model revision insertion;
selected-revision update;
relationship changes;
the existing append-only owner audit event.
The model call, chat confirmation, browser interaction, and post-commit notification remain outside the transaction. No transaction spans several mechanics. A failed record does not roll back a prior confirmed record.
Supported prerequisites use their existing ISAC actions and audit events. A prerequisite may commit before its dependent mechanic. If the mechanic later fails, the session reports the retained prerequisite rather than deleting valid Canonical Game Data.
Existing audit semantics
The owner action keeps its established game_data category and owner-specific past-tense action. Its before/after evidence includes the selected model revision, source fingerprint, readiness, Scenario Inputs, normalized conditions and outcomes, and affected projections or relationships. The event identifies the authenticated Registered Agent.
The audit event does not store chat text, model prompts, hidden reasoning, credentials, session cookies, or a separate Modeling Session origin marker. A read-back check verifies the selected revision and audit event before the session proceeds.
Contribution moderation boundary
Ordinary Contributor submissions continue through the existing proposal and Data Oversight lifecycle. The bulk modeling workflow does not use that path because it runs only for a Registered Agent with data.manage and explicit per-record chat confirmation.
Generated mechanics must not exploit proposal replay, internal fetches, or direct database access to bypass owner validation. Existing proposal behavior does not need new Modeling Session revisions, correction lineage, or approval rules in this scope.
Compensating reversal
A reversal never deletes or rewrites a model revision. It requires audit.revert, explicit confirmation, and the same current-state comparison used by other audit reversions. The server verifies that the selected revision and relevant owner state still match the original event's after-state and that no newer dependent change would be overwritten.
If a compatible prior revision exists for the current authored source fingerprint, reversal copies its validated graph into a new corrective model revision, selects that revision, and appends audit.reverted linking the original event, prior revision, replaced revision, and corrective revision. Copying creates a new revision because the reversal is a new canonical decision.
If the authored source fingerprint differs, the prior graph fails current validation, or dependencies changed, reversal is ineligible. A new Modeling Session must generate and confirm a correction. Rejected confirmations and failed submissions created no canonical mutation and need no compensating action.
Prerequisites reverse separately through their owning audit actions and only when current-state and reference checks pass. Reversing a mechanic never deletes a shared Attribute or another prerequisite.
Acceptance checks
Every modeled owner update requires data.manage and its existing ISAC action.
Source drift after chat confirmation rejects the write and requires renewed confirmation.
Model revision, selection, owner projections, and audit evidence commit atomically per record.
One failed mechanic leaves previously confirmed records intact.
Audit snapshots contain useful mechanic evidence without chat content or secrets.
Reversal creates a new corrective revision and preserves all prior revisions.
Reversal blocks when current state, source fingerprint, validation, or dependencies no longer match.
# Modeling Session mutation, audit, and reversal
## Authority and confirmation
A Modeling Session runs under a Registered Agent's authenticated browser session. Every mechanic update requires that Agent to confirm the exact record in chat before submission. The session then uses browser-harness to post the owning ISAC action.
The action requires `data.manage`. The Modeling Session does not create a Contribution Proposal, enter Data Oversight, issue a special token, or gain authority from chat confirmation. If the authenticated Agent lacks direct mutation permission, the session stops.
SHD.build does not persist chat confirmation. The existing owner audit event remains the durable account of the canonical mutation and does not add Modeling Session provenance.
## Source ownership and stale-write protection
The Modeling Session posts the complete owner form expected by the existing action, including the validated Mechanic Program and the source fingerprint shown during confirmation. The server reloads canonical authored inputs and recomputes the fingerprint inside the owner transaction.
A mismatch returns a source-changed error and writes nothing. The session reloads the owner, regenerates or revalidates the program, shows the changed record in chat, and obtains another confirmation. It must not reuse approval for a different fingerprint.
The owner action remains the only canonical write path. Shared mutation functions may be extracted from route actions for maintainability, but the session does not write mechanic tables or audit rows directly.
## Per-record transaction
Each confirmed owner update uses one transaction containing:
- source-fingerprint comparison;
- owner and authored-projection updates included in that action;
- immutable model revision insertion;
- selected-revision update;
- relationship changes;
- the existing append-only owner audit event.
The model call, chat confirmation, browser interaction, and post-commit notification remain outside the transaction. No transaction spans several mechanics. A failed record does not roll back a prior confirmed record.
Supported prerequisites use their existing ISAC actions and audit events. A prerequisite may commit before its dependent mechanic. If the mechanic later fails, the session reports the retained prerequisite rather than deleting valid Canonical Game Data.
## Existing audit semantics
The owner action keeps its established `game_data` category and owner-specific past-tense action. Its before/after evidence includes the selected model revision, source fingerprint, readiness, Scenario Inputs, normalized conditions and outcomes, and affected projections or relationships. The event identifies the authenticated Registered Agent.
The audit event does not store chat text, model prompts, hidden reasoning, credentials, session cookies, or a separate Modeling Session origin marker. A read-back check verifies the selected revision and audit event before the session proceeds.
## Contribution moderation boundary
Ordinary Contributor submissions continue through the existing proposal and Data Oversight lifecycle. The bulk modeling workflow does not use that path because it runs only for a Registered Agent with `data.manage` and explicit per-record chat confirmation.
Generated mechanics must not exploit proposal replay, internal fetches, or direct database access to bypass owner validation. Existing proposal behavior does not need new Modeling Session revisions, correction lineage, or approval rules in this scope.
## Compensating reversal
A reversal never deletes or rewrites a model revision. It requires `audit.revert`, explicit confirmation, and the same current-state comparison used by other audit reversions. The server verifies that the selected revision and relevant owner state still match the original event's after-state and that no newer dependent change would be overwritten.
If a compatible prior revision exists for the current authored source fingerprint, reversal copies its validated graph into a new corrective model revision, selects that revision, and appends `audit.reverted` linking the original event, prior revision, replaced revision, and corrective revision. Copying creates a new revision because the reversal is a new canonical decision.
If the authored source fingerprint differs, the prior graph fails current validation, or dependencies changed, reversal is ineligible. A new Modeling Session must generate and confirm a correction. Rejected confirmations and failed submissions created no canonical mutation and need no compensating action.
Prerequisites reverse separately through their owning audit actions and only when current-state and reference checks pass. Reversing a mechanic never deletes a shared Attribute or another prerequisite.
## Acceptance checks
- Every modeled owner update requires `data.manage` and its existing ISAC action.
- Source drift after chat confirmation rejects the write and requires renewed confirmation.
- Model revision, selection, owner projections, and audit evidence commit atomically per record.
- One failed mechanic leaves previously confirmed records intact.
- Ordinary contribution moderation remains unchanged.
- Audit snapshots contain useful mechanic evidence without chat content or secrets.
- Reversal creates a new corrective revision and preserves all prior revisions.
- Reversal blocks when current state, source fingerprint, validation, or dependencies no longer match.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of #1
Blocked by: #4
Question
How should Modeling Session-driven single and bulk modeling use the owning ISAC actions and permissions, honor contribution moderation, reject stale source descriptions, choose per-record versus run-level transaction boundaries, emit useful append-only audit evidence, and determine compensating-reversal eligibility without bypassing canonical source ownership or validation?
Modeling Session mutation, audit, and reversal
Authority and confirmation
A Modeling Session runs under a Registered Agent's authenticated browser session. Every mechanic update requires that Agent to confirm the exact record in chat before submission. The session then uses browser-harness to post the owning ISAC action.
The action requires
data.manage. The Modeling Session does not create a Contribution Proposal, enter Data Oversight, issue a special token, or gain authority from chat confirmation. If the authenticated Agent lacks direct mutation permission, the session stops.SHD.build does not persist chat confirmation. The existing owner audit event remains the durable account of the canonical mutation and does not add Modeling Session provenance.
Source ownership and stale-write protection
The Modeling Session posts the complete owner form expected by the existing action, including the validated Mechanic Program and the source fingerprint shown during confirmation. The server reloads canonical authored inputs and recomputes the fingerprint inside the owner transaction.
A mismatch returns a source-changed error and writes nothing. The session reloads the owner, regenerates or revalidates the program, shows the changed record in chat, and obtains another confirmation. It must not reuse approval for a different fingerprint.
The owner action remains the only canonical write path. Shared mutation functions may be extracted from route actions for maintainability, but the session does not write mechanic tables or audit rows directly.
Per-record transaction
Each confirmed owner update uses one transaction containing:
The model call, chat confirmation, browser interaction, and post-commit notification remain outside the transaction. No transaction spans several mechanics. A failed record does not roll back a prior confirmed record.
Supported prerequisites use their existing ISAC actions and audit events. A prerequisite may commit before its dependent mechanic. If the mechanic later fails, the session reports the retained prerequisite rather than deleting valid Canonical Game Data.
Existing audit semantics
The owner action keeps its established
game_datacategory and owner-specific past-tense action. Its before/after evidence includes the selected model revision, source fingerprint, readiness, Scenario Inputs, normalized conditions and outcomes, and affected projections or relationships. The event identifies the authenticated Registered Agent.The audit event does not store chat text, model prompts, hidden reasoning, credentials, session cookies, or a separate Modeling Session origin marker. A read-back check verifies the selected revision and audit event before the session proceeds.
Contribution moderation boundary
Ordinary Contributor submissions continue through the existing proposal and Data Oversight lifecycle. The bulk modeling workflow does not use that path because it runs only for a Registered Agent with
data.manageand explicit per-record chat confirmation.Generated mechanics must not exploit proposal replay, internal fetches, or direct database access to bypass owner validation. Existing proposal behavior does not need new Modeling Session revisions, correction lineage, or approval rules in this scope.
Compensating reversal
A reversal never deletes or rewrites a model revision. It requires
audit.revert, explicit confirmation, and the same current-state comparison used by other audit reversions. The server verifies that the selected revision and relevant owner state still match the original event's after-state and that no newer dependent change would be overwritten.If a compatible prior revision exists for the current authored source fingerprint, reversal copies its validated graph into a new corrective model revision, selects that revision, and appends
audit.revertedlinking the original event, prior revision, replaced revision, and corrective revision. Copying creates a new revision because the reversal is a new canonical decision.If the authored source fingerprint differs, the prior graph fails current validation, or dependencies changed, reversal is ineligible. A new Modeling Session must generate and confirm a correction. Rejected confirmations and failed submissions created no canonical mutation and need no compensating action.
Prerequisites reverse separately through their owning audit actions and only when current-state and reference checks pass. Reversing a mechanic never deletes a shared Attribute or another prerequisite.
Acceptance checks
data.manageand its existing ISAC action.Decision specification recorded above. It preserves per-record chat confirmation, existing ISAC ownership and permissions, source-hash compare-and-swap, atomic owner audit, unchanged contribution moderation, and corrective-revision reversal. Closing as resolved.