PAP/1.0 Specification

Status of this document. pap/1.0 is a published specification with a live reference implementation inside LabsAI Studio, where delegated work travels as PAP invocations within a single node. The protocol is transport-independent by design; the multi-node agent network its URIs address is in development. Revisions are versioned and logged in §08 — the wire format below is stable for the 1.0 line.

01URI schemes

A PAP URI addresses an invokable agent resource — an agent capability, not a document:

pap://labsai.studio/research
paps://labsai.studio/research

paps:// is PAP over a secured transport, and is the required scheme whenever the operation involves execution on the callee’s systems, tools, secrets, payments or identity-bound actions. A callee must refuse such operations arriving as plain pap://. In deployments where TLS terminates at a fronting proxy, the leg from the proxy inward is considered the secured transport’s continuation; the scheme names the caller’s obligation, not the topology. Bare capability names are permitted where the host is already established by the connection.

02The request envelope

{
  "pap_version": "pap/1.0",          // exact string; others are rejected
  "id":          "9f0c…-uuid",        // caller-unique per request; echoed back
  "target":      "pap://labsai.studio/research",
  "op":          "invoke",            // describe | invoke | stream
  "headers":     { },                 // caller metadata; never load-bearing
  "body":        { "query": "…" },    // the capability's input, per its schema
  "auth":        { "scheme": "key", "token": "…" }
}

pap_version and id are required on every request; target is required for invoke and stream. Auth rides in the envelope — a PAP request must be self-describing enough to relay — and a callee may additionally require transport-level credentials. Envelopes exceeding the callee’s declared size limit are rejected with parse_error.

03The response envelope

{
  "pap_version": "pap/1.0",
  "id":          "9f0c…-uuid",        // the request's id, always
  "status":      "ok",                // ok | error
  "result":      { "answer": "…", "sources": "…" },
  "meta":        { "ms": 8412, "confidence": 0.7 }
}

On error, result is replaced by error: an object of code (from the registry in §05) and message. Execution metadata rides the response itself, never a side channel: ms (wall time) always; confidence and trust where the callee computes them; seq and last on stream frames.

04Operations

op	Semantics
describe	Returns the agent card: name, protocol version, supported ops, auth schemes, and every capability with its target URI, input schema and whether it streams. Discovery is a protocol operation, not documentation.
invoke	Executes the targeted capability with body as input and returns one response envelope. The callee must bound execution with a timeout and return timeout rather than hanging the caller.
stream	Executes the targeted capability and returns newline-delimited response frames, each a complete envelope carrying meta.seq; the final frame carries meta.last: true. Errors mid-stream arrive as an error envelope in the stream.

05Error registry

code	Meaning
parse_error	The envelope is not valid JSON, is missing required fields, exceeds size limits, or names an unsupported pap_version.
auth_error	Missing or invalid credentials, at either the transport or the envelope layer.
policy_denied	The invocation was refused by the callee’s governance — capability scope, budget, or content policy. A PAP caller is never a side door around policy.
timeout	The invocation exceeded the callee’s execution bound.
invalid_signature	A signed envelope failed verification.
not_found	The target names no capability this agent exposes.
busy	The callee is at capacity; the caller may retry with backoff.
unsupported	The op, or an op/capability combination, is not supported — also the terminal code for unclassified execution failures.

06Authentication

pap/1.0 defines one auth scheme, key: a shared secret carried as auth.token and compared in constant time. Callees may also require the same credential at the transport layer. The scheme registry is open by design — signed envelopes (invalid_signature already reserves their failure mode) and identity-bearing schemes belong to later minor versions without breaking 1.0 callers.

07The reference implementation

Live usage: LabsAI Studio. The Studio’s agent endpoint implements every section of this document, plus an export capability returning any recorded run’s A2F .orch trace — the envelope validation, all three ops, the full error registry, envelope and transport auth, and execution metadata — and the Studio itself is the protocol’s first caller: a session’s delegated research — a Speech‑to‑Orchestration Voice Command at its origin — travels as a pap/1.0 invoke to the Studio’s own endpoint and returns with timing and confidence in meta. Governance is shared with live tool use, so policy_denied is a real, reachable state, not a reserved word.

One honest boundary, stated plainly: the reference implementation runs within a single node. Multi-node operation — discovery across hosts, resolution of agent names, trust between agents that have never met — is what the URI scheme is written for, and is in development rather than shipped.

08Versioning & changelog

The version string is exact: a callee speaking pap/1.0 rejects any other value with parse_error. Minor revisions of this line (1.1, 1.2…) may add ops, auth schemes, meta fields and error codes; they may not change the meaning of anything specified here. The changelog is the record:

Version	Date	Change
pap/1.0	2026‑08‑17	Initial publication: URI schemes, envelopes, describe/invoke/stream, error registry, key auth, execution metadata. Reference implementation live in LabsAI Studio.

The concept, and where the protocol sits among the planes.

Read Introducing PAP →

Contributors

Labsintelligence

Contributing authors: Maya E. Davis · Duránd F. Davis Jr.

Tell us what you think, join us

This research is published while the questions are still open, and the systems it describes are live. We would love for you to join us — and please share your thoughts at research@labsintelligence.ai.

Citation

Please cite this work as:

Davis, Maya E., and Davis, Duránd F., Jr., “PAP/1.0 Specification.” LabsAI Research Specs, Labsintelligence — lab1 of Labs Companies, Inc., August 2026.

Or use the BibTeX citation:

@article{labsintelligence2026pap10,
  author  = {Davis, Maya E. and Davis, Duránd F., Jr.},
  title   = {PAP/1.0 Specification},
  journal = {LabsAI Research Specs},
  publisher = {Labsintelligence, lab1 of Labs Companies, Inc.},
  year    = {2026},
  month   = {august},
  url     = {https://labsintelligence.ai/research/labsai/pap-1-0/},
}