Your team has a working service that can summarize a document. The first customer wants to call it from an agent, choose which service providers may execute it, pay per Job, and inspect what happened when two answers disagree. A web endpoint can expose the summary function, but it does not by itself describe provider registration, service state, artifact identity, or a result rule.
Tangle is a coordination network for services that independent parties run. Its contracts record selected registration, service, payment, verification, and lifecycle state while application work runs outside the chain. Off-chain means computed outside the blockchain, while on-chain means recorded in blockchain state. That missing description is what a Blueprint, a reusable service template, supplies: it connects a service’s jobs, artifacts, service providers, and rules.
How Blueprints work begins with these protocol objects and the provider that runs them:
- A Blueprint is a reusable template for a service.
- A Service is one configured instance of that template.
- A Job is one callable unit of work inside the Service.
- An operator is the party that runs the artifact and executes the Job.
The Tangle Blueprint documentation describes those objects and the split between protocol coordination and off-chain application logic. The Blueprint software development kit (SDK) is the public Rust toolkit for packaging the logic, routing jobs, running an operator process, and testing the path against local Tangle contracts.
A Blueprint puts service code, Job schemas, artifact sources, operator requirements, triggers, and usage policies into one versioned service definition.
The request before the architecture
Use a transcription service as an example. The customer sends an audio reference and a language hint. The service returns timestamped text.
The public job contract might be:
Job: transcribe
Input: { audio: <reference>, language: <optional code> }
Output: { segments: [{ start, end, text }] }
Failure: invalid reference, unsupported language, timeout, or execution errorThat contract answers the caller’s first questions. It says which input must be encoded, which output can be decoded, and which failures should be handled as a retry or a user-visible error.
If the caller is an AI agent, its agent profile is the versioned bundle of model choice, instructions, tools, permissions, and output rules that guide the workflow. The profile can choose a transcription Job without needing to understand how each operator stores a model or starts a process.
The runtime is the process and environment that carries out the profile or service code. The Blueprint Manager is the off-chain operator process that watches protocol state, obtains artifacts and metadata, and runs assigned services. The Blueprint Runner is the job-execution process that receives calls, routes them to handlers, and returns results. A Blueprint Service Manager is a separate on-chain contract that can customize registration, service creation, authorization, payment, result checks, and slashing. The Manager and Runner are the off-chain processes that face that protocol state.
The separation matters because a caller can choose the job contract while the operator chooses ordinary operational details such as machine size, process supervision, and local storage, subject to the Blueprint’s published requirements.
What belongs in a Blueprint
A deployable Blueprint normally contains more than the function that does the work.
| Blueprint component | What it tells the system |
|---|---|
| Executable artifact | What an operator downloads and runs, such as a container or native binary |
| Job handlers | Which units of work the service exposes |
| Input and output schemas | How callers encode requests and decode results |
| Triggers | Whether jobs arrive from chain events, HTTP, webhooks, schedules, or machine payments |
| Metadata | What the service does, where its docs live, and which evidence it returns |
| Execution policy | Whether standard or confidential execution is acceptable |
| Optional manager contract | How registration, service creation, authorization, payment, result checks, or slashing are customized |
The Blueprint sources guide defines a source as the instructions for fetching and executing an artifact. A container source is still an artifact source, even when the Blueprint separately declares that it prefers or requires a trusted execution environment.
The metadata is part of the public interface. It should let a customer decide whether the service fits before submitting a job. That includes the job schema, payment path, operator requirements, execution policy, result evidence, timeout, and expiry behavior.
On-chain coordination and off-chain execution
Tangle uses on-chain and off-chain state for different jobs. A smart contract is a program whose state transitions are executed by a blockchain network. On-chain state is recorded in smart-contract state that participants can query and agree on. Off-chain work is computed by an operator process outside the chain.
The chain can record service creation, operator registration, job identifiers, payment transitions, and lifecycle changes. The operator can process an audio file, call a model, and return a transcript without putting the file or every token into the chain.
The path looks like this:
A job router maps a job identifier to the handler that should run it. A trace is a time-ordered record of a run. A task evaluation is a test or judging procedure for the property a customer cares about.
caller or agent
|
| job request, webhook, chain event, or paid HTTP call
v
producer -> Blueprint Runner -> job router -> job handler
|
v
result + trace fields
|
v
consumer -> protocol or callerA producer is an adapter that turns an external event into a job call. A consumer is an adapter that sends a job result to its destination. The job-router documentation describes routing, parameter validation, and the producer-consumer relationship.
For a transcription job it might include the call ID, input fingerprint, artifact version, start and end time, exit state, output reference, and evaluation result. A trace is useful evidence, but it does not become independent evidence merely because it has a timestamp.
The Blueprint lifecycle
1. Publish the template
The developer publishes the executable artifact, metadata, job definitions, and any manager contract or protocol configuration. The public definition should identify the versioned source and explain what operators and customers must provide.
The artifact needs a stable identity.
A mutable latest tag can point to different bytes on different days, so a production service should record an immutable digest or release artifact and make updates visible as new versions.
2. Operators register
Operators register their willingness to run a Blueprint. Registration does not mean that a customer has already created a Service. It means the operator is available for a service instance of that type and can be evaluated against any requirements the Blueprint declares.
The operator may need a keystore, remote procedure call (RPC) endpoints, hardware capabilities, a container runtime, or a confidential-computing setup. The Blueprint Manager documentation says that the manager watches chain events, obtains the Blueprint’s artifacts and metadata, and runs assigned services natively, in a container, or in a virtual machine according to the definition and confidentiality policy.
3. A customer creates a Service
The customer chooses a Blueprint and creates a Service with an owner, operator set, configuration, payment terms, and lifecycle state. The Service is the object the customer uses.
A Service can require a minimum number of operators or specify a confidentiality intent. It can have a time-to-live, or TTL, which is the period after which the protocol can stop accepting jobs or billing. The current service lifecycle guide explains that expiry does not necessarily perform application cleanup or return every asset.
If the transcription Service owns durable customer state, the Blueprint must provide a migration or exit path before the TTL ends.
4. A trigger creates a Job call
x402 is an open protocol for programmatic payment over the Hypertext Transfer Protocol (HTTP).
The caller sends a request, the server returns 402 Payment Required with payment requirements, the caller signs a payment payload, and the server verifies and settles it before delivering or enqueuing the resource.
The official x402 flow documents the headers and steps.
The Job can be triggered by an on-chain event, a web webhook, a schedule, a custom event source, or an x402-paid request. The producer turns the trigger into the internal job shape expected by the Runner.
Tangle’s optional x402 gateway turns a verified payment into a JobCall, the internal message for a configured service and job.
The gateway can return 202 Accepted when the request has been accepted and enqueued.
That status is not a completed transcript.
5. The operator executes off-chain
The Runner receives the call and the job router selects the handler. The handler validates the input, calls the model or application code, applies resource limits, and produces a typed result or an explicit error.
The operator may run a native binary, a container, or another source supported by the release.
If the Blueprint requires confidential execution, the manager must refuse or filter out a runtime that cannot satisfy the policy.
The current execution confidentiality guide lists any, tee_preferred, tee_required, and standard_required as the protocol policy values.
6. The result moves to the consumer
The consumer submits or returns the result through the path associated with the trigger. For an on-chain job, that may produce a result event or state transition. For a web gateway, it may return a correlation identifier first and expose the eventual result through another endpoint or application callback.
The result should carry enough context to connect it to the exact Service, Job, artifact version, and payment. Without that connection, a customer can receive a valid-looking transcript and still be unable to prove which execution produced it.
7. Verification and settlement apply the chosen rules
Verification is the procedure that checks a result against a rule. For deterministic work, the rule may compare outputs from multiple operators. For a cryptographic job, it may verify a proof. A trusted execution environment, or TEE, is a hardware-backed area that isolates a workload from ordinary host software. An attestation report is signed evidence about that environment and its measured workload. A task evaluation is a test or judging procedure for the property a customer cares about. For private inference, it may check an attestation report and a model measurement. For a language task, it may run a task-specific evaluation.
The Blueprint defines the rule or connects to a manager that does. The protocol does not supply a universal test for arbitrary output quality. The companion article How Tangle Verifies Work works through those boundaries.
Payment and verification are separate. A settled x402 payment proves that the payment path accepted the signed payload and settled according to its scheme. It does not prove that the transcript is accurate.
The smallest job-router example
The public SDK documents the central route shape as follows:
use blueprint_sdk::Router;
let router = Router::new()
.route(MY_JOB_ID, my_job)
.with_context(my_context);The names in this snippet are placeholders from the documentation’s minimal example.
In a transcription Blueprint, MY_JOB_ID becomes the stable identifier for transcribe, my_job becomes the handler, and my_context can hold resources such as a model client or store.
The route does four useful things:
- It gives the call a stable address inside the Blueprint.
- It makes the handler selection explicit.
- It gives the Runner a place to validate and decode the request.
- It preserves a boundary where unknown job IDs can be rejected.
The route does not encode the entire service. It does not publish the container, register an operator, create a Service, charge a customer, or evaluate the transcript. Those concerns belong to the surrounding package and protocol configuration.
Verification methods and their limits
Suppose three operators transcribe the same short audio file. The Blueprint accepts a result when at least two normalized transcripts agree. That rule can detect a disagreement and tolerate one unavailable operator. It cannot prove the agreed transcript is correct if all three use the same faulty model or the same corrupted audio file.
Other verification designs make different tradeoffs:
A zero-knowledge proof, or ZK proof, demonstrates that a formally defined computation satisfied a relation without revealing its private inputs. Multi-party computation (MPC) lets several parties compute from split inputs without giving the complete input to one party. The NIST definition of MPC describes the privacy boundary of that computation. An optimistic challenge accepts a result provisionally and lets a participant dispute it during a defined window.
| Design | What it can establish | What remains open |
|---|---|---|
| Redundant deterministic execution | The required operators produced matching output | Shared bugs and collusion can produce matching wrong output |
| TEE attestation | An approved measured workload ran in a protected environment | The workload can still implement the wrong algorithm |
| ZK proof | A formally defined computation satisfied a mathematical relation | The relation may omit the property the customer cares about |
| Optimistic challenge | An incorrect deterministic result can be challenged during a window | Finality waits, and someone must monitor and challenge |
| MPC | Parties can compute from split inputs under a threshold assumption | It can be expensive and still needs a correctness rule |
| Task evaluation | A result passes selected examples, rules, or human review | Unseen cases and evaluator error remain |
A quorum is the minimum number or weight of participants whose matching result is accepted. A canary is a known input used to detect a selected behavior change.
These terms describe mechanisms, not product guarantees. The Blueprint must state which one it uses and which assumptions a customer is expected to accept.
Rewards, stake, and slashing rules
An operator supplies infrastructure, keys, and availability. The service may reward the operator for jobs, require a stake, or apply a slashing rule after a detected violation.
Slashing is not an instant refund button. The current public slashing guide describes a proposal, a dispute window, and an executable or cancelled outcome. The evidence must be non-zero and the authorization and dispute rules matter.
An economic rule is useful only if the customer can understand the condition that triggers it. “Bad output” is too vague for a contract unless the Blueprint defines how to identify the bad output and who may submit evidence. An operator may be penalized for a missed heartbeat or a provable protocol violation while a subjective language-quality disagreement remains outside that rule.
The cost of verification also belongs in the pricing model. Running three copies of a deterministic job can provide redundancy at roughly three execution costs before network and coordination overhead. Generating a proof can take longer than running the job. Human evaluation can dominate the price even when the compute is cheap. The service should expose which layer the customer is paying for.
Registration, artifact, expiry, payment, and result failures
An operator registers but never runs
Registration expresses willingness, not successful operation. The Blueprint needs health signals, timeouts, and a policy for removing or replacing an unavailable operator.
An artifact changes under the same label
The caller and operator may disagree about which code is approved. Use an immutable digest or versioned release and include it in the service evidence.
A Service expires with state in use
TTL is a protocol boundary, not a complete data-retention policy. Provide an exit path that does not depend on a fresh Job call if the operators may refuse renewal.
A request is paid twice
Payment settlement and job idempotency are different controls. Give each request a correlation identifier and define whether a duplicate returns the original result, creates a second Job, or is rejected.
Two operators disagree on a non-deterministic result
Do not pretend that string equality is a correctness rule for sampled text. Normalize what can be normalized, define acceptable variation, and add a task evaluation for the property the customer values.
The result is accepted before the work is complete
An enqueued or paid state should not be named completed.
The x402 gateway’s documented 202 Accepted response is a useful example of keeping those states separate.
Blueprint fields and protocol responsibilities
A Blueprint carries more than code. It is the agreement between developer, operator, and customer about what can be requested, who may run it, which artifact is approved, what evidence is returned, how payment works, and how the Service ends.
Publishing machine-readable schemas, pricing, triggers, completion states, and evidence requirements gives an agent a discoverable callable surface. An agent can inspect the job schema and price, select a Service, pay through a machine-readable flow, wait for an explicit completion state, and decide whether the returned evidence satisfies its profile.
Contract events, queryable lifecycle state, and result identifiers can expose those transitions. The application still has to define typed results, retry rules, idempotency keys, and terminal error states.
When a Blueprint fits
A Blueprint is a good fit when the service needs independently operated infrastructure, on-chain lifecycle records, protocol-level payment, custom verification, or an operator set whose membership matters to the customer.
A conventional service is usually better when one company should own the whole path, the input is already trusted to that company, the request is latency-sensitive, and an ordinary contract and audit satisfy the recourse requirement.
Choose a Blueprint when independent operator choice, queryable lifecycle and payment state, result evidence, or slashing recourse addresses the customer’s feared failure; otherwise use the conventional service.
What is a Blueprint in Tangle?
A Blueprint is a reusable service template that describes executable artifacts, jobs, schemas, metadata, triggers, and optional protocol logic. Operators run it, and customers create configured Services from it.
What is a Service?
A Service is one live or configured instance of a Blueprint. It has an owner, an operator set, payment terms, configuration, and lifecycle state.
What is an operator?
An operator is the party that registers to run a Blueprint, fetches its artifacts, executes assigned Jobs, and returns results. An operator can use cloud or bare-metal infrastructure while following the Blueprint’s published execution policy.
What does the Blueprint Runner do?
The Blueprint Runner is the job-execution process that receives calls, passes them through a job router, invokes handlers, and sends results to consumers or protocol clients.
Is a Blueprint a smart contract?
No. A Blueprint usually includes off-chain executable code and may connect to a smart-contract manager for registration, service creation, payment, verification, or slashing rules. The application logic normally runs on operator infrastructure.
Does a Blueprint verify every result automatically?
No. The developer must define a result rule that matches the job. The rule might compare deterministic outputs, check a proof, validate an attestation, or run a task evaluation.
Can an AI agent call a Blueprint?
Yes, if the Blueprint exposes a trigger and schema the agent can use. The agent can call a normal HTTP path, a webhook, an on-chain job, or an optional x402-paid gateway. It should distinguish payment accepted, job enqueued, job completed, and result evaluated.
Public sources
Read the Tangle Blueprint introduction for the object model and roles.
Read the Blueprint Manager guide for the operator lifecycle.
Read the job-router reference for job dispatch.
Read the x402 gateway guide for paid job ingress and its 202 Accepted semantics.
Read the Tangle CLI reference and the Blueprint SDK repository for current commands, code, examples, and release versions.
Once the lifecycle is clear, the next design question is which verification mechanism belongs on each Job. That is the subject of How Tangle Verifies Work.