Client or agent identity.
The record identifies whether the request came from a client, builder, trusted agent, or external workflow system.
Client + Agent Intake Rail
One intake path for client work and agent-submitted workflows.
The intake rail captures who is requesting the work, what operating tool should run, what evidence exists, what output is required, where the result should return, and how the request binds into Wever Labs OS runtime records.
What the rail captures
Context becomes a routable operating request.
Client and agent requests use the same intake shape: requester identity, tool selection, workflow context, evidence references, urgency, callback route, result format, and runtime binding requirements.
The work is routed to a surface.
TokenOps, FinanceOps, EnergyOps, DistributionOps, and PacketOps can receive work through the same intake rail.
Files and references are named.
Uploaded files, document links, provider references, ledger records, invoices, project records, and notes become structured inputs.
Output requirements are explicit.
The request states the desired result package, callback behavior, receipt needs, attestation needs, and operator review requirements.
Runtime binding
Each accepted intake becomes an OS runtime record.
The intake rail binds the submitted context to onboarding status, trust profile, quote, provider route, credit entitlement, run contract, queue state, result contract, receipts, callback, ledger, and attestation.
Machine-readable contracts
The intake rail is discoverable and callable.
Agents and builders can read the request schema, runtime binding schema, examples, and OpenAPI paths before submitting work into Wever Labs OS.