Let agents find information, prepare a proposal and coordinate work across services. The operating model names who they work for and what they may do. Work that needs a person's approval returns to the Wallet; implemented and illustrative paths are distinguished below.
The agent workflow starts with a task: find an available service, assemble the permitted context and prepare the next step for review.
The Wallet is available when a person or organisation needs to understand, authorise or retain what happens. Routine work can continue inside an existing mandate; consequential work can stop for a clear decision. Either way, the principal, authority and result stay visible.
Compare how an established service partner and an independent tailor can reach the same field view, policy decision and expected result. This page renders the product contract; its public execution controls remain inactive until the named trust origin and partner proof are available.
External KYA-OS references: DIF introduction, DIF working group and verifier example. These are not a Verifable test, endorsement or certification.
Item 0438 · exact repair view · one lifecycle event
The service declares the resource, operation and authority it accepts.
The principal, actor, evidence, audience, scope and limits travel together.
Policy chooses the exact fields, representations and update rights for this task.
The proposed graph diff and supporting evidence are inspectable before commitment.
A Wallet checkpoint appears when the policy calls for a responsible person.
The accepted event binds the principal, agent, authority, decision, change and result.
The readable outcome, verification trace and machine representation are three intended views of the same operation record. This illustrative record is not proof that the operation ran.
{
"@context": { "vf": "urn:verifable:agent-operation:" },
"@id": "urn:verifable:receipt:repair:0438:01",
"@type": "vf:OperationReceipt",
"vf:principal": "urn:person:garment-owner",
"vf:agent": "urn:agent:repair-assistant:8472",
"vf:resource": "urn:product:item:0438",
"vf:action": "append-repair-event",
"vf:decision": "allow-with-approval",
"vf:executionState": "illustrative-not-executed",
"vf:result": "urn:event:repair:0438:01"
}The same checks can support travel, new work and caring for products or places. These are directions for the product model, rather than deployed workflows.
Prepare a journey, a move or a visit to family. Let the person review who needs their information and why.
Prepared journey → Wallet checkpoint when neededPrepare evidence for a tender, a customer or a service partner. Make clear who may submit it and which decision still needs approval.
Authorised task → attributable resultConnect repair, reuse, care or environmental observations to the people and evidence behind them.
Contextual action → continuing evidenceKeep the person as principal when they borrow a device, receive help beside them, or authorise a representative for one bounded task.
Device access ≠ assistance ≠ authorityWallet, human UI, API and MCP interactions can converge on the same policy decision and result. Policy invokes a responsible-person checkpoint when the situation requires one.
Show the represented principal, actual operator when different, requested fields, proposed change and expected receipt before approval.
Create, validate and project the bounded operation through domain-specific interfaces.
Exercise issuer, verifier and cross-device ceremonies while inspecting every protocol artifact.
Open the SandboxChoose the Wallet, issuer or verifier you bring, then move from its profile to a runnable test.
Open test directoryVerifable participates in the OpenID Foundation AIIM MCP Security interoperability work across authorization-server, OpenID Provider, resource authorization-server and MCP Server roles.
Start with one real resource, one permitted action and one accountable result.