A mandate is an artifact, not a setting.

TaskContractV1

The contract binds, in one signed object: the tenant, the actors allowed to act under it, the Guardian and audience it is addressed to, the revision, the steps, their constraints, the budget and its units, the validity window, the policy and manifest in force, and the revocation counter.

• taskId · revision

  Identity and version. An approved contract is never edited in place: any change to a step yields a new revision that has to be reviewed again.

• tenant · guardianId · audience

  Who it belongs to and which single execution point may consume it. One mandate addresses one Guardian.

• actors[]

  Each actor binds an identifier to a key and its thumbprint. A step is claimed by proving possession of that key against a fresh challenge, consumed atomically.

• authority

  Set per operation by the protocol. The caller neither chooses it nor may degrade it within the same request, and an approved mandate must never lower a step's threshold. The Guardian must refuse, locally, any operation that is not eligible for delegation — even under a validly signed grant.

• steps[]

  Each step names its canonical operation, its provider, its resource list, the digest of its exact parameters, and carries maxUses fixed at one.

• budget

  Durable and atomic per tenant, task, revision and step. Committed means consumed plus anything reserved whose outcome is pending or uncertain, so one grant cannot reserve twice — and submitting the same task and revision with different content must not open a fresh budget.

• issuedAt · expiresAt

  The window. After it no new step is sent; there is no grace period and no renewal from inside the task.

• policyVersion · revocationVersion

  The signed local policy in force and the revocation counter. Revocation is checked as part of the send itself, not only before it; if storage or revocation is unavailable, no new effects go out.

The intersection still applies

effective permission = mandate ∩ grant ∩ signed local policy ∩ adapter constraints ∩ budget ∩ identity ∩ validity and revocation

The cloud never widens the local ceiling. A mandate is one more term in the intersection, never a way around it, and the Guardian has to enforce all of them before a provider is contacted — for the task runtime, gap 03 below says where that stands today.

State machine

A task occupies exactly one state, and the ledger records the transition rather than the intent.

• draft
• approved
• running
• paused
• completed
• revoked
• expired

Deliberate exclusions

• No subdelegation. One mandate, one Guardian, one budget; a task cannot hand part of itself to another actor or raise a second execution point.
• No open-ended effects. A step without a canonical operation and a parameter digest is not a step.
• No standing authorization. Every mandate expires, and expiry is not renewable from inside the task.
• What the actor reads — documents, tool output, web content, memory — is input, never authority. It cannot extend the contract.
• The adapter determines the canonical effect and the prestate. An agent's summary, a read-only schema or a destination taken from content is not accepted as truth.

The reader's role

The local reader is explanatory. In this profile an isolated finding, an abstention, a non-evaluation or a partial read does not block, revoke or force additional approvals on an exact effect already approved and permitted. Authority is never raised to compensate for an alert, and it is never lowered because no alert appeared. Identity, signature, budget, precondition and revocation keep failing closed — this is not permission to execute without controls.

Known gaps in the local runtime

A local runtime for this profile exists and runs in simulation. A review on 2026-09-23 found these differences between the specification above and the code. They stay listed here until each one is closed with a regression test.

1. 01Offline verification of a task bundle treats the expiry of a step's grant as a reason to reject, so a bundle stops verifying minutes after it was issued. A historical proof has to stay verifiable after the authorization it records has expired.
2. 02The same verifier rejects correctly signed receipts whose status is failed, indeterminate, revoked or expired. An incomplete task has to be representable as incomplete, not as invalid.
3. 03The task runtime does not yet apply the signed local policy, nor a local check that an operation is eligible for delegation. Until it does, the ceiling depends on whoever signs the grant.
4. 04Revocation is optional in the task runtime, and it is checked before the provider preflight rather than at the moment of sending.
5. 05The task ledger identifies a contract by its digest, so a different contract reusing the same task and revision would get its own budget. There is no transition yet from indeterminate to a reconciled result.
6. 06A task bundle does not yet carry the human approval, the local policy applied or the durable claim, so on its own it does not prove separation of duties or the ceiling that bounded the task.

Planned next — not available today

Each item below is part of the current plan. None of it is available today, and each one will appear on the evidence page with its own level — design, simulated or real integration — when it closes.

• Approval bound to the mandate: a single-use challenge tied to the contract digest, the revision, the approver and an expiry. In an organization the requester and the approver are different people, and an open session on its own does not count as a fresh approval.
• A minimal console in securestamp.online to review a proposed task, approve or reject one exact revision, follow its budget and uncertain steps, request revocation and export the evidence.
• Two labels that are never merged. Restricted call: only the tools and arguments the mandate allows reach the server — which says nothing about the server's internal effect. Exact effect: a verified adapter binds operation, resources, parameters and preconditions to the observed result. A route that bypasses the Guardian is labelled not covered.
• The model is shown the approved snapshot of each tool's name, description and schema. A later change stops the affected task instead of reaching the model first.
• Later, and not in the first profile: an authority diff. A task that needs something outside its mandate asks for that exact change; the new revision inherits what was consumed and what is uncertain, and never resets the budget.