The proposal boundary: separating a model’s suggestion from accepted context

Two actions that should remain different

An analyst asks an agent to compare a fictional agreement with a later communiqué. The agent returns a useful table and suggests changing a recorded commitment from “proposed” to “accepted.” Producing the table and changing the team’s accepted context are different actions. The first supplies material for review. The second changes what later work may rely on.

Our intended architecture gives those actions separate paths. PRAXIS is the agentic workspace for assigning the task and reviewing the returned artifact. DIALECTICA handles structured knowledge and review records through a defined interface. This is a design requirement for the integrated system, not a claim that every deployed path already enforces it.

What is being approved?

A proposal needs a stable identity, the source versions it used, the target capsule revision, and an explicit list of changes. The reviewer should see the relevant passages beside the proposed difference. “Approve with a qualification” must preserve that qualification in the accepted record; a note visible only in an approval dialog would be lost to the next task.

PROV can describe the proposed artifact, the review activity, and the responsible agent. It also supports derivation and revision relationships. That helps represent who did what, but the application must still define the legal state transitions and verify the reviewer’s authority. A well-formed provenance record is not an authorization token. [1]

The check belongs where the write happens

Putting an instruction in the agent prompt is insufficient. The service accepting the change needs to authenticate the caller, check access to the target capsule and sources, validate the decision against the exact proposal, and commit the result consistently. An agent’s extraction credential should not also be a promotion credential. A tool result claiming that a supervisor approved something should remain data until the application verifies an authorized decision.

The MCP tools specification makes tool availability and invocation explicit, recommends human oversight, and warns that tool annotations from untrusted servers must be treated as untrusted. It does not choose our capsule authorization model or enforce our review policy. The host and server still have to implement those boundaries. [2]

Concurrency is easy to miss in a demonstration. Suppose two analysts review the same proposal against revision 12. The first approval creates revision 13. The second approval must not overwrite it or silently apply a now-different change. HTTP conditional requests provide one established pattern: If-Match can make an operation conditional on a matching entity tag and help prevent lost updates. Our underlying storage would still need an atomic revision check, regardless of the transport. [3]

begin transaction
  require reviewer may change this capsule
  require decision targets this exact proposal version
  require current_revision == reviewed_revision
  require referenced sources remain accessible under policy
  validate proposed changes and retained qualifications
  write next_revision and decision_receipt atomically
commit

on revision mismatch: return conflict; require renewed review

A review record can still record a bad decision

Human review is not automatically effective. A long batch of plausible claims can encourage a reviewer to accept everything. The interface should make disagreement and uncertainty visible, show the consequence of the decision, and allow the reviewer to narrow its scope. We should test whether the display helps people notice errors rather than equating a click with informed judgment.

Rejections can preserve useful context: an apparent contradiction may have turned out to involve different dates. But keeping every rejected proposal forever is not an unconditional virtue. Sensitive source passages, retention requirements, access changes, and deletion requests also matter. A decision history needs a retention policy and an intelligible way to represent missing or withdrawn evidence.

NIST’s AI Risk Management Framework is voluntary guidance for incorporating trustworthiness considerations into design, use, and evaluation. It supports treating these as ongoing system responsibilities, not a one-time approval event or a certification obtained by adding a reviewer field. [4]

Tests that would establish the boundary

We would test an agent attempting direct promotion, a forged reviewer identity, approval of a modified proposal, inaccessible evidence, duplicate submission, a crash between the data write and receipt write, and two reviewers racing on the same revision. Each test needs an observable expected state, including the absence of partial changes.

The behavioral evaluation is separate: can reviewers detect a deliberately misplaced qualification or unsupported commitment change? We need both types of evidence. Passing authorization tests would establish something about permitted writes; it would not establish the quality of the resulting analytical judgment.

Reject, correct, review and reuse one local revision

The source checker flags unsupported adoption wording; the chronology checker separately checks the cutoff. A person can reject the proposed revision, inspect the qualified replacement and approve its bounded use with a reservation. Editing creates a new revision and removes that approval. Saving retains the actual evidence and decision; keeping the correction produces a new method revision for the next assignment. None of these browser decisions promotes records into PRAXIS canonical stores. [5]