Platform
Proxy covers the lifecycle around getting work completed: something arrives, it is understood, it is kept, people are scheduled, the work is done, and all of it can be shown afterwards. The services are separate. The conventions underneath them are not.
A stage describes what is happening to the work. A service is the thing you buy and call. The two do not map one to one, and pretending they did would make the catalogue easier to draw and harder to use.
Beginning with a single service is a supported way to use Proxy rather than a trial of it. Nothing about the first service changes when a second arrives.
Prove is not a service you buy. It is four artefacts the other services produce while they run, and you can read all four without enabling anything extra.
The event, the resource, the named actor and the time it was recorded.
On every mutation, by every service.
The operation key, the quantity, the billing unit, the cost and the status.
On every metered operation, charged or free.
The outcome, the attempt history, and whether a retry has been made.
On every message sent and every webhook attempted.
The server-side verdict, kept with the signature it belongs to.
On every signature submitted for capture.
GET /api/v1/audit?resource=01k5m7z4…
{
"data": [
{
"event": "storage.object.created",
"resource": "01k5m7z4h9c1e8ptw2yb3rkq5d",
"actor": { "type": "integration", "name": "Claims portal" },
"recorded_at": "2026-08-14T09:40:58+00:00"
},
{
"event": "processor.job.completed",
"resource": "01k5m8f2r7q0x3v9tzcd4npb6h",
"usage": { "operation": "ocr.document", "quantity": 1, "status": "charged" },
"recorded_at": "2026-08-14T09:41:07+00:00"
}
]
}The two calls from the integration example, seen from the evidence side. The actor, the operation and the charge status are all on the record, so a question asked six months later does not depend on log retention.
Each of these composes services that were enabled separately. None of them needed a workflow engine to be modelled first.
Claims handling
A customer uploads what they have from a phone. Proxy reads it, works out what each file is, and keeps the originals with the extraction beside them.
Services used, in order: Storage then Processor then Storage
Legal operations
Fields already held on the matter populate your template. The document is stored, sent as an envelope, signed in the browser and returned to both sides.
Services used, in order: Documents then Sign then Communications
Field services
Availability comes from the constraints you publish. The customer picks a slot in your page, and the appointment attaches to the job rather than to a calendar nobody else can see.
Services used, in order: Calendar then Communications
Regulated servicing
Outbound email and SMS are sent on the organisation's behalf and recorded against the record. Inbound replies land in the same place. SMS is metered by segment, so a long message is not under-counted.
Services used, in order: Communications then Storage
Customer onboarding
An address is resolved before it is stored, the identity document is checked, and the outcome is recorded with the application rather than in an operator's inbox.
Services used, in order: Address Lookup then Identity then Storage
Tell us the shape of the work and we will say which services cover it, which do not, and what the operations would be. Where something does not fit, we will say that too.