Review the prerequisites
Suitable for: Requires review tool platform or cross-team integration.
- Schema
- A contract describing the shape, type and constraints of fields; valid fields do not prove that the caller has operation permissions.
- trusted context
- The identity and tenant obtained after server-side authentication cannot directly trust the identity filled in the model.
- side effects
- Writes to the outside world, such as payments, releases, or deletes.
- status version
- A version of the current state of the resource, used to discover changes that have occurred since the check.
How does the mechanism work?
- Candidate parameters
The model proposes actions and parameters.
- structure and semantics
Check fields, types, units, and associated constraints.
- identity and status
Check the real permissions and current business status.
- Execution and receipt
Execute conditionally and verify the results and business evidence.
Design · Explain the trade-offs
Carry the contract through requests, approvals, and results
Objectives of this level: Able to assign each layer of inspection responsibilities and design version compatibility and result verification.
Assign responsibilities to layers
The model proposes candidates. A protocol adapter parses calls. An execution gateway checks trusted identity and policy. Business services enforce resource state and atomic writes. A result adapter returns verifiable receipts. Define each layer's inputs, outputs, and failures; a prompt cannot carry all permission checks.
Include errors and results in the contract
Success results identify action status, resources, and necessary evidence. A timeout can leave the outcome unknown rather than proving no execution occurred. The contract defines which failures are retryable. Valid result fields alone are insufficient; the caller must match the effect to the intended resource.
Specify compatibility and approval binding
Retain the tool version used by each task. Adapters may handle compatible changes; incompatible ones require revalidation or migration. Bind approval to concrete arguments and necessary resource versions so execution cannot substitute a different action. Choose the added state and operational complexity according to side-effect risk.
Run experiments and observe counterexamples
Manual parameter and authorization checks for specific tools; no real payments, full schema implementation, transactional deductions, or dynamic permissions platform.
Python 3.10+ · Runs by default using only the standard library · Runs on your computer
- Running a counterexample that is legal but cross-tenant
- Change trusted identities and permissions, compare wrong branches
- Additional testing of status changes after design check
python3 tool_contracts.pyView the entry-point script
"""A specific tool's manual validator, not a JSON Schema implementation."""
import json
def validate_shape(params):
if type(params) is not dict or set(params) != {"account", "amount_cents"}:
raise ValueError("shape")
if not isinstance(params["account"], str) or not params["account"]:
raise ValueError("account")
if type(params["amount_cents"]) is not int or params["amount_cents"] <= 0:
raise ValueError("amount")
def authorize(params, actor, accounts):
validate_shape(params)
account = accounts.get(params["account"])
if account is None or account["tenant"] != actor["tenant"]:
raise PermissionError("not allowed")
if "pay" not in actor["permissions"]:
raise PermissionError("not allowed")
if params["amount_cents"] > account["balance"]:
raise ValueError("balance")
def demo():
params = dict(account="B", amount_cents=100)
actor = dict(tenant="tenant-a", permissions=["pay"])
accounts = {"B": dict(tenant="tenant-b", balance=1000)}
validate_shape(params)
try:
authorize(params, actor, accounts)
except PermissionError:
return dict(shape_valid=True, authorized=False, business_writes=0)
raise AssertionError("cross-tenant request was accepted")
if __name__ == "__main__":
print(json.dumps(demo(), sort_keys=True))
Expected output when running locally
{"authorized": false, "business_writes": 0, "shape_valid": true}- Structure and authorization results are presented separately.
- Cross-tenant requests have no business effect
- Online business competition needs to be verified separately
Continue to do advanced research experiments
Push the read-only tool boundary to the approval boundary
First observe whether business effects have been generated while waiting for approval, and then press README to check action binding and recovery.
Read full text and fault analysis → · Download Reliability Experiment v3 ↓
python3 approval_cli.py submit
python3 approval_cli.py run
python3 approval_cli.py inspect
# 审查 draft 和 action_json 后，按 README 使用对应 binding_hash 批准并恢复Keep evidence and check item by item
- Status waiting_approval, no reports service has written yet.
- Review actions, targets, scopes, inputs, and content summaries before approving the corresponding binding_hash.
- Run tests to reject, cancel and modify content respectively to explain why old approvals cannot be reused.
Local approval fixture; --actor is not a login or production authentication. No network by default.
Acceptance task for this level
Draw the four layers of responsibilities of model, adapter, gateway and business service, and write an acceptance condition for each layer.
Check each item after completion
- Trusted identity does not come from model parameters
- State constraints are implemented into execution boundaries
- Explain how to handle compatible versions, unknown results, and approval failures
Save your own processes, code and results. Acceptance requirements are provided here, and course mastery status will not be automatically graded or saved at this time.
Hide the answer and check your understanding
Can "the model never generates override parameters" be the only authorization measure?
Expand reference derivation
No. Generating actions cannot replace server-side permission boundaries, and direct requests, model errors, and external textual influences must all go through the same execution check.
Further explanations and practice
When encountering unfamiliar principles, first read the implementation, continuous questioning and migration cases, and then independently explain the premise and boundaries. Answers and notes are saved to the original account record.
Sources and verification scope
The principles are based on public information; the numbers, cases and tasks are the teaching design of this website. Offline experiments verify the range noted on this page, and the learning effect still needs to be judged through independent tasks and feedback.