Changelog

[v0.95.1] - 2026-10-30

Fixed

• A caller webhook's attempt can continue when its delivery step runs again: DeliveryExecutor.execute_caller_delivery and deliver_caller_webhooks take a keyword-only host_attempt, the host's own attempt at the caller step counted from 1, and number the step's calls after every call its earlier attempts could have made, ATTEMPTS_PER_STEP per URL each, so a durable orchestrator that passes its attempt number when it retries the step has attempt keep increasing under the same webhook-id, possibly skipping numbers, where it restarted at 1. The default of 1 numbers each run of the step from 1 as before, so attempt stays informational and a receiver still deduplicates on webhook-id; a value below 1 raises ValueError before anything is sent. The delivery's log lines also carry event_attempt, the attempt the call carried.

[v0.95.0] - 2026-10-29

Added

• callback_urls and pipeline_run_id on /v1/execute: the API server's blocking run route takes the caller's webhooks, whose events are sent before it answers, and a caller-chosen pipeline_run_id, honored as /v1/start honors it, a run still in flight under the same id answering 409 pipelex.run.already_exists. PipelexMTHDSProtocol.execute takes pipeline_run_id too.
• COMPLETION_CALLBACK_URL, the deployment's completion target: the API server notifies this URL, which may name the run's id with one {pipeline_run_id} placeholder in its path or its query, when each /v1/start run ends, with the completion notice in the operator's view and its X-Completion-Signature. A malformed value, or one set without COMPLETION_CALLBACK_SECRET, stops the server at boot, and a /v1/start request's callback_urls entry equal to the run's completion URL is notified once, as the completion target, while on /v1/execute, which notifies no completion target, it is a caller's webhook.
• pipelex.webhook.secret_not_configured: a 422 registry code naming in setting the runner setting that holds no secret to sign a caller's webhooks with.
• The library delivers caller webhooks: DeliveryAssignment.caller_webhooks lists CallerWebhookTargets, each with the delivery_id its calls carry, and pipelex.tools.network.standard_webhooks signs a call in the Standard Webhooks format. DeliveryExecutor delivers a run in two steps a durable orchestrator may run apart: execute_host_delivery stores the results and notifies the host's webhooks, then execute_caller_delivery sends the caller's events, last and once, with how the run ended, which run_ending_after_host_failure gives when the host step failed. DeliveryExecutor.execute runs both, and takes the run's finished_at and extras.

Changed

• callback_urls receive the signed run.finished event (Breaking): each URL a request to the API server registers receives the caller-webhook contract's event, type, timestamp, attempt and data, the run as the protocol's status read serves it with a failed run's problem in the caller's view, signed with the Standard Webhooks headers webhook-id, webhook-timestamp and webhook-signature under the whsec_ secret or secrets in CALLER_WEBHOOK_SECRET. It replaces the completion notice and its X-Completion-Signature, which no caller webhook receives any more, so a self-hosted receiver now verifies the Standard Webhooks signature, and a server without CALLER_WEBHOOK_SECRET refuses a request carrying callback_urls with a 422 pipelex.webhook.secret_not_configured. Each URL is delivered on its own, three attempts within 15 seconds each and no redirect followed, and a delivery that fails is logged and never changes the run.
• The completion notice goes to COMPLETION_CALLBACK_URL alone (Breaking): a host that relied on callback_urls to receive the completion notice and its X-Completion-Signature, as a hosting platform does, sets COMPLETION_CALLBACK_URL to its completion URL before taking this release; otherwise its URL is a caller webhook and, on a server without CALLER_WEBHOOK_SECRET, every /v1/start carrying it is refused. The notice now always carries the operator's view of a failed run's problem, whoever started the run.

Fixed

• A /v1/start run whose dispatch fails gives its id back: the API server releases what it set up for a run its orchestrator could not enqueue, its registration, its graph tracer and its library, so the same pipeline_run_id can be started again; pipeline_run_setup's new companion release_run_setup does it for any host.
• A cancelled run is never reported completed: a run cancelled before it ended, which PipeRun re-raises the cancellation of, now tells its webhooks, the host's completion notice included, that it failed, with the problem run.cancelled, where the notice said COMPLETED; a delivery that fails afterwards never replaces the cancellation.
• A failed notice to a host's webhook names its reason: the pipelex.webhook.delivery_failed problem a run fails with when one of its host's webhooks cannot be notified carries the reason its code requires, http_status with the receiver's receiver_status, or unreachable.
• A refused webhook no longer replaces a failed run's own failure: a delivery destination the SSRF guard refuses after the run failed logs its security event and the delivery's failure, and the run fails with its own error, where the refusal used to be raised in its place.

[v0.94.0] - 2026-10-29

Changed

• mthds and pipelex-sdk versions (Breaking): The pins move to mthds==0.26.0, the release following the MTHDS standard's v8.0.1, and pipelex-sdk==0.57.0, the release built on it, whose own breaking changes since 0.53.0, such as list_runs and iterate_runs taking method_id as a keyword-only filter and method-version fields no longer coerced, reach anyone importing pipelex_sdk beside pipelex. Everyone downstream inherits those exact versions.
• MTHDS standard 8.0.1 and MTHDS Protocol 2.0.1 (Breaking): every crate pipelex normalizes, on the command line and on the API server's POST /v1/resolve, is stamped mthds_version: "8.0.1", a METHODS.toml whose mthds_version is exactly 8.0.0 now warns where >=8.0.1 passes, and pipelex --version, pipelex-agent --version and GET /v1/version report the MTHDS Protocol 2.0.1. Crate fingerprints do not move.
• The problems a run raises carry titles written for whoever follows it: every problem pipelex emits under a core code a run can raise, in a run's failure, an API server answer or the CLI's error output, carries the title the core error registry 8.0.1 gives it for someone following a run of a method they did not write: pipe.output_multiplicity is titled "A step produced a list instead of one result, or the reverse" where it read "A pipe's output does not have the declared multiplicity", and pipe.output_invalid "A step's result does not have the structure the method declares". No code, domain, retry verdict, step kind or status changes.

Fixed

• The API server checks a files map's blobs last: as the MTHDS Protocol 2.0.1 orders a map's refusals, a map holding a key the tree's rule refuses, colliding keys or a malformed entry is refused for that before any blob it names is read, where a hash held at another size than its entry states answered 422 request.invalid, and a damaged stored blob 500 pipelex.storage.damaged, ahead of the key's own refusal.

[v0.93.1] - 2026-10-28

Added

• pipelex.billing.credit_exhausted names the credit ledger that ran out: the code declares an optional ledger parameter, inference or usage, so the hosted platform's refusal of a run says whether the organization's inference credit or its usage credit is spent, and BillingCreditExhaustedParams gains the ledger field. A model call refused once the credit has run out names no ledger, as before.

[v0.93.0] - 2026-10-27

Fixed

• A direct provider's spent quota is read from its structure, not its wording: a call with your own keys to OpenAI or a backend on the OpenAI SDK, Anthropic, Google Gemini, Mistral or Amazon Bedrock is a spent quota only on the status, error code or error detail that provider documents for one, and is otherwise retried as provider.rate_limited. A 429 whose message mentioned a quota, as Gemini's per-minute throttles do, used to fail at once as provider.quota_exhausted. Anthropic's credit-balance and self-set usage-limit refusals, which carry no code, are still read, by their opening words.
• Throttles sent on another status than 429 are retried: OpenRouter's 402 for its in-flight budget, Groq's 498 for its flex tier at capacity, and Bedrock's ServiceQuotaExceededException, from Bedrock's SDK or from Claude on Bedrock through the Anthropic SDK, are now provider.rate_limited where they failed at once.
• Gemini's retry delay is carried: the delay Gemini gives in its error's RetryInfo detail, not in a Retry-After header, is now the failure's retry_after and is named in its advice.
• A delay in milliseconds is read: a retry-after-ms header above zero, which Azure OpenAI sends beside retry-after, is now the delay a rate limit carries, read first as the OpenAI and Anthropic SDKs read it, on a call through either SDK, Azure's REST API or a gateway. The transport retry of a call to Azure's REST API now waits that delay too, where it read Retry-After alone.
• More of Bedrock's wordings of an input over the window are recognized: a ValidationException saying "Input Tokens Exceeded" (Amazon Nova), "Too many input tokens" (Amazon Titan) or "prompt tokens (N) exceed model maximum (M)" is now model.context_exceeded where it was runtime.unexpected.

Removed

• ProviderErrorMetadata.is_quota_exhaustion (Breaking): a plugin reads ProviderErrorMetadata.limit_verdict instead, a ProviderLimitVerdict of quota_exhausted, rate_limited or neither, the one entry point the classifier reads.

[v0.92.3] - 2026-10-27

Fixed

• A gateway's rate limit is no longer read as a spent quota: a 429 relayed by a Portkey-dialect gateway is now provider.rate_limited, retried with the provider's Retry-After, unless its error code is one the provider documents for a spent quota: OpenAI's insufficient_quota, credit_balance_exhausted, organization_spend_limit_exceeded, project_spend_limit_exceeded or organization_usage_limit_exceeded. A 429 whose message mentioned a quota, as Azure OpenAI's throttles do, used to fail at once as provider.quota_exhausted with advice to add credit. A 402 is still a spent quota.

[v0.92.2] - 2026-10-26

Added

• A fetched method's provenance carries its declared name: MethodProvenance gains display_name, the display_name the package's METHODS.toml declares at the fetched commit, and null when it declares none, so the method_provenance of a method_ref run on /v1/execute and /v1/start reports it beside the address, tag, commit and tree digest, and a host can name the run's method after it. A fetched copy's .provenance.json sidecar records it too, and a sidecar or a record written without it still reads, its display_name null.

[v0.92.1] - 2026-10-26

Fixed

• The S3 storage provider reuses one client per event loop: each event loop opens one aiobotocore client on its first S3 operation, and every later operation on that loop shares it and its pool of S3_MAX_POOL_CONNECTIONS connections, where every operation, a presigned URL included, built a client and opened a TLS connection of its own; the client is closed as its loop shuts down or at the runtime's teardown, which now calls StorageProviderAbstract.teardown(), a no-op that a storage plugin keeping a client open between operations overrides to close it. Measured from a laptop against a bucket in another region, the API server's read of a method tree of 20 blobs went from 4,261 ms of wall time and 425 ms of CPU to 1,582 ms and 32 ms with this change alone.
• The API server reads each blob a request names in one request: a run, a validation and the tooling routes read each hash entry of files and dependencies with one read of at most one byte past the size the entry states, 16 at a time, where they looked each blob's size up first and then read the blobs 4 at a time; a hash held at another size still answers 422 request.invalid, its size looked up only for that refusal's message, and damaged bytes still answer 500 pipelex.storage.damaged. Measured as above with both changes, reading a tree of 1, 20 and 50 blobs takes 194, 419 and 838 ms of wall time and 1.3, 14 and 31 ms of CPU, where it took 1,142, 4,261 and 10,253 ms and 26, 425 and 1,000 ms. The local storage provider now reads such a leading range of a file without loading the whole file.

[v0.92.0] - 2026-10-25

Changed

• The API server refuses a method's unmet requirements as an invalid method (Breaking): /v1/execute and /v1/start refuse a method whose requirements.txt the PipeFunc sandbox does not meet, or holds a line the standard refuses, with a 422 method.invalid whose errors hold one method.dependency_missing or method.package_invalid item per refused line, located at requirements.txt and the line, the problem a local run of the method raises and the items /v1/validate gives, where they answered a bare method.dependency_missing or method.package_invalid with no item and no location; a client reads the refused requirement from the item's params and location.

Fixed

• A failed step's trace records the failure's own code: a failed node of the execution graph, and the pipe_end_error trace event, now carry the problem the run fails with when the step's error wraps a carrier of a problem recovered across a transport boundary, such as pipe.function_raised for a PipeFunc whose function raised in a sandbox, located at the step, where they carried the carrier's catch-all runtime.unexpected. The step's own message names that recovered code too, Error: <carrier class> (pipe.function_raised), and reported_failure_code (pipelex.pipe_run.located_failure) reads the code a failure reports without building its problem.

[v0.91.0] - 2026-10-25

Added

• OpenRouter model research: pipelex-dev openrouter list-models looks up the public catalog across modalities, filters and sorts models, and emits Markdown or clean JSON. --save writes disabled draft backend TOML with output-token limits and known token prices for review, independently of remote-config tooling.
• The validation report names the files each step reads: PipelexValidationReport, and so the valid verdict of /v1/validate, carries tree_files_read, mapping each validated pipe's pipe_ref to the files of the method's tree it reads, each a TreeFileRead with its tree_path and its use (template for a PipeDocGen step's template_file, template_asset for a file its HTML template names by a literal relative URL, python_module for the module holding a PipeFunc step's function), an empty list for a pipe reading none, and tree_file_readers, mapping each of those files to the pipes that read it. pipelex-agent validate bundle and validate method carry both in their envelope, and the Markdown of a valid verdict lists them in a "Files the steps read" section.
• A sandboxed PipeFunc reports its function's own failure: when the function a PipeFunc call runs raises inside a sandbox, python -m pipelex.pipe_operators.func.pipe_func_transported_entrypoint writes a PipeFuncRaisedReport to its result file before it exits non-zero, holding the operator's view of the pipe.function_raised problem, which names the function and the step and the class of what the function raised, never its text, while a sandbox failing any other way, such as a timeout inside it, still writes nothing there. An out-of-process executor reads the result file of a call that exited non-zero with read_pipe_func_raised_report (pipelex.pipe_operators.func.pipe_func_execution_transport), which answers the problem, rendered again from the registry and with only the diagnostics a sandbox writes, or None for no report or a report of any other code, and raises a Pipelex error carrying it, so the step reads pipe.function_raised as it does in process.
• A fetched package is checked against the calling method's methods.lock: when a method carries a methods.lock at the root of its tree, a package it calls by address that the runtime fetched itself, for this load or by an earlier fetch whose installed copy records its provenance, must have the tree digest the lock records for its address, whatever version the lock names, else the load is refused with the core code security.integrity_mismatch (domain method, a 422 with its security event on the API server), whose message names the locked and fetched versions and digests and says to pin the reference to the locked version or to lock the method again, or, when an installed copy answered a reference pinning another tag, says so and to remove that copy. A lock not naming the address, or no lock, checks nothing, and packages shipped with the method or installed by another tool are not checked. The lock is read only when a dependency resolves to such a copy, and one the runtime cannot read, one recording a hash from before tree digests included, then refuses the load with method.package_invalid and the new reason lock_invalid.

Changed

• Every S3 write carries its SHA-256 (Breaking): the S3 storage provider sends the SHA-256 of every object it writes, so S3 refuses a body that arrived damaged and keeps the checksum beside the object, where a HeadObject with ChecksumMode=ENABLED returns it, and a generated file's write carries the whole digest of which its key carries the first 16 digits; its client no longer signs the payload, which the signed checksum protects. StorageProviderAbstract.store takes the digest as checksum_sha256_hex from a caller that hashed the bytes already, and hands it to _store, so a storage plugin adds the keyword checksum_sha256_hex to its _store, sending it when its storage can check a write's checksum and ignoring it otherwise.
• pipelex-agent validate bundle --graph writes into an output folder (Breaking): the flowchart it draws, dry_run.html, and mermaidflow.html with --graph-format mermaidflow or both, go into a new numbered folder, <pipe_code>_output_<NN>/, under the results/ directory a run bundle of the same target writes to (beside the bundle file named, beside the bundle defining a folder's entry pipe, or in the folder's own results/ when --pipe names the pipe), holding the .gitignore a run's output folder holds, instead of beside the bundle drawn, so validating a method no longer adds files to its tree or changes its digest. Read each file's path from graph_files in the envelope, the Markdown listing them under ## Graph files, and the folder from graph_output_dir.
• The API server's examples send a method in files: the server's README and the API Server pages send a method to /v1/execute and /v1/validate in files, a map from each file's path in the method's folder to its content, where they sent mthds_contents. The reference pages and the OpenAPI artifact now say that mthds_contents, with bundle_b64, resources and /v1/validate's mthds_sources, is being retired and will be refused by a later release, so a client sends files now.
• A PipeFunc package-offer factory is never called on a thread running an event loop (Breaking): the factory a plugin registers with PluginRegistrar.add_pipe_func_package_offer may block for as long as its work takes and must not use an event loop of its caller's, and pipelex enforces it: a load that would call the factory on a thread running an event loop fails with PipelexUnexpectedError instead, so a host that calls a load itself from asynchronous code, such as a worker's activity, moves it off the loop with run_method_load (pipelex.libraries.method_load_threads) or with acquire_library_async (pipelex.pipeline.execution_seams), the twin of acquire_library that loads off the loop. The factory's signature is unchanged, and so is the plugin API version. run_method_load runs a blocking call in the method-load pool, a named pool of at most METHOD_LOAD_MAX_THREADS threads (four) apart from asyncio's default executor, in a copy of the caller's context, and when its caller is cancelled, the shutdown of asyncio.run included, withdraws a call no thread has taken yet or lets the cancellation through only once the running call has ended; the general mechanism is WorkerThreads (pipelex.tools.misc.async_utils).
• The refusal of a package the request did not send: the message of the unresolved_package_dependency refusal a static resolution gives, such as the one behind /v1/resolve, /v1/codegen and /v1/pipe-io, tells its reader to send the package's files in dependencies, keyed by its address, beside the method's own files in files, where it spoke of an in-memory resolve and the host filesystem and advised directory-based resolution; it still carries the words address-based dependency '<address>'.
• A run lists each method tree once (Breaking): the method trees a run reads, the method's own, its library directories' and its dependency packages', are each listed once, and the run loads the trees its caller listed, so the method_tree_digest a run records is the digest of the tree it loaded: PipelexMTHDSProtocol.execute, pipeline_run_setup, acquire_library, acquire_library_async, validate_bundle, validate_bundles_in_process, fix_bundle_file, fix_method_folder, and LibraryManagerAbstract.load_libraries and load_from_blueprints take tree_listing, a MethodTreeListing (pipelex.libraries.method_tree_listing) holding the trees already listed, which run bundle, validate bundle and fix bundle on both CLIs hand down from the listing that resolved their target. The listing reads a path as the standard's lister does before it takes anything from what it holds: a folder and a symbolic link naming it are one listing, since the lister follows such a link, a bundle file named alone inside a library directory shares the listing of the tree that directory roots, and a symbolic link to a bundle file, named alone, is refused as the lister refuses it, even once the run listed the file it points to. Loads of one run running at the same time list each tree once and list different trees side by side. The API server's run routes and /v1/validate load the trees their check of the method's requirements listed, which ensure_served_method_requirements_met now lists through tree_listing in place of its limits, and which reaches the in-process validator through scoped_tree_listing, so the bundle-validator plugin contract is unchanged. list_library_trees and list_library_dir_trees (pipelex.libraries.method_trees) take the lister of a directory's own tree or of its trees (own_tree_of, trees_of), through which the listing lists them, and tree_bundle_of_lone_file is removed: a bundle file named alone is placed in its tree with MethodTreeListing.lone_file_bundle.
• A run asks the PipeFunc package-offer factory once per tree: the run's MethodTreeListing keeps each method tree and each dependency package whose requirements.txt a check found met, with the execution mode and the factory it was judged against (PipeFuncEnvironmentSource, current_pipe_func_environment_source in pipelex.libraries.package_environments), so a run judges each tree once against them however many of its steps and loads read it, two loads judging one tree at the same moment ask once (MethodTreeListing.judge_requirements_once), and on the API server the load serving a request takes the verdict of the runner's check of the served method instead of asking the factory again. A check against another mode or factory, a refused tree and every new run ask again: pipelex keeps a verdict for one run alone, so a factory whose answer takes time keeps its own cache across runs, by the requirements' texts. ensure_method_requirements_met and ensure_package_requirements_met take the listing as tree_listing.
• mthds 0.25.0 and pipelex-sdk 0.53.0 (Breaking): pipelex pins mthds==0.25.0 and pipelex-sdk==0.53.0, the release whose errors carry the hosted API's problem document, so it implements the MTHDS standard 8.0.0 and the protocol 2.0.0, which the version handshake reports, and a method tree never holds a run's inputs file, inputs.json or inputs.toml at any depth, so a method folder holding one is listed, and digested, without it.
• PipelexMTHDSProtocol takes the protocol's files (Breaking): execute, start and validate take the MTHDS protocol's files map in the position the protocol gives it, and the local runtime refuses a map holding a file with request.unsupported and the reason method_files_on_local_runtime, METHOD_FILES_UNSUPPORTED_REASON in pipelex.errors.unsupported_reasons; mthds_contents is a keyword-only argument, which validate requires. The API server's ApiRunner takes the same arguments, and its routes, which write a method sent in files out as a tree before they run it, are unchanged.
• A hosted run sends its method as a tree (Breaking): pipelex run --hosted and pipelex-agent run --runner hosted send a local method to /v1/pipe-io, /v1/start and /v1/execute as the MTHDS protocol's files map, each .mthds bundle under its path in the method's tree and each library directory beside the method under a top-level folder named after it, inline up to 256 KiB and by hash beyond, where the run took the bundles' bare contents and pipe-io a list the runner now refuses with a 422, so a hosted run whose inputs name a local file reads the signature again, and a method that does not load is reported by the tree path of each faulty file. HostedRunRequest (pipelex.hosted.hosted_run) takes contents, each bundle's bytes by tree path, in place of mthds_files. A file of the tree that cannot be uploaded stops the run before anything starts, as pipelex-sdk's MethodFileTransferError, which both CLIs report with the SDK's verdict and a next step: run again, or report a file the storage refused. A bundle file given with -L that the membership rule keeps out of its tree, a hidden one under a dot segment or one .gitignore excludes, is refused before anything is sent, as a local run refuses it, where it was sent as it was.
• A hosted run's lost connection follows pipelex-sdk's reading: pipelex run --hosted and pipelex-agent run --runner hosted report a connection lost on the start or the execute request as HostedRunOutcomeUnknownError (client.outcome_unknown) whenever pipelex-sdk reads it as one that may have started the run (its problem's retry verdict outcome_unknown), a proxy's failure and a TLS handshake that was dropped included, which read as an unreachable API, while a connection lost on a request sent before the run's, such as the blob check of a tree sent by hash, stays pipelex-sdk's ApiUnreachableError.
• Both CLIs report a hosted failure as its problem (Breaking): pipelex run --hosted prints the problem pipelex-agent run --runner hosted reports, its title, detail, next step, code with its domain and retry verdict, request id, run and items, and a failed run's own problem below it, both read from pipelex-sdk's exc.problem through describe_hosted_error, which now takes credential_sent and returns the problem, the error's own sentence and pipelex's advice. The readers of the hosted API's answers in the shape that predates the problem document are removed: an answer that is no problem document keeps pipelex-sdk's reading by its status, except a bare 401 or 403, which reads as auth.missing_credential when no key was sent and auth.invalid_credential when one was, and a bare 404, request.not_found, each with the next step that names the CLI's settings. HostedMethodInvalidError carries the items of the pipe-io verdict as errors, the standard's problem items, where it carried validation_errors, and a run past the wait reports pipelex-sdk's client.follow_failed.
• pipelex-agent validate bundle and fix bundle exit 2 on a configuration refused before the boot: a configuration that does not validate, which these commands read before the boot for the limits a method's folder is listed under, exits 2, no verdict, where it exited 1, as pipelex validate bundle and pipelex fix bundle exit on it; the problem is unchanged, and run bundle and inputs bundle still exit 1.
• The development Python is pinned in .python-version: the library's .venv and the API server's api/.venv are built on the version the root .python-version names, and the Makefiles hand that version to every uv command, so PYTHON_VERSION=<version> make install now moves an existing environment to the version asked for, where it used to keep the environment's own Python without a word. The CI jobs that run another version set it for the whole job, and the matrix jobs check that each cell ran the version it names.

Fixed

• A hosted run refusing a local file names its reason: the request.unsupported problem pipelex run --hosted and pipelex-agent run --runner hosted report when the inputs name a local file and the method calls another by its address carries the parameters its code requires, field (inputs) and reason (local_file_with_address_dependency, LOCAL_FILE_WITH_ADDRESS_DEPENDENCY_UNSUPPORTED_REASON in pipelex.errors.unsupported_reasons), so a client can tell this refusal apart.
• A file name's type is the same on every Python: mime_type_of_file_name answers text/markdown for .md and .markdown, application/yaml for .yaml and .yml, and the OpenDocument types for .odt, .ods and .odp on every supported Python, where Python 3.11's table knew no Markdown and only 3.14's knew the others, so a file of these types has the format key md, yaml, odt, ods or odp whatever the Python, and a bare zip named .odt, .ods or .odp is identified as that OpenDocument type.
• A method edited between its listing and its load is refused: a run read its method's files again after listing them, so a file edited in between was loaded under a digest that named other bytes. Every file a load reads from a tree listed on this host, a bundle it parses, the requirements.txt it judges and the Python it scans, is now read against the hash the listing recorded, a load reads every file of a tree the run listed before it again, once per run, as it takes the tree, and the bundle text a CLI read for its run is checked against the listed file, so a bundle, a template or any other file of the tree edited, replaced or removed since the listing is refused before anything of the method is parsed, imported or run, with MethodTreeChangedError (pipelex.libraries.exceptions), coded method.package_invalid with the new reason tree_changed and the file's path in the tree; run, validate and fix report it as an invalid method whose item names that file. A requirements.txt that can no longer be read is this refusal too, where it was requirements_invalid. The checked reads are read_tree_file_as_listed, read_tree_bundle_as_listed, ensure_tree_files_as_listed and ensure_bundle_text_as_listed in pipelex.libraries.method_trees, MethodTreeListing.loading() marks a load reading a listing and ensure_unchanged() checks a tree a caller placed a bundle in, and MthdsParser.make_pipelex_bundle_blueprint takes the bytes it parses as bundle_data, beside the bundle_path that names them.
• Method loads leave the event loop: every method load pipelex reaches from asynchronous code, a run's, a validation's and those of the commands that run a loop, runs in the method-load pool, where it ran on the event loop, the reading and parsing of the bundles it loads included, so listing and hashing a method's files, a sandbox's judgment of its requirements.txt and a fetch of a package it calls by address no longer hold up the other requests or activities the loop serves; the API server's run routes and /v1/validate also write a request's method tree to disk and remove it there, and judge its requirements there, so a client that disconnects never has the tree removed while the check still reads it, the crate routes resolve and project there, and the in-process validator reads a tree's entry pipe for its graph there too. A module imported by file while a method loads, such as one defining a structure class, is published and executed under a lock that the load's class discovery also holds, so two loads in parallel never take a module half executed, and a module that fails to execute leaves sys.modules rather than stay there half imported. /v1/validate of a method tree calling a package nothing shipped still resolves it as a run does, from the methods installed on the server and by a fetch on a miss, so its verdict matches the run's, and the fetch now runs off the event loop.
• Where a method's Python travels, in the docs: the PipeFunc Requirements, PipeFunc and run pages say that the API server receives a method as a tree holding its bundles and its Python together and judges its requirements.txt from the tree's listing, that the runner never imports a method's Python, that a run's crate names each step's method tree by its digest and carries none of its files, that a PipeFunc call's files are read through the method file store the worker's host installs, and that a worker a method tree's validation is dispatched to checks the method's requirements again, where they said the server received a method's Python apart from its bundles, the Python was captured as text, the crate carried the method's Python sources and the worker never checked anything.

Removed

• resolve_crate_from_contents (Breaking): pipelex.pipeline.resolve_bundle no longer resolves a crate from bundle contents held as strings. A host resolves a method as /v1/resolve, /v1/codegen and /v1/pipe-io do, by writing its tree out and calling resolve_crate_from_method_dir, with the packages it ships in methods_dirs; a call into a package nothing shipped is then an unresolved_package_dependency item of the invalid verdict, never the request.unsupported refusal with the reason address_based_dependency, which no resolution of this release gives: its constant ADDRESS_DEPENDENCY_UNSUPPORTED_REASON (pipelex.errors.unsupported_reasons) is removed with ADDRESS_DEPENDENCY_REFUSAL_MARKER (pipelex.methods.address_dependencies), and a hosted run no longer reads that refusal from /v1/pipe-io, only the invalid verdict naming the package nothing shipped.

Security

• aiohttp 3.14.5 in the API server image: the lock the pipelex/pipelex-api image installs from moves aiohttp past GHSA-494j-54xm-rwp3, GHSA-5wr8-gcqf-gqf3 and GHSA-2g87-pp6c-29x5, with yarl 1.25.1 alongside; the published pipelex wheel's own requirements are unchanged.

[v0.90.0] - 2026-10-19

Added

• The Pipelex error registry: the codes Pipelex emits beyond the MTHDS core registry, under the pipelex extension prefix the core registry registers to it, are authored in one public file in the MTHDS error registry format, pipelex/errors/registry/pipelex-error-registry.yaml, each declaring its title, domain, retry verdict, steps, typed parameters, templates and status. The package ships its JSON snapshot, pipelex-error-registry.json, published under Pipelex's version, a pre-release's written in the SemVer form the registry format requires (0.88.0rc1 as 0.88.0-rc.1), which load_pipelex_error_registry() reads into a typed model, and every release attaches the snapshot to its GitHub release.
• pipelex.errors.registry.pipelex_codes: PipelexErrorCode, a member per code of the Pipelex error registry, and for each code a closed, frozen and strict parameters model typed as the registry declares, with the code and its operator-only parameters as class attributes, PIPELEX_ERROR_PARAMS mapping each code to its model.
• A documentation page per error code: docs.pipelex.com documents each code of the Pipelex error registry on its own page, under the Error Codes index at errors/, and its type URI, https://docs.pipelex.com/errors/<code>, leads to that page once a release documenting the code is the latest.
• pipelex-dev generate-error-registry and pipelex-dev check-error-registry (make ger, make cer): generate the registry's snapshot, its typed Python and its pages from the source, refusing a source the format's JSON Schema, the typed model or the registry's rules refuse, or check that every derived file is what the generator writes; pipelex-dev write-error-type-redirects writes the redirects that make a code's type URI resolve, which every documentation deploy runs.
• Every error carries its registry code: every PipelexError subclass declares in error_code the code it raises, a code of the MTHDS core registry or of the Pipelex error registry, or else an ErrorCodeSet its raise sites choose from with with_error_code(), its cause's code (InheritsCause, with a fallback), or ABSTRACT_ERROR for a base never raised itself. resolve_error_code() gives the code an error reports, the first one named along its cause chain, and runtime.unexpected when none is; pipelex.errors.error_codes reads any code's title, domain, retry verdict, status and steps (error_code_spec, parse_error_code).
• PipelexError.with_items(): a raise site that finds several faults of one kind gives one problem item per fault, so a PipeParallel whose branches give several results of a multiplicity their fields do not declare names each one in its pipe.output_multiplicity problem's errors, beside the first in its sentence.
• PluginRegistrar.declare_error_codes: a plugin, a closed one included, declares the public codes it raises while it registers, and a code neither the MTHDS core nor the Pipelex registry defines refuses the boot with PluginErrorCodeNotRegisteredError (pipelex.plugin.broken), naming the plugin and the code.
• --error-format on pipelex-agent itself and on its inputs commands: the error format can be given before the command, pipelex-agent --error-format json validate bundle …, where a command's own --error-format still wins and its --format still serves when neither is given, so a caller forwards one flag whatever the command; the inputs commands take --error-format too, falling back to the program's and then to JSON, never to their --format, which is the template's serialization.
• InputFreeValueError and the input-free rendering of a refusal: a pydantic validator raising InputFreeValueError (pipelex.tools.typing.validation_exceptions) declares that its message names nothing of the value it refused, which keeps its sentence wherever a refusal of a run's data is written, and format_validation_error_without_input() and describe_exception_without_input() (pipelex.tools.typing.pydantic_utils) write a ValidationError as its locations and reasons, never the values it refused.
• PipelexRequestError: the runtime's own refusal of a request it cannot serve is a PipelineRequestError of the mthds package carrying the core code request.invalid (or request.unsupported) and its problem document, so a client reads the same refusal whether the runtime or the standard's client raised it.
• Validation warnings as problem items: warning_problem_items() in pipelex.pipeline.validation_errors gives a valid report's warnings as problem items, each under the code its type names, a hint lint's method.hint_invalid naming its hint from the new ValidationErrorItem.hint_key and located at the declaration the hint is on, a concept at concept.<Concept>, a field of its structure at concept.<Concept>.structure.<field>, a pipe's input at the pipe and the input, and root_escape_of(), whose RootEscape gives both the reason a path leaving its root is refused and its rule, and path_refusal_error() in pipelex.core.bundle_resources.bundle_resource, which builds the refusal of a submitted file's path from that escape, with its code and its parameters, the rule of security.input_path_refused or the field resources of request.invalid.
• The security event: a refusal coded in the security. or pipelex.security. family fails its run under that code and logs one record on its own logger, pipelex.errors.security_event, at warning level, with the message A security rule refused a request and event.name set to pipelex.security.refusal, naming the code, its domain, the kind of target refused, the class of destination when the rule knows it (loopback, private, link_local, metadata, scheme, foreign_storage_key, which the caller's problem states as the registry's private, since its sentence reads the class as a word), the run, the request and each of the run's extras as run.extras.<key>, which the API server reads off a request's analytics_groups as soon as its JSON body is parsed, on the diagnostic routes as on the run routes, and never the URL, path, template or any input value. The process that raises a refusal logs it, once: the pipe run for a refusal raised while it executes, its delivery included, the validation sweep for one a dry run meets before its pipe run starts, such as while its mock inputs are built, the runner for one before the run exists and for one raised in its own process that no pipe run logged, and the API server for one answered before any run, the refusals it authors itself included (a reserved object key, a callback URL the SSRF rule refuses, a resource path or a method file path leaving the method: absolute, naming a drive or a network share, or climbing with .., read with either separator, while a path of the wrong shape, empty or holding a backslash or a colon, logs none and is request.invalid as a key of resources or a file submitted beside a method, and method.package_invalid with the reason invalid_tree_path as a key of files or a member of bundle_b64), which keep their response, while a failure rebuilt from another process's report is never logged again, since the orchestrator that rebuilds it marks it, and no event names a run id a request body chose; pipelex.errors.security_event gives a host emit_security_event(), mark_security_event_emitted() and log_security_event(), and a raise site states the class of destination with PipelexError.with_security_target_class().
• pipelex.test_extras.required_params_sweep: spy_on_problem_warnings, set before a test, and assert_problems_carried_required_params, run after it, fail a test that builds a problem or an item lacking a parameter its code requires, unless the test carries the builds_problems_without_required_params marker with its reason, and the library's unit tests and the API server's run under them.
• pipelex.request.dependency_key_mismatch: a dependency a run or validation request keys by another address than the one its own METHODS.toml declares, such as its repository's address alone, is refused with this 422 code, whose key and address parameters give the key sent and the address to key it by, where it was a generic request.invalid.

Changed

• The problem document replaces ErrorReport (Breaking): every PipelexError answers a problem document, PipelexError.to_problem(view=...) building a PipelexProblem (pipelex.errors.problem), where it built an ErrorReport: its type, title, status, domain, retry and next_step are its code's, its type the code's page (https://mthds.ai/errors/<code> for a core code, https://docs.pipelex.com/errors/<code> for a Pipelex code), its detail and its step are rendered from the code's templates and the parameters the error gives, the code's title standing in for a sentence a missing parameter leaves unrendered, a refusal of several faults lists them in errors, and the Pipelex members request_id, run_error and diagnostics join the standard's. A problem never writes a member a model declares as null, while a null an extension member or a free-form object holds is written as it was read, to_wire() writes back every problem a reader accepts however deeply an extension member nests, a parameter of a type its code does not declare, an infinite or NaN number and a value that is neither a JSON scalar nor a list of them included, is dropped and logged rather than raise in place of the error, and an item never carries a parameter its code keeps for the operator, whoever built it, the caller reading an item whose code this process does not know with no parameter and a generic sentence. ErrorReport, TracedFailure and the graph's ErrorSpec are gone, and error_type is no member of a problem: the operator reads the error's class as diagnostics.error_class.
• The reader's identity picks the view of a failure (Breaking): a problem is read in the caller's view, its sentences rendered from the parameters a caller may read, or in the operator's, which adds diagnostics (the error's class and message, its causes, the model, the provider's answer, a migration, the runtime version and the trace) and the operator's own next step; DisclosureMode, the ERROR_DISCLOSURE setting and caller_facing_message are gone, and caller_view_of() projects an operator's problem to the caller's, giving a code this process's registries do not hold the generic step of its kind, report for an operator's code. The runner answers the operator's view to a request carrying its static API key (AUTH_MODE=api_key) or reaching it through a trusted proxy (AUTH_MODE=none with TRUST_FORWARDED_IDENTITY_HEADERS=true), which owes its own callers their caller view, and the caller's view to every other request, and a webhook receives the view its target's problem_view names, the caller's by default, the problem built only for a run that has a webhook and never replacing the run's own error when it cannot be built.
• The runner answers each code's HTTP status (Breaking): an error response's status is its code's, from the error registry, where it followed the error's domain and a table of per-class overrides, so provider.unavailable answers 502, provider.timeout 504, model.unavailable 501, a method that cannot be fetched (method.fetch_failed) 502 where it answered 422, and a fetched method declaring Python structures (pipelex.deployment.python_structures_refused) 422 where it answered 403; Retry-After rides a 429 alone, and an exception that is not a Pipelex error answers runtime.unexpected, a 500.
• An input refusal names the input and what is wrong with it: a refusal of a run's inputs carries the input in params.input and location.input, with the facts its code declares, the expected and provided counts of input.wrong_multiplicity, the declared and provided concepts of input.wrong_concept and the field at fault of input.invalid when the concept's structure names one, so its detail names the input and its fault; a refused file, whether its url is blank or malformed, its storage reference names nothing, its data URL or local path cannot be read, the run may not read it, or its format is one its input or its model cannot take, names the run's input as input and the path down to the file as location.field, such as documents[1], or documents[1].url for its url, which input.invalid also gives as its field. A CSV table input refused before it is read says what happened: a url that does not parse is input.file_unreadable, a url that is not a local path request.unsupported with the reason remote_table_url, and a concept with no structure class method.concept_invalid, where each was an input.invalid about the concept's structure, and every CSV refusal, before or while the table is read, is located on the input in location.input.
• A run failure's problem names its pipe and path: the problem of a run that failed inside a pipe carries the failing pipe and the pipes leading to it as location.pipe and location.path, and fills the pipe parameter of a code that declares one, while a failure of the entry pipe before any step carries no location. The location also keeps what the errors between the run and its root fault know, such as the field and the file a pipe met an unknown model at, and the diagnostics keep the model and the backend a worker attributed the failure to on an error above the root fault, an inner router's stand-in for a foreign exception included. A parameter a wrapper above the error whose code the problem reports gave, and its code declares, fills the one that error gave none of, and the items a wrapper gave follow that error's own.
• A graph node's error is its problem (Breaking): a failed node of a GraphSpec, and the trace event that ended its pipe, carry the problem in the caller's view in error, located at the node's pipe and path, and the stack trace, when the graph's data inclusion asks for it, in error_stack, capped at the same length on both, where error held error_type, message, stack and caller_facing.
• Plugin API v9 (Breaking): an HTTP-error mapper registered with add_http_error_mapper(exc_type_provider=..., to_pipelex_error=...) returns the PipelexError a transport exception stands for, where to_error_report returned a report, and a bundle validator's validate_bundles returns a BundleValidationFailure, the refusal's problem in the operator's view with its validation items, as its invalid verdict, and a host plugin's carrier of a problem recovered across a transport boundary overrides PipelexError.recovered_problem() to return it rather than overriding to_problem(), which a located run failure no longer reads as a carrier; PLUGIN_API_VERSION moves to 9, so a plugin declaring targets_api = 8 is refused at discovery with PluginApiVersionMismatchError.
• pipelex.test_extras.problem_parity (Breaking): the parity fixtures a distributed executor's tests share with the local runner's moved from pipelex.test_extras.error_report_parity, and their classes are ProblemParityTestData, SearchProblemParityTestData and JudgeProblemParityTestData.
• A run failure reports its root fault's code (Breaking): the root fault a run failure's problem reports is the first error down its cause chain that declares a code of its own, and its code, title, type, domain and retry verdict are the problem's, with no runtime floor on the domain; a consumer that branched on the wrapper's error_type branches on code. A PipeFunc whose function raised reads pipe.function_raised whatever it raised, a coded error of a helper the function called included, which rides as the cause, while a failure of the executor running it, such as its timeout, keeps its own code, and an exception an executor lets through that is not a Pipelex error, such as an out-of-process executor's transport failure, reads runtime.unexpected. A failure below an exception that is not a Pipelex error lends the error above it no code, fact, location or advice.
• The runner's own refusals are coded problem documents (Breaking): every error response of the API server, a 404 for a path no route serves, a 405 and a 413 included, is a problem document carrying a registry code, and the API's ErrorType is gone with the error_type, error_domain, retryable and instance members, the tree_refusal, missing_blobs and mismatched_blobs members becoming the code's parameters or the operator's diagnostics. A field the runner refuses is request.invalid naming it as params.field, with one item in errors per refused field up to a bound, which the operator's diagnostics.message keeps too, saying how many more faults there were, a rule over several fields naming the one to change, such as the second of two selectors sent or mthds_sources beside a method_ref, a body or a part of one it cannot parse request.malformed with a reason, a size limit request.too_large with its limit and the size in bytes, an encoded value measured by the bytes it carries, and a method tree it cannot read method.package_invalid with a reason, the standard's tree refusal code or one of the runner's own, one per rule and one per limit, so an archive past its member count reads bundle_too_many_files, while a body refused beyond its schema on /v1/execute or /v1/start (a bundle sent with mthds_contents, method_ref beside a bundle, resources or dependencies without their files, no run source, a hosted-only field such as method_id) answers a PipelexRequestError carrying request.invalid or request.unsupported; the API's ProblemDocument schema documents code, and request_id, taken from X-Request-ID or minted, is what correlates a response with the server's log.
• The runner's refusals answer their code's status (Breaking): an orchestration-mode override the deployment forbids is a 422 where it was a 403, custom Python on a deployment that is not sandbox-hosted a 501 where it was a 403, /v1/start on a blocking-only deployment a 501 runtime.unsupported where it was a 400, a registry-form method_ref a 422 request.unsupported where it was a 501, invalid base64 and a client gone mid-upload a 422 where they were a 400, an archive past its file-count or decompressed-size ceiling and too many resources a 422 where they were a 413, a blob past the per-file limit a 413 where it was a 422, a forwarded X-User-Id that is not path-safe a 422 request.invalid naming the header where it was a 400, a body FastAPI could not parse, holding bytes that are not UTF-8 or an integer past Python's digit limit, a 422 request.malformed with the reason not_utf8 or integer_too_long where it was a 400, while the framework's own refusals, plain {"detail": …} bodies until now, keep their status under a code whose required parameters the runner can fill, a 400 as request.malformed with the reason unreadable, a 401 as auth.missing_credential keeping its WWW-Authenticate challenge, a 403 as auth.invalid_credential, a 413 as request.malformed with the reason too_large, a 429 as runtime.unavailable keeping its Retry-After, and any other, such as a 415, as request.malformed with the reason unreadable, a read_scope a jwt caller may not read a 403 auth.forbidden whose requirement is read_scope_under_caller where it was a 403 ReadScopeForbidden, and a token whose claims the runner cannot use a 500 where it was a 401; a 401 carries WWW-Authenticate: Bearer only where the deployment reads a bearer token (AUTH_MODE=api_key or AUTH_MODE=jwt), so behind a trusted proxy a missing X-User-Id is a 401 asking for no token.
• Damaged stored bytes are a damaged stored file, never retried: bytes the API server's blob store holds under a hash that do not hash to it, or are not the size it holds them at, answer a 500 pipelex.storage.damaged, a new code of the Pipelex error registry, naming the kind of storage, plugin for a storage plugin's own, whose verdict is not to retry, since a retry reads the same damaged object, and which /v1/execute, /v1/start, /v1/validate, /v1/resolve, /v1/codegen, /v1/pipe-io and PUT /v1/blobs/{sha256} declare in their OpenAPI responses; the server's line naming the object to remove, Stored blob bytes do not match their hash, carries blob_sha256, blob_size_bytes, read_size_bytes and storage_scheme.
• The /validate Markdown presents the verdict's items (Breaking): the opt-in rendered_markdown of an invalid verdict is rendered from the problem items its errors holds, in the same view, each under its code's title with its code, location, sentence, suggestions and suggested fix, so a caller reads no wording its view of the items leaves out, where it rendered the validation items' own messages; pipelex.pipeline.validation_render.render_invalid_verdict_markdown(items=..., message=...) replaces render_invalid_validation_markdown(report).
• The diagnostic routes' verdicts carry problem items (Breaking): the invalid arm of /v1/validate, /v1/resolve, /v1/codegen and /v1/pipe-io carries errors, one problem item per finding with its code, detail, params and location and a suggested fix naming its file as file, where it carried validation_errors, the valid arm's warnings are problem items too, and a top-level member a verdict has no value for, such as default_pipe_ref or graph_spec, is absent rather than null. The OpenAPI artifact no longer publishes ValidationErrorItem or pipelex's SuggestedFix, and names every schema reachable from the standard's problem item with a Problem prefix, such as ProblemSuggestedFix and ProblemSetKeyOp.
• Pipe selection refusals carry the code of their case: an entry pipe the selector names but no closure declares reads request.pipe_not_found, offering as its suggestions only pipes the caller may select, the method's own for a bare or domain-qualified code, never a pipe of the server's own library directories, and for an alias->… code the pipes that dependency exports, a bare selector matching pipes in several domains request.pipe_ambiguous, a request with no selector over a closure declaring no main_pipe, or several, request.pipe_unspecified, naming the declared ones as its candidates, a manifest main_pipe the closure lacks method.pipe_unresolved, naming the main_pipe declaration as its pipe and the nearest declared pipes as its candidates, and one it declares in several domains method.ref_ambiguous, all still a 422, a dependency's alias->code matching pipes in several of its domains naming them as candidates too; a run of a method on disk with no pipe named refuses several declared main_pipes and a manifest main_pipe several bundles define the same way.
• PipeIOContractError is the method's (Breaking): a structure that cannot be projected into its IO contract answers a 422 carrying method.concept_invalid, naming the concept and the finding, where it answered a 500.
• Storage and remote-file failures say whose they are: an S3 or GCS refusal of the deployment's credentials (AccessDenied, an invalid or expired key, Forbidden) carries pipelex.config.credential_refused, a bucket that does not exist pipelex.config.invalid and missing credentials pipelex.config.credential_missing, apart from an outage, pipelex.storage.unavailable, naming the kind of storage; a remote file that times out, refuses the connection or answers a 5xx, 408, 425 or 429 is input.url_unreachable, which a retry may cure, and any other failed fetch input.file_unreadable.
• Builtins raised where a reader sees them are coded classes: refusals that raised a bare ValueError, RuntimeError, ImportError or NotImplementedError raise a coded PipelexError, such as RunParameterError for a run's metadata, extras or storage scope (still a ValueError), ExportedPipeNotFoundError and ExportedPipeAmbiguousError for a CLI pipe selector, BundleClosureEmptyError, StorageNotConfiguredError, UrlSyntaxError, LocalFileMissingError and UnsupportedImageMimeTypeError, and the classes that were rooted outside PipelexError (PipeValidationError, ConceptValueError, QualifiedRefError, SemVerError, MethodNotFoundError and the like) join it.
• Inference failures carry the code their classification picks (Breaking): the classification of a provider's failure picks a code with its category, a ServiceErrorCode a plugin contributes names its error_code, and a category that repeats the call within the run must pick a code that invites a retry; an error built with a category alone reports the category's code (provider.unavailable for TRANSIENT, runtime.misconfigured for CONFIGURATION, provider.quota_exhausted for CAPACITY, provider.outcome_unknown for AMBIGUOUS). A provider 400 that carries no context-window or content-policy signal is runtime.unexpected, answered 500, where it was the caller's 422, and a local extractor's OSError is runtime.unexpected, no longer repeated within the run.
• One rule for a request id (Breaking): a run's request_id holds ASCII letters, digits, _ and - alone, at most 128 of them, the rule the API server applies to an inbound X-Request-ID, now one function, pipelex.system.job_metadata.is_valid_request_id(), where a run accepted any printable ASCII, a space, a quote or an = that could forge a field of a key=value log line or a parameter of a header included; RunParameterError no longer quotes the refused value.
• A truncated completion says which limit cut it: LLMCompletionTruncatedError carries model.output_truncated when the method's max_tokens cut the answer and model.context_exceeded when the context window did, both the method's to change.
• ModelDeckPresetValidationError is spelt right (Breaking): the error a model deck preset that fails validation raises was ModelDeckPresetValidatonError, and its reports carried that error_type; a consumer that branched on the old name branches on the new one, or on its code, pipelex.config.invalid.
• Usage statistics carry the error's code (Breaking): a failed command_completed or run_completed carries the code of its error in error_code and that code's domain in error_domain, now one of input, method, account, operator and runtime where it read input, config, runtime or other, and a model_used counts its failed calls by the domain of their code, in failures_input, failures_method, failures_account, failures_operator and failures_runtime, where it counted them by the runtime's inference category, which no event carries any more. A failed hosted run's command_completed carries the code and the domain the hosted API sent, and none when it sent none, and every surface reads a refusal a server answered by that rule, a run's run_completed reading the catch-all where nothing was sent rather than the code the client infers from the status. Every event's schema is 2, so a receiver tells these events from an earlier release's.
• pipelex-agent reports a failure as its problem (Breaking): the agent CLI's error stream is the failure's problem in the operator's view, Markdown by default and JSON with --error-format json: its code, domain, retry verdict and next_step, its params, location and errors, its request_id and pipeline_run_id, and diagnostics with the error's class, the model and the provider of a failed call and a pending configuration migration, which rides diagnostics.migration where it rode migration, beside the command's own message and members. The envelope's error, error_type, error_domain, error_code, error_category, retryable, hint, validation_errors, error_source, and a failed run's pipe_code, pipe_stack, cause_type and cause_message, are gone, and so are AGENT_ERROR_HINTS, AGENT_ERROR_DOMAINS, AGENT_INIT_FAILURE_HINT, run_failure_fields() and extract_validation_errors(): an agent branches on code, an invalid verdict's items are the problem's errors, a failed run is located by location.pipe and location.path, and the advice an error's chain gives is a Markdown tip, a boot that fails with no advice of its own tipping the recovery path through doctor, migrate and init. A refusal the CLI makes itself carries its own code, client.argument_invalid for an argument, client.file_unreadable for a file it cannot read, the bundle file of every bundle command included, client.tool_missing when plxt is not installed, and pipelex.config.file_missing when init finds a configuration file it should have written missing, and an exception that is no Pipelex error reads runtime.unexpected, an error of the system that names no file, such as a refused connection or a timeout, included. A bundle file that is not UTF-8 text does not parse, so run bundle and fix bundle report it as validate bundle does, the invalid verdict with a method.syntax item, where run bundle read it as a file it could not read; fix bundle codes the errors left as validate bundle codes them, where an item no stage classified read method.schema_violation, and a fix it cannot write is client.write_failed. The Markdown lists the problem's items one per line, each with its code, sentence, location, suggestions and suggested fix, an invalid verdict's included, where it rendered a verdict's items as validate's category-grouped prose. A run on a runner (--runner hosted) that fails reports the problem the runner answered or the client decided, as it came, by the members the standard and Pipelex declare alone, in the caller's view: the runner's problem document with its errors, client.unreachable naming the base URL for a runner that cannot be reached, client.outcome_unknown for a server fault on the run request, and run.failed naming the run for a run that started and failed, the client's own sentence as message, nesting the run's own problem as run_error in the caller's view, read off its stored report whatever its shape; an answer in the shape that predates the standard's reads as the core code its status and the hosted plane's own code name, auth.invalid_credential, auth.missing_credential when no key was sent, auth.forbidden for an operation the platform refuses a key it accepted, under one of its authorization codes, request.not_found, run.not_found or method.not_found, or account.rate_limited with its retry_after, a runner's refusal of a method that does not validate lists its validation items under method.invalid, and any other such answer keeps the client's client.response_unreadable with the reason it gave; each takes the next step pipelex run --hosted gives, of the kind the answer's advice names when it gave one, and so does a failure the client meets on its own side; what the CLI refuses before sending it is a problem in the operator's view, and so is a failure of its own, under its own code, except a method run bundle refuses while reading it, a bundle that does not parse or validate or a bundle file or folder with no pipe to start at, which reads in the caller's view as the runner's refusal of the same method would, with its code, items, locations and next step and neither diagnostics nor message.
• The pipelex error panels print the problem: a panel names the problem's title, its detail, its next step, its code with its domain and retry verdict, its location and its request id beside the fields it printed, and a run that fails, or any failure a command root catches, prints its problem the same way on stderr, where it printed one line with the message. Every panel, an invalid bundle's, an unavailable model's or a telemetry file's included, and the stack trace --traceback adds to it, now goes to stderr, where the panels and their stack traces went to stdout, so a command's piped output holds only what it produced.
• A configuration refusal names its setting and its file: pipelex.config.invalid raised for a configuration that does not validate, a telemetry configuration, a tracing sink or what a former release left in the inference configuration names the setting, its file and the configuration it belongs to in the operator's next step, a file the refusal can single out, a former release's or one that does not parse (pipelex.config.syntax, where pipelex show config named pipelex.toml whichever layer failed), named relative to the working directory or as ~/… under the home directory, never with the home directory's account, and its advice, the tip a CLI prints, follows the pending migration, pipelex migrate when it would rewrite the files and a correction by hand when it would not, and else the refusal's code: pipelex init for a missing file, setting the variable for one that is not set, and pipelex doctor for a configuration that does not validate or parse. The refusal of what a former release left carries in diagnostics.migration what pipelex migrate would do about it, from the cleanup's dry run, so a JSON reader, who gets no tip, reads the remedy too.
• A pipe's failure line carries its code, not its text: The execution of a pipe failed carries the problem's error.code beside error.type and no longer error.message, so a log query selects failed pipes by code, and the line holds neither the caller's own text, a function's message or a template's source, nor a refused host.
• Jinja2TemplateSecurityError is a SecurityError (Breaking): the template sandbox's refusal at render time now derives from SecurityError, like UriReadRefusedError, SsrfBlockedError and UnsafeSchemaError, instead of ToolError, so a host catching SecurityError catches it too and an except ToolError no longer does; it stays a type of its own, apart from Jinja2TemplateRenderError, and its class name, which the operator reads as diagnostics.error_class, its code, security.template_refused on a method's template, its title and its classification are unchanged.
• A security refusal is never a validation verdict (Breaking): a refusal a raise site coded in the security. family is let through by the bundle-validation cascade whatever its class, as a SecurityError always was, so a PipeDocGen step whose template_file climbs above its method tree's root fails validate and a run with security.method_path_refused and logs its security event, where it was a method.invalid verdict naming the pipe; a refusal a validation's dry run meets, such as a template the sandbox refuses at render, fails it the same way under its own code, every failure riding its items and the event logged once, where it was an item of an invalid verdict.
• mthds 0.22.1 and pipelex-sdk 0.46.0 (Breaking): the exact pins move from mthds==0.22.0 and pipelex-sdk==0.45.0 to mthds==0.22.1, the release whose errors carry the MTHDS problem document read by its registry code, and pipelex-sdk==0.46.0, the release built on it; everyone downstream inherits those exact versions.
• A problem carries every parameter its code requires: every problem and item the runtime and the API server build gives each parameter its code's registry entry requires, so its sentences state the occurrence rather than the code's generic wording: a model no catalog knows offers its suggestions, an empty list when none is near, an invalid identifier names its identifier_kind and name, a name declared twice, or a native concept declared again, names the name and the conflict in one item per bundle, each located on its own file and on the colliding declaration's path, such as concept.Rating, in a validation verdict and a run's refusal alike, while a batch item named as its list stays on its pipe and the field it collides on, input_item_name or a step's steps.0.batch_as, an unresolved concept and a selected pipe the method lacks offer the nearest declared ones, a pipe reference naming nothing the pipe whose body writes it and the nearest pipes it may name, of a dependency only those it exports unless the reference is written in that dependency, and beside a server's own library directories only the pipes of the bundles the request sent, a template the sandbox refuses names what it reached for as name when its own source spells it, the format string a .format call formats included but no other string literal, and is located on its pipe and the field the template is written in, while a name the run's data chose is withheld and its sentences say the template looked a name up from the run's data, a validation item gives the facts its check knows (the concept a pipe declares and those that would fit, the multiplicity it declares and the one its use expects, the site where an optional value escapes, the path a binding cannot follow), and method.package_invalid always gives its reason, tree_unreadable for a tree that cannot be listed among the new ones. A failure met while running names its facts too: a stored file gone and a storage outage name the kind of storage as scheme, which a storage provider's new storage_kind gives, plugin unless a provider says otherwise, a pipe added twice to a library, a duplicate branch output and a module the tree shadows name the name and the conflict, a file a model cannot read its format and model, a remote file that cannot be fetched its host or its reason, a completion the context window cut, and a prompt a provider refuses as over the context window, its limit, a Gemini image a filter refused its model, a model a provider does not know or refuses and a waterfall with nothing served the model_type and reason of model.unavailable, a PipeFunc past its deadline its function and timeout, a PipeJudge question that reads a file the step's input and the concept it declared, a requirement whose extra needs a missing or mismatched distribution that distribution with not_found or no_matching_version, a call to a pipe another domain of the package does not export the pipe and the package, one item per call located on the bundle, the pipe and the field that write it, and bundles declaring a reserved domain, which a package's METHODS.toml refuses as method.name_conflict too, or two declarations of one name whose bundles are unknown, one item each, on its own file. ValidationErrorItem and PipesAndConceptValidationErrorData carry those facts in params, and the problem builders log A problem lacks a parameter its code requires when a raise site gives fewer, except for a parameter withheld by rule, the refused name a template looked up from the run's data.
• A refusal of one fault carries no errors list (Breaking): a problem whose only item restated its own code, such as /v1/models/check's refusal of a missing reference or a template the sandbox refused while validating, carries that item's parameters and location itself and no errors; a refusal whose single item has another code, such as method.invalid over one fault, keeps its list, and one whose single item carries suggestions or a suggested fix takes that item's parameters and location and keeps the item listed, so its fix reaches the caller.
• A model no enabled backend serves is model.unavailable (Breaking): a method naming a model a catalog of the deployment knows but no backend it enables serves, such as claude-4.5-haiku with anthropic switched off, answers a 501 model.unavailable with the reason not_served, located on the pipe and its model field, when it is validated and when it runs, where it was the method's model.unknown verdict; a switched-off backend's model file that is missing, is not UTF-8 text or does not parse declares nothing and never stops the boot.

Fixed

• A model deck's own unresolved default or override is the deployment's fault: a deck default or override naming a model the deck does not define raises ModelDeckChoiceUnresolvedError, naming the deck setting and carrying model.unavailable, with the reason not_served, for a bare handle no backend serves, answered 501, and pipelex.config.invalid for a preset, an alias or a waterfall the deck does not define, answered 500, with the deck setting in the operator's diagnostics alone, where it read as the caller's unknown model, and a PipeJudge naming no model, whose default is resolved as its method loads, raises it rather than an unknown_model verdict item; a bad override is refused when the deck is built, and a handle the deck serves only as another type of model is model.capability_unsupported.
• A host library that refuses to load is the deployment's fault: a method of a server's own library directories that refuses to load beside a caller's bundles raises HostLibraryLoadRefusalError, carrying pipelex.config.invalid, which an API answers with a 500 whose message reaches the operator's diagnostics alone, where it answered the caller a 422 verdict carrying the host library's text; the same refusal in the caller's own content, or in library directories the caller owns, stays the caller's 422 verdict.
• A template error found only at render is a located refusal: a template naming a filter or a test that does not exist, which Jinja2 only finds when the branch renders, fails the run at the pipe with Jinja2TemplateInvalidError, naming the unknown filter or test and none of the template, coded method.template_invalid, a 422, when the template is the method's, in a PipeCondition expression, a PipeLLM prompt or system prompt and a PipeDocGen template, and runtime.unexpected when it is one of Pipelex's own, such as the deployment's structure prompt rendered in a PipeLLM step, where it failed as an unclassified 500. A filter refusing its argument, which may be a value of the run's data, is pipe.template_render_failed rather than the template's fault.
• A failure's message is bounded: the error's message a problem carries in diagnostics.message, a provider's answer and every text parameter are cut at 2,000 characters, ending in […], so an oversized exception cannot swell a response, a stored run or a log line.
• A dry run failing on a fault of the runtime's is no verdict: validating a method whose dry run fails only on faults that are not the method's, such as a storage outage or an unexpected error, answers the first of those faults' codes, every failure listed in errors, where it answered method.invalid and blamed the method; a verdict needs one failure in the method's domain, and the first fault is chosen with a no retry verdict before a retryable one, then the operator's before the account's, the input's and the runtime's, the answer's sentence rendered from the failure whose code it takes. A mock value a routed pipe cannot build, a pydantic or polyfactory refusal, stays the method's method.mock_unsatisfiable. A refusal met while loading that is not the method's keeps its own class and code in the same way, so pipelex run bundle and pipelex-agent run bundle on a folder whose bundles declare no single main_pipe print the run's refusal, request.pipe_unspecified or request.pipe_ambiguous, where they printed an invalid verdict. A hosted run whose inputs name a local file tells POST /v1/pipe-io's verdict on a method calling a package by its address that the request did not ship apart from a fault of the method by the verdict's method.dependency_missing item of the kind package, naming the package its params.name gives, where it matched the words of the item's message.
• A provider's 408 is retried: a provider answering HTTP 408, that it gave up waiting, is a transient failure carrying provider.timeout, so the call is repeated within the run, a billed image call included, where it was read as the caller's input and the run failed on its first attempt.
• A PipeFunc returning a list of anything but stuff contents fails its output: a function returning a list that holds a value other than a stuff content, such as a dict or a number, fails the step with FuncOutputTypeError (pipe.output_invalid), where a dict became an empty content and any other value failed as though the function had raised.
• A CLI command's unexpected failure logs no run data: the root of pipelex run and of pipelex graph render logs an unexpected failure with the code of its problem, its class, the classes along its cause chain and the frames it went through, each by its module, line and function with no source line or local (error.frames), where it attached the exception, whose traceback printed the text of every chained exception, a foreign ValidationError quoting the values it refused or a method function's exception included; the traceback rides the record only under --traceback, and the terminal prints the failure's message capped.
• A prompt over the model's context window reads model.context_exceeded: a provider 400, or another 4xx such as the 422 or 413 a gateway may answer, saying the inputs are over what the model can read, by OpenAI's context_length_exceeded code or by the wording OpenAI, Anthropic, Mistral, Bedrock and Gemini give it, in the error's message or its body, is the caller's model.context_exceeded, answered 422, where it read runtime.unexpected, or input.too_large on a 413. A language model's window holds the prompt and the output requested with max_tokens together, and a 400 the max_tokens sent caused reads the same, so its next step is to shorten the input or lower max_tokens, or choose a model with a larger context window; an image, extraction, search or judgment model's next step names what it reads instead. A 400 about a malformed request still reads runtime.unexpected.
• A structured output cut at max_tokens reads model.output_truncated: the Anthropic, OpenAI Chat Completions and Mistral workers turn instructor's IncompleteOutputException, raised for a structured answer cut at its output limit, into LLMCompletionTruncatedError, naming a structured output, the stop value, the output tokens and the max_tokens sent, where it escaped unclassified as runtime.unexpected. LLMCompletionTruncatedError takes an output_kind, a text or a structured output. When the Anthropic structured-output timeout lowered the limit that cut it, the error says so and advises a lower reasoning effort or a smaller output, never a higher max_tokens.
• A Gemini image a safety filter blocked reads model.content_refused: the Google image worker reads the answer's finish reason, or the prompt's block reason when no candidate came back, and raises ImgGenGenerationError with model.content_refused, answered 422 with a next step to revise the prompt or its images, where an IMAGE_SAFETY or PROHIBITED_CONTENT answer read as an empty one, provider.response_invalid. The message names the reason Gemini gave and what it says, so an image stopped for recitation or for an unsupported language reads the same code without being called a safety block. An answer the model's output token limit stopped before it held an image (MAX_TOKENS) raises the new ImgGenOutputTruncatedError, model.output_truncated, answered 422 with a next step to simplify the prompt or choose another image model, where it read provider.response_invalid.
• No error message carries a run's data: an error's message, which reaches the operator's diagnostics, the error tracker and the log lines, no longer quotes an input's value, a stuff's content, a model's answer or a value a pipe built: a refused input is described by its kind and size, a list item by its index and type, a URL by its scheme when it is one Pipelex reads, a date or a time by the form it expected, a pydantic refusal of a run's data, a provider's metadata included, by its locations and reasons, a stuff by its code and concept, and a file of unknown type by the number of bytes read. A PipeFunc whose function raised names the class of what it raised and never its text, as does any other failure of its executor, by its class and its code; a template that fails to render is described by the class Jinja2 raised and the template's line, never by Jinja2's text, which quotes a key of the data the template reached for, nor by its source, a name it reached for, the sandbox's refusals and the render budget's refusal of a call included, being named only when the parsed template spells it, a syntax error by its kind and line rather than the token Jinja2 quotes, and Pipelex's filters never quoting the argument they refuse; a structured generation instructor gave up on is described by the refused answer's reasons, located by the class it asked for, by the class of any other failure to parse the answer, a model's refusal included, or by the class of what ended its loop; an exception that is not a Pipelex error stands in a problem's diagnostics as its class alone, a run's and the API server's catch-all's alike; and no message names a refused or unreachable host, which input.url_unreachable takes as its host parameter, alongside the input the URL came from, which an extract worker, a prompt's image or document and a document's page views name, while a provider's file that could not be fetched is given no parameter its code does not declare. A failure following a pipe's own, a delivery's or the graph tracer's, is logged by its class and code, a webhook's transport failure is named by its class, a trace event log's refusal and the tracing assembly's errors are written by their reasons, and no sink writes instructor's log records, which quote the model's answers. A location never quotes a key of the value's own: a key of a dict, or one the model does not declare, is written <key> (entries.<key>.score), only what the validated type's schema names is written as it is, and a refusal whose model is not known is written by its reasons alone; every site that validates an input into its concept's class, an explicit envelope and a transported stuff included, locates its refusal by that class, an explicit envelope's naming the input and the field as input.invalid's parameters, and a refusal of a method author's own document is located as pydantic gives it (is_authored_input). A CSV input's refusal names the file by the input it was given as, never by its path, and quotes no cell nor a column the concept does not declare; its problem takes the input as its input parameter.
• Pre-release documentation is published: a push to a pre-release/ branch deploys its documentation under the pre-release alias of docs.pipelex.com, where the deploy workflow called a make target with no recipe and published nothing.

Removed

• The per-class error pages (Breaking): the generated page every PipelexError class had under docs/errors/, pipelex-dev generate-error-pages (make gep) and pipelex.errors.error_pages_generator are gone; a problem's type is now its code's page, and docs.pipelex.com redirects each retired page to the page of its class's code, or to the Error Codes index when the class is gone or raises no single code.
• Class-level error classification (Breaking): an error class no longer declares error_domain or retryable, PipelexError.title() and PipelexError.type_uri() are gone, and so is InferenceErrorCategory.error_domain: the class declares its error_code, which decides all four, and an inference failure's category, which stays inside the runtime, picks the code its worker raises. as_caller_fault() is gone too, since a caller reads the sentences a code renders and never an error's own message.

Security

• Callback URLs are held to the runtime's SSRF rule: the runner refuses a /v1/start callback URL with the rule the webhook delivery applies when it fires, pipelex.tools.network.host_rules, so a cloud metadata name spelled in capitals or with a trailing dot, and an address that is not publicly routable such as a carrier-grade NAT one, are refused with a 422 security.input_url_refused before the run, where the runner's own copy of the rule let them through to the delivery; a host of dots alone, such as http://./hook, names no host, and a host and port written with no scheme, such as localhost:3000/cb, opens no authority, so each is a 422 request.invalid naming callback_urls, with no security event, while a scheme-relative URL whose host the rule refuses, such as //169.254.169.254/latest/meta-data, is the rule's refusal, classed by its host.
• The API server's error line quotes no exception (Breaking): every error line carries error.code and names the classes of the failure's exception chain in error.chain, and an error-level line adds error.frames, where the deepest exception was raised, in place of the traceback under exception, so no exception's text, which a foreign exception can fill with a run's inputs or a model's answer, reaches the log, and an exception the catch-all answered no longer reaches the server, whose log would print its traceback; the detail field is gone too. The error's message rides the operator view's diagnostics alone, which only a request the operator authenticated reads (AUTH_MODE=api_key, or a trusted proxy's forwarded identity), so every line names the problem's operator-only parameters as error.params.<name>, such as the component of a runtime.misconfigured, whichever view the response took. A refusal the runner answers in place of a framework exception, FastAPI's RequestValidationError, Starlette's ClientDisconnect or an HTTPException, names that exception's class after its own in error.chain, and a failure no handler recorded that ended a request after its response had started, the catch-all's own failure while a response streamed, is written as A request failed after its response had started, naming its path, the status already sent and its classes alone, where it was dropped unrecorded; so is a failure to send the answer the server built for a failure no handler answered, such as to a client already gone. A line's level says who has to act, from its status and its code's domain: a 4xx is a warning, a 5xx an error with frames only when its domain is the runtime's or the operator's, a 501, what the deployment does not offer, such as custom Python without a sandbox or /v1/start on a blocking-only orchestrator, a warning without frames, where every 5xx was an error, and a 404 or 405 for a request no route serves a debug line, where it was a warning.

[v0.89.0] - 2026-10-17

Added

• resolve_crate_from_method_dir: pipelex.pipeline.resolve_bundle resolves a method's tree a host wrote out to a directory into the normalized crate, loading it as the caller's library directory the way validate_bundle loads a method_dir, with methods_dirs holding the packages shipped with it, under the same ValidateBundleError verdict and loaded-on-success contract as resolve_crate_from_contents. The resolution is static: a package the method calls by its address is loaded from methods_dirs alone, never from the methods installed on the host or by a fetch, and one they do not hold is an unresolved_package_dependency item of the verdict.
• address_dependency_sources: LibraryManager.load_libraries and load_from_blueprints take an AddressDependencySources (pipelex.methods.address_dependencies), ANYWHERE by default, which looks for a package called by its address among the load's methods_dirs, then the installed methods, then fetches it when fetch-on-miss is on, or SHIPPED, which looks only in methods_dirs and reports a package they do not hold as an unresolved_package_dependency item raised from the new MethodDependencyNotShippedError.

Changed

• Every command taking a method's folder reads it as its method tree (Breaking): validate bundle and fix bundle on both CLIs judge every bundle of the folder's tree, as the MTHDS protocol's validation does, instead of a bundle.mthds or the folder's only .mthds file, so a folder whose bundles declare several main_pipes, or none, is validated and fixed like any other, one holding no bundle exits with code 2 under EmptyMethodTreeError, one whose tree cannot be read is their invalid verdict naming the folder (FixBundleError on pipelex-agent fix bundle), and a fix writes anywhere in the tree from its root, the --diff preview proposing what the real run writes. pipelex-agent inputs bundle, pipelex build inputs bundle and pipelex build output bundle act, with no --pipe, on the pipe run bundle starts at, the METHODS.toml's main_pipe or, with no manifest, the one main_pipe its bundles declare, loaded with the rest of the method's folder, and refuse a folder that decides none with the MethodEntryError run bundle gives. pipelex-agent validate bundle <folder> --graph draws that same pipe, or the one --pipe names, and when the folder decides none it says why in graph_unavailable instead of failing the validation; on every command reading a folder, a configuration that does not validate, read before the boot for the tree's limits, is reported as the failed boot it would be.
• Validating a method's tree judges only its own pipes (Breaking): validate_bundle(method_dir=...), and so POST /v1/validate on a method's files and validate bundle <folder>, dry-runs and reports only the bundles of the method's own tree; a nested package below it with its own METHODS.toml, the packages it depends on and the -L directories still load for its bundles to use, but their pipes are no longer judged with it.
• /v1/resolve, /v1/codegen and /v1/pipe-io take the method tree (Breaking): the three routes take the method as /v1/validate and the run routes do, files being the MTHDS protocol's map of file entries with dependencies, resources and read_scope beside it, or a method_ref whose package's whole tree is loaded with the packages it ships, so a call into another package by its address resolves when that package was shipped, while one nothing shipped is the invalid verdict, never looked up among the runner's installed methods or fetched, and a METHODS.toml at the root of a sent tree names the default pipe of /v1/pipe-io, which reads it only for a request naming no pipe. A files list of {content, source} items is refused with a 422 InvalidMethodFiles, the tree's refusals and the custom-Python 403s are those of /v1/validate, include_files echoes the method's .mthds bundles as a map from tree path to text, and the request models MthdsFilesRequest, MthdsFileItem and MthdsPipeRequest are removed. The routes load the method in a worker thread, so a slow load never holds up the server's other requests.
• A bundle validator receives the read scope, plugin API version 8 (Breaking): BundleValidatorProtocol.validate_bundles takes read_scope, the scope the host named for the validation, None when it named none, so a validator dispatching the validation to another process hands the method's trees to its worker through that scope's blob store and the worker reads them by digest under it, as a run's worker reads under the run's read scope. The API server's POST /v1/validate hands its validator the request's read_scope on every arm, never the caller's own id, and PLUGIN_API_VERSION moves to 8, so a plugin declaring targets_api = 7 is refused at discovery with PluginApiVersionMismatchError.
• A PipeFunc package-offer factory receives the method's requirements, under plugin API version 8 (Breaking): a factory registered with PluginRegistrar.add_pipe_func_package_offer is called with a PipeFuncPackageOfferRequest, the pipe_func config and the requirements of the one method tree being judged, where it received the config alone, so a sandbox mode building an environment for each method states the environment it builds for them, or answers a PipeFuncPackageRefusal when none can hold them, which refuses the method with a MethodRequirementsNotMetError carrying the plugin's reason. Each tree judged in one check gets the offer stated for its own requirements, and the factory stays synchronous, so a plugin whose answer takes time caches it by the requirements. The requirements arrive with their markers unevaluated, and the new requirements_needed_in (pipelex.libraries.method_requirements) picks out those whose markers hold where the mode would run the method, the only ones a refusal may rest on; parse_requirements_text, RequirementLine and REQUIREMENTS_FILE_NAME move to pipelex.core.method_trees.requirements_file.

Fixed

• A main_pipe that is not a pipe code is an invalid bundle: a bundle declaring its main_pipe as another type, such as a list, is refused with a validation error located on main_pipe instead of crashing the parse with a TypeError, and a folder's entry rule refuses a main_pipe that is no pipe code, such as domain.pipe, a camelCase name or an empty string, with the same located error instead of reading an empty one as declaring none.
• Load errors name a written tree's bundles by their tree paths: an error raised once the bundles of a tree the server wrote out have parsed, such as a concept declared in two bundles, names them by their tree paths instead of the directory they were written to, so a verdict of /v1/validate, a run or a crate route no longer discloses a path on the server.

Security

• An auto-detected inputs file must be a regular file (Breaking): pipelex run bundle <folder> and pipelex-agent run bundle <folder> read the folder's inputs.json or inputs.toml only when it is a regular file, opened without following a link and judged on the descriptor its bytes are read from, and refuse a symbolic link, a directory or any other entry of either name with the new AutoDetectedInputsFileError, an input error pointing to --inputs; they used to follow a link the method's tree keeps out, such as one its .gitignore ignores, so a method you checked out could point its inputs at data outside its folder. An inputs file named with --inputs is read as given, a link followed.
• A jwt caller's read_scope is bound to its own id (Breaking): on a deployment with AUTH_MODE=jwt, every route taking a read_scope (the run routes, /v1/validate, /v1/resolve, /v1/codegen, /v1/pipe-io and POST /v1/blobs/missing) refuses a scope that does not lie under the caller's token user_id with a 403 ReadScopeForbidden, so a caller holding its own token can no longer read another caller's blobs or run under another's scope. With AUTH_MODE=none or api_key, the caller is a trusted host or a single tenant, and the scope is taken as before.

[v0.88.0] - 2026-10-16

Added

• crate_fingerprint on the run answers: the API server's POST /v1/start acknowledgement and POST /v1/execute result, PipelexRunResultStart and PipelexRunResultExecute, carry the fingerprint of the library crate the run's method was loaded into, so a host records it on its run beside the digest of the method tree that ran; it is null for a run built from no crate.
• StorageProviderAbstract.store_if_absent: a storage provider creates an object only when its key holds none and answers whether it did, never replacing an object already there, and checks the bytes against checksum_sha256_hex before writing, raising the new StorageChecksumMismatchError on a mismatch. S3 makes the condition with If-None-Match: *, sends the SHA-256 as x-amz-checksum-sha256 for S3 to check, and retries a 409 ConditionalRequestConflict a bounded number of times, GCS uploads on generation 0, and the local provider hard-links a temporary file to the key; a provider that does not override _store_if_absent, such as an external storage plugin, looks the key up and then stores.

Changed

• The API server's blob store writes create-only (Breaking): every blob and tree listing the server writes is created only when its key is free, with its SHA-256 as its checksum, so a bucket refusing unconditional writes under blobs/ and trees/ refuses none of them. A blob held at another size than the bytes uploaded under its hash is no longer written over: the upload is a 500 BlobStoreCorrupted that leaves the object for the deployment's operator to remove, and the local storage's folder must sit on a filesystem that supports hard links.

Fixed

• POST /v1/validate without a read_scope stores nothing: a validation of a files map records its tree in the blob store only under the read_scope its request carries, where it used to record the tree's blobs and listing under the caller's own id, a prefix no host lists or erases; hash entries still resolve in the caller's own scope.

[v0.87.0] - 2026-10-16

Highlights

A method is now its whole folder, its method tree, and every file of it travels with it. Pipelex lists each method as the MTHDS standard's method tree, so its templates, images, stylesheets, fonts, Python and requirements.txt reach its steps wherever it runs: locally, on the API server through the files map and the blob routes, or fetched by method_ref, and every run records the digest of the tree it read. A PipeFunc now names its function by import path, a method's requirements.txt is checked before any of its Python runs, and a relative URL in an HTML template names a file of the method.

Added

• [interpreter.method_tree_limits]: the limits every method tree is listed under on this machine, max_files (10,000) and max_total_bytes (1 GiB) by default with max_file_bytes unset, so a folder handed over by mistake is refused before any file is hashed, with the advice to run the method's own folder or to raise the limits; these are not the hosted API's limits, which a deployment sets.
• A run records its method tree: pipelex run bundle prints the digest of the method tree it read with its recap and writes method_tree.json (the digest, the tree's root, its entry and each file's path, hash and size) in its output folder, pipelex-agent run bundle adds method_tree_digest to its output file and to its --with-memory output, and every run's RunMetadata carries method_tree_digest, the digest of the tree its pipe belongs to, which changes with any byte of the method, beside crate_fingerprint, which changes only with the meaning of its concepts and pipes.
• MethodTreeLoadError, MethodEntryError and HostLibraryTreeError: the error_type of a method tree that cannot be listed (a symbolic link, a tree past its limits), of a method folder with no single pipe to start at, and of a server's own library directory whose tree cannot be listed beside the bundles a caller submitted, a configuration fault whose message, naming the server's paths, never reaches the caller.
• PluginRegistrar.add_pipe_func_package_offer: the plugin providing an out-of-process PipeFunc execution mode states, keyed by the same mode, the Python packages and the marker environment its sandbox offers (PipeFuncPackageOffer), which a method's requirements.txt is checked against; a mode stating none refuses every method declaring requirements with PipeFuncPackageSetUnstatedError, a configuration fault. MethodRequirementsFileError, MethodRequirementsNotMetError, HostLibraryRequirementsError, PipeFuncPackageSetUnstatedError and DuplicatePipeFuncPackageOfferError are new error_types.
• pipelex fix function-names and pipelex-agent fix function-names: rewrite every flat PipeFunc function_name of a method folder as the function's import path and drop the argument of every @pipe_func(name=...) marker, reading the files as syntax trees without importing them or booting Pipelex, and keeping every comment and alignment; a flat name no module of the method's tree registers, or that two register, is left as it is and reported with the markers registering it, which keep their argument, and so is a marker whose name is not a string literal, the agent command's is_complete being false and both commands exiting 1, with --dry-run to preview.
• pipe_func_function_refused and the method-tree Python errors: a PipeFunc whose function cannot be found or proven is refused at validation with the pipe_func_function_refused validation error type, located on the step's function_name, and the new PipeFuncFunctionError, TreePythonError, TreePythonHeldError, TreeModuleShadowingError and FunctionNamesMigrationError name the failures of a function, of a tree's Python and of the migration.
• The method file store: a step reads a file of its method where reading is allowed, at the moment it uses it, through MethodFileStoreProtocol, whose read_tree_listing(tree_digest=..., read_scope=...) and read_blob(sha256=..., read_scope=...) return a tree's listing and a file's bytes under the run's read scope, each read checked against the tree's digest (pipelex.core.method_trees.method_files). The local store, LOCAL_METHOD_FILES, serves the trees this process's libraries hold, and a plugin whose activities run apart from the process that loaded the method claims HubSlot.METHOD_FILE_STORE with PluginRegistrar.claim_method_file_store; a file the store does not hold for the run fails its step with the new MethodFileUnavailableError. An orchestrator running a job out of process copies every tree the job's crate names into the store its workers read before its execute or start returns, since the runner may drop the files as soon as it does, and read_stored_trees(tree_digests=..., read_scope=...) reads them for that copy, each as a store keeps it, its listing under its digest and its files under their hashes. The local store finds a file by its hash in one lookup and reads a file on disk off the event loop.
• Relative URLs in HTML templates read the method's own files: a relative URL in a PipeDocGen HTML template, inline or a template file, such as an image's src, a stylesheet's href, a font, or a url() inside a stylesheet the template links, names a file of the template's method tree, resolved by the MTHDS standard's rules against the template file, or against the bundle file of an inline template, and read through the method file store under the run's read scope wherever the document prints, so a logo, a stylesheet and a font travel with their method. Only images, stylesheets and fonts are read, by suffix, so a URL a run's input supplies cannot make a document carry the method's other files. A URL the template writes as it is is checked when the method loads, and a URL built from the inputs that climbs above the tree's root, names a folder, a missing file, a file the tree's membership rule keeps out or a file that is no asset fails the print with the new TemplateUrlRefusedError, an input error naming the URL and the template; a URL with a scheme, such as https://, data: or pipelex-storage://, is read as before.
• RenderJob.base_url and the method-file arm of RenderResources.load: an HTML job whose template belongs to a method tree carries the URL a document engine joins the document's relative URLs to, under METHOD_FILE_URL_PREFIX (https://method-files.pipelex.invalid/, which never resolves), and RenderResources.load reads a URL joined under it, a stylesheet's own URLs included, from the document's method tree, with no media type; DocumentComposition.url_base carries the template's place in its tree to the print stage. They join plugin API version 7, and an engine that never reads base_url keeps refusing a relative URL.
• StorageProviderAbstract.load_size: a storage provider reads an object's size without its bytes, from a file's metadata, an S3 HEAD or a GCS object's metadata, and a provider that does not override _load_size measures the object it loads, so an external storage plugin keeps working.
• The API server's blob routes, POST /v1/blobs/missing and PUT /v1/blobs/{sha256}: the server keeps a blob store in its configured storage, under <scope>/blobs/<sha256>, declares it with blob_store: true on GET /v1/version, and serves the MTHDS protocol's blob routes, so a sender asks which of its method's files the runner lacks, uploads each one to the signed target the answer names, and then sends the method by hash; the scope is the request's read_scope, else the caller's id, the targets start with PUBLIC_BASE_URL when it is set, else with the URL the request arrived at, are signed with BLOB_UPLOAD_SIGNING_KEY (a key per process when unset) and expire after BLOB_UPLOAD_URL_TTL_SECONDS, and once the server has read a tree in full it records its listing under <scope>/trees/<digest>, so asking with that digest answers in one lookup for blobs of that tree. A blob counts as held only at the size the sender states, read from the storage's metadata, so bytes held short are asked for again and written over by their upload. BlobMismatch, BlobUploadNotAuthorized and BlobStoreCorrupted are new error_types.
• files takes every entry form, beside dependencies: on /v1/execute, /v1/start and /v1/validate, each value of files is the file's text, {"base64": "…"} or {"sha256": "…", "size": n} naming bytes the blob store holds, so a method's templates and other binary files travel with it, and dependencies carries the method packages it calls by address, each a map of its own keyed by its address; /v1/validate also takes read_scope. A hash the server does not hold is a 422 MissingBlobs listing the hashes in missing_blobs, a hash it holds at another size than the entry states a 422 BlobMismatch listing each with its held size in mismatched_blobs, checked before any byte is read, and a tree over MAX_METHOD_TREE_FILES, MAX_METHOD_TREE_FILE_KIB or MAX_METHOD_TREE_TOTAL_KIB, the files resources joins to it included, or a method with more than MAX_METHOD_DEPENDENCIES dependency trees or more than MAX_METHOD_REQUEST_TOTAL_KIB across its trees, a 422 MethodTreeTooLarge.
• method_provenance.tree_digest: a run by method_ref reports the digest of the method tree it loaded beside the commit it was read from (MethodProvenance.tree_digest).
• Validating a method directory: validate_bundle, validate_bundles_in_process and BundleValidatorProtocol.validate_bundles take method_dir, a method's tree validated whole as the caller's, with methods_dirs holding the packages shipped with it, every .py file of the tree compiled for its syntax and refused by its tree path and line, and the graph drawn from the tree's entry pipe; write_method_tree and WRITTEN_METHOD_TREES (pipelex.libraries.written_trees) write a tree out and make every listing of its directory, while it is held, the tree as written.

Changed

• Library directories load through their method trees (Breaking): a library directory's .mthds files are the bundles of its method tree and of the trees of the nested packages and repositories under it, each loaded as a method of its own, so a hidden, gitignored or virtual-environment .mthds file is no longer loaded, a symbolic link in the tree refuses the load, and [interpreter.scan] excluded_dirs now applies only to the scan for Python classes and functions; a hosted run sends the same bundles. A directory holding nothing but nested methods loads them, a nested package or repository holding no .mthds file is skipped before it is listed, and a dependency package whose tree cannot be listed is refused naming the package by its address, never the directory it was installed into.
• -L <subdir> inside a package loads the whole package (Breaking): a library directory is listed as its method tree, which is rooted at the nearest METHODS.toml at or above it, so naming a subfolder of a package with -L, or as a library directory of a runner, loads every bundle of the package.
• A .mthds file named alone belongs to its method tree (Breaking): a bundle file handed to run bundle, validate bundle or a runner is the member of the tree rooted at the nearest METHODS.toml at or above its folder, and with none its method is that one file, so a step naming any other file, such as a template_file, is refused with the advice to run the method's folder or to add a METHODS.toml.
• template_file resolves in the bundle's method tree (Breaking): a PipeDocGen template_file read from disk is looked up among the files of its bundle's method tree, where a .. climbing to another folder of the tree is now allowed, and a file the tree does not hold (above its root, gitignored, hidden or in a nested package) is refused, the message naming each file by its path in the tree; a URL is refused when the bundle parses, and a bundle loaded from a string still reads only the files sent with it.
• run bundle <folder> starts at the method's main pipe (Breaking): with no --pipe, pipelex run bundle and pipelex-agent run bundle on a folder, locally as on the hosted API, start at its METHODS.toml's main_pipe, or with no manifest at the one main_pipe its bundles declare, and refuse none or several, naming each bundle by its path in the tree; a bundle.mthds or a single .mthds file in the folder is no longer looked for. A hosted run names that pipe as domain.pipe_code, so it starts where the local run would when two domains of the method define the same code.
• Run output folders hold a .gitignore: every folder pipelex run creates for a run's outputs holds a .gitignore ignoring everything in it, so a run started inside a method's folder leaves the method's tree, and its digest, unchanged; the folder is named after the pipe's own code even when the pipe was named as domain.pipe_code, on a hosted run too.
• pipelex-agent run writes into an output folder (Breaking): its output file (live_run.json or dry_run.json) and its graph files go into a new numbered folder, results/<pipe_code>_output_<NN>/ beside the bundle it ran, else under mthds-wip/, holding the same .gitignore, instead of beside the bundle itself, so two runs of a method read the same tree, with the same method_tree_digest.
• mthds and pipelex-sdk versions, MTHDS protocol 1.0.0 and standard 7.0.0 (Breaking): the pins move to mthds==0.22.0, the release that lists method trees, carries protocol 1.0.0 and implements MTHDS standard 7.0.0, and pipelex-sdk==0.45.0, the release built on it, so the runner and GET /v1/version report protocol_version 1.0.0, a crate pipelex normalizes is stamped mthds_version 7.0.0, and a METHODS.toml declaring mthds_version = "^5.0.0" now warns that the engine does not satisfy it. A dependency package fetched before is fetched again into the release's new cache layout, a package's METHODS.toml is found only at its root and manifest discovery stops at any .git entry; everyone downstream inherits those exact versions.
• A method's requirements.txt is checked when it loads (Breaking): a method tree holding Python and a requirements.txt at its root is refused before any of its Python is imported, naming each requirement, when the environment its PipeFunc steps run in does not meet it, or when the file holds a line the MTHDS standard refuses (a URL, an option such as -r or -e, a comment after a requirement, a continued line). A package a method calls by its address is checked the same way, named by its address. Locally the environment is the interpreter Pipelex runs in and the refusal gives the uv pip install command that fixes it; on a sandbox-hosted deployment it is the package set the deployment states for its sandbox, a run is refused with a 422 and a validation by method_ref with an is_valid: false verdict located on the line, naming no path on the server. A method of a server's own library directories whose requirements are not met is the server's fault, a 500 HostLibraryRequirementsError whose message never reaches the caller. Pipelex never installs anything. A project root loaded as a library directory is such a tree, so hand over the folder holding the methods instead when the root's requirements.txt is an application's.
• A PipeFunc names its function by import path (Breaking): function_name is the function's import path from the root of the step's method tree, such as funcs.totals.compute_totals for the function compute_totals of funcs/totals.py, and a flat name is refused as the bundle is read with the advice to run pipelex fix function-names. Validation locates the module among the tree's files and proves, without running any Python, that the function is a top-level def or async def the module defines carrying the @pipe_func() marker; the module is imported under its real name, the tree's root first on the import path, when the step first runs, where its signature and return type are checked. A bundle passed as content imports locally from the process's import path, and on a sandbox-hosted deployment from the Python submitted with it. The runner's OpenAPI document gives the PipeFunc blueprint's function_name its import path pattern and PipeValidationErrorType its pipe_func_function_refused value.
• One method tree's Python per process (Breaking): a run holds the Python of the tree it imports from until its library is torn down, and a step of another tree that would load its Python meanwhile is refused with TreePythonHeldError naming both trees by a bundle each holds and the start of its digest, never by a path of the host, so a run whose own steps and a dependency package's steps both call Python is refused locally; once no run holds a tree, its root leaves sys.path and the next tree evicts every module imported from a file of it, whatever imported it. A top-level module of a tree named like a standard-library module or like a module importable outside the tree is refused at validation, structures excepted, and on a sandbox-hosted deployment, whose sandbox holds its own packages, only a standard-library name is, and while a tree is held, importing a file its membership rule keeps out, such as a .gitignored module, is refused naming the rule, and no bytecode is written into the tree.
• The function registry is retired and @pipe_func() takes no argument (Breaking): FuncRegistry, func_registry, FuncRegistryUtils, FuncRegistryError, RuntimeHub.get_func_registry and the name= argument of @pipe_func are removed, no function is discovered or imported while a library loads, and is_marked_pipe_func(func=...) tells a function carrying the marker.
• Kernel func ops take the function (Breaking): pipelex.kernel.func_ops.call_registered_function becomes call_function(function=..., memory=...), and run_func takes the function itself in place of function_name.
• Plugin API version 7 (Breaking): PLUGIN_API_VERSION moves to 7, so a plugin declaring targets_api = 6 is refused at discovery with PluginApiVersionMismatchError: a bundle validator's validate_bundles receives submitted_files in place of bundle_resources and takes method_dir and methods_dirs, its mthds_contents becoming optional, a PipeFunc executor's transported request names its tree by tree_digest and carries no files, the transported entrypoint takes the directory the call's files were unpacked into, an orchestrator running a job out of process copies the job's trees before it returns, and claim_method_file_store joins the registrar's menu.
• LibraryCrate names its method trees by digest (Breaking): python_sources, bundle_resources and host_bundle_files give way to tree_bundles, which names each pipe's bundle by its tree's digest and its tree path (TreeBundleRef), so a crate carries no file's bytes, no listing and no path of the host that assembled it, a pipe built from it resolves a file its bundle names lexically and reads nothing, a Temporal workflow loading it included, and its fingerprint ignores the trees. Bundles loaded from content strings sit at the root of the tree of the files submitted with them, which the files of a library directory whose own tree holds no bundle join; two directories submitting different files at one path refuse the load with BundleResourcePathError, naming the path in the tree alone and joining none of their files, and a structure class is refused in every tree the load lists, a package or repository nested in a library directory included. A load that validates a crate builds each pipe as a member of its tree when a library of this process holds the tree under the digest the crate names, so a PipeDocGen HTML template file is checked as it was where the crate was assembled, and refuses such a step with the new PipeDocGenTemplateFileUncheckedError when no library holds its tree, rather than passing its template unchecked; a load skipping validation still reads no file. LibraryCrate.concepts_only() gives the crate's concepts and domains without its pipes.
• A PipeFunc call names its method tree (Breaking): PipeFuncExecutionRequest.tree_digest names the tree of the called step, and the process running the call reads its files, every one but the .mthds files and a generated structures module, through the method file store under the run's read scope (read_pipe_func_call_files). The direct executor's transported run writes them into a temporary directory, generates structures unless the method shipped one, imports the function by its import path under the process's hold on that directory and unloads its modules before removing it; the transported entrypoint takes as a required third argument the directory a sandbox client unpacked the files into, since a sandbox reaches no method file store, and runs DirectPipeFuncExecutor.run_pipe_func_transported_at on it. Only the called step is built in the tree written for the call, which holds none of the tree's bundles: load_from_crate and rehydrate_library_and_memory take written_pipe_trees, keyed by the step's pipe ref, and every other step, a PipeDocGen of the same tree included, is built as the crate names it, its template file named by the crate's digest. The transported library's id is public, TRANSPORTED_LIBRARY_ID.
• A PipeDocGen template file is read where the document prints (Breaking): DocumentComposition.template_file, a ComposedTemplateFile naming the file by its tree's digest and tree path (MethodFileRef), replaces template_path and template_resource, and the print stage reads it through the method file store under the run's read scope, renders an .html one with the step's data, carried as a TemplateRenderContext (the stuffs the step's inputs name, the concepts and domains of the run's crate with none of its pipes, the crate's fingerprint, and the run's runtime parameters), through the template file stage the interpreter installs at boot, a dry print included, in the run's own library where this process holds it and otherwise in a library loaded from the concepts, which the process keeps for later prints (RenderLibraryCache), and hands an office one's bytes to its engine, whose template check moves from the step's dry run into the dry print. An .html template file whose bytes changed after its tree was listed is refused at load, never read from the disk unchecked. make_render_job is synchronous again and takes the rendered html or the template's bytes; an inline template is still rendered where the step runs.
• Files submitted with content strings make one method tree (Breaking): PipelexMTHDSProtocol, validate_bundle, validate_bundles_in_process, acquire_library, pipeline_run_setup, resolve_crate_from_contents and BundleValidatorProtocol.validate_bundles take submitted_files, a mapping from the path a step names to the file's bytes, in place of bundle_resources, and LibraryManagerAbstract.add_submitted_files replaces add_bundle_resources. The run names their tree by its digest and carries none of the files, so nothing is stored under the run's assets/bundle/ before it leaves the process, the 512 KiB bound on .html template files is lifted, and files that cannot make one tree, such as two paths equal once case-folded, raise BundleResourcePathError. A step names a submitted file by any spelling of its path, so templates//invoice.docx reads the file submitted as templates/invoice.docx.
• A relative URL in an HTML template names a file of the method (Breaking): a literal relative URL of an HTML template, or of a stylesheet it links, that names no image, stylesheet or font of the method's tree now fails the method's load, pipelex validate and dry runs included, where it loaded and failed only at print. A relative path such as images/logo.png that an engine printing HTML hands RenderResources.load as written now resolves in the template's method tree, and is refused with TemplateUrlRefusedError when the template belongs to none, where an unscoped run read it from its working directory; a root-absolute local path, and every URL of a document printed from the auto-layout or an office template, read as before.
• A method sent to the API server is a method tree (Breaking): files and bundle_b64 are read as one map under the MTHDS standard's tree rule, so a key holding a dot file or directory (.mthds/ included), an empty, . or .. segment, a backslash or a colon, a key given twice, or two keys naming one file is a 422 InvalidMethodFiles carrying the standard's tree_refusal (code and names) in place of InvalidBundle, and a package the method calls travels in dependencies beside files, while a bundle_b64 archive still carries it under .mthds/methods/<name>/. The whole tree is written out and loaded as the caller's library directory, so a template beside its bundle needs no resources entry and counts against the tree's limits rather than those of resources, an image, stylesheet or font only a template's relative URL names travels with the method, a file sent in resources joins the tree with no step needing to name it, a bundle that does not parse is a 422 naming it by its tree path, and with no pipe_code the run starts at the tree's entry pipe by the protocol's rule.
• method_ref is read from its commit and run as a tree (Breaking): a package fetched by address is read from the git objects of the commit it resolved to, never from the clone's working tree, and runs or validates as a tree sent in files does, its template files and Python included, the packages it ships under .mthds/methods/<name>/ becoming dependency trees that /v1/validate now loads too; its entry pipe is its manifest's main_pipe, so a manifest declaring none answers default_pipe_ref: null.
• /v1/validate validates a method tree whole (Breaking): a method sent as files or fetched by method_ref is validated as it would run, every .py file of it compiled for its syntax, a file that does not parse or is not UTF-8 making the verdict is_valid: false with an item at its tree path and line, and its default_pipe_ref and graph follow the tree's entry pipe, both null for a tree with none; mthds_sources accompanies mthds_contents alone.

Fixed

• The local storage provider publishes a write whole: LocalStorageProvider writes to a temporary file beside the key, flushes it, then renames it onto the key, so a full disk or a killed process never leaves a file cut short under a key, and two writers of one key each land whole.
• A bundle file that is not UTF-8 text is a located diagnostic: a .mthds file read from disk that does not decode is a parser error naming its source and the line and column of its first undecodable byte, so a method tree sent to the API server holding one is the caller's 422 on a run and an invalid verdict on /v1/validate, never a server error.
• Python a method tree holds that cannot parse is its diagnostic on every interpreter: a .py file holding a NUL byte, which Python 3.11 refuses with a ValueError where later versions raise a SyntaxError, or one nested too deeply to parse, is an invalid verdict located at its tree path, and a PipeFunc whose module is such a file is refused as one that does not parse.
• A template_file no sent file could be keyed by is a blueprint item at its step: a bundle loaded from content strings, as the API's routes and validate_bundle load one, whose PipeDocGen step's template_file holds a .. segment or a NUL character, or names no file, is refused when it parses, whatever files the request sends, as one blueprint_validation item with field_path pipe.<code> whose message names the field and not the path, instead of a load refusal saying the file was not supplied. A bundle read from disk still resolves a .. in its method tree.
• A method_ref package's template files reach its steps: a PipeDocGen step of a package run or validated by method_ref reads the template file the package holds beside its bundle, where the run before had no way to read it.
• A request's own method that does not load is the caller's 422: a method sent to the API server whose bundle does not parse, or whose tree cannot load, is refused as the caller's fault, naming each file by its tree path, instead of a 500 naming the server's temporary directory.
• A TOML syntax error names the bundle's source: a bundle read from a file under a source the caller gives names that source in its TOML syntax error, never the file's path on the host.

Removed

• Bundle resources and their dispatch (Breaking): BundleResource, BundleResources, make_bundle_resources, BundleResourceReadStage, MAX_LOAD_STAGE_RESOURCES_BYTES, prepare_job_for_remote_dispatch, relocate_run_resources and does_pipe_run_leave_process are removed, InterpreterHub.set_pipe_run takes the pipe run alone, and BundleResourceError and BundleResourcesTooLargeError are no longer error_types: no template file rides in a run's payloads, so none is bounded by them, and a method file a run cannot read raises MethodFileUnavailableError.

[v0.86.1] - 2026-10-16

Changed

• A scoped event log captures usage events: a usage event emitted while runtime_hub.scoped_event_log is set now goes into the scoped event log and nowhere else, ahead of an event log registered with ReportingManager.set_event_log and of the per-process runner fallback, including inside an isolated sub-execution such as a Temporal activity, where it always went to the fallback. Code running a leaf inside an activity can therefore scope a fresh InMemoryEventLog around it and return the leaf's usage events with its result, which is how a backend with no shared tracing store, such as Mistral Workflows, collects a run's usage; with no scoped event log set, usage events are routed as before.

[v0.86.0] - 2026-10-13

Highlights

A run's trace now records each decision as it is made and names every pipe by its place in the method. A condition's chosen outcome and a batch's width are written before anything runs under them, and every trace event carries its invocation path, its mode and the attempt of the execution that wrote it, so a graph built from a run's events names each pipe the same way in every run, live or dry, and shows a retried step once.

Added

• condition_resolved and batch_fanned_out trace events: a live PipeCondition writes condition_resolved the moment its choice is final, before anything runs under it, with the rendered_value its expression rendered and the selected_outcome key of the outcome map it matched, null when it took the default outcome, and a chosen pipe whose inputs are missing fails the condition with no outcome recorded; both graph builders derive from that event and the start of the chosen pipe the selected_outcome edge from the condition, labelled with that key, which no run drew before, whichever workflow the chosen pipe started in. A PipeBatch writes batch_fanned_out once it knows its width, before any item starts, with item_count, branch_pipe_code, the bare code of the pipe each item runs, branch_pipe_ref, its qualified reference, and branch_pipe_type. A dry run resolves no condition, so it writes no condition_resolved, and both graph builders build the same graph from a run's events.
• step_count and branch_count on pipe_start: a PipeSequence's start event states the number of steps its author wrote, the binding of a dotted batch_over not among them, and a PipeParallel's the number of its branches; both are null on every other pipe.

Changed

• Every trace event states its mode (Breaking): each trace event carries mode, live or dry, the mode the run's pipes run in, which the run's TraceContext carries as the new run_mode, so a usage event an activity writes states it too, and a live run a keyless boot (needs_inference=False) forces dry states dry on its trace context, its events and its graph, and, like every dry run, opens no OpenTelemetry trace; an event stored without mode by an earlier version is refused with EventLogSchemaMismatchError rather than read as live, and a consumer that builds trace events passes it. Callers follow new signatures: TraceContext.run_mode is required, with no default, and so is run_mode on GraphTracerManager.open_tracer and on the tracers' setup (GraphTracerProtocol, GraphTracer and GraphTracerNoOp), where it replaces mode: GraphSpecMode, so a workflow opening a tracer of its own for part of a run passes the run_mode of the context it received, and PipelexKernel.make refuses, with TraceContextRunModeError, a trace_context stating another mode than the one its run takes, which the new runtime_hub.resolve_effective_run_mode gives, dry on a keyless boot. GraphSpecAssembler.assemble no longer takes mode and raises the new TraceEventModeError on a set of events that mixes modes or holds none, and assemble_tracing and assemble_tracing_on_output no longer take run_mode: the graph states the mode its events state, so a dry run assembled from its events in a durable workflow gets a dry graph where it got a live one, and assemble_tracing reports a TraceEventModeError as the run's graph_assembly_error.
• Controllers register their execution data as they decide (Breaking): a PipeSequence registers step_count as it starts, now the number of steps its author wrote; a PipeParallel registers its branch_count, add_each_output and combined_output_concept before its branches run, a PipeBatch its item_count and branch_pipe_code before its items run, and a live PipeCondition its evaluated_expression and selected_outcome once its choice is final, before the chosen pipe runs, where each used to register them once it had finished. GraphTracerProtocol adds register_batch_fan_out and register_condition_resolution, and add_selected_outcome_edge takes selected_outcome: str | None in place of outcome_value.
• Trace events and graph nodes name their invocation (Breaking): every trace event carries path, the invocation path the hosted progress contract defines, which names a run of a pipe the same way in every run of the method, live or dry, on every engine: the entry pipe's pipe_ref, then one segment per controller level, step_<n> as the author numbered the steps, binding steps included, branch_<n>, item_<n> counting the items from 1, and outcome_<key> or default for a condition's outcome group, the outcomes that run one pipe as the library resolves it, however they spell it, named by the first key that runs it, percent-encoded, so filings.review_filings/step_3/item_2/step_1, and a dry run runs each group's pipe once; a binding step's events carry null. Every NodeSpec carries the same path, pipe_start carries pipe_ref, pipe_end_success, pipe_end_error and pipe_end_skipped carry pipe_code, pipe_ref and pipe_type, and a failed node's ErrorSpec carries caller_facing, true when its message was written for the caller, or the error's text with caller_facing false when the error's report cannot be built, a fault the tracer logs while the run still fails with the pipe's own error. A controller hands each pipe its place through JobMetadata.for_child_at; since tracing never fails a run, a pipe started without one is traced with a null path and the tracer logs the fault, the new InvocationPathError, as an error, while an inactive tracer and the no-op tracer derive no path; GraphTracerManager.on_pipe_start and the tracers' on_pipe_start require pipe_ref, on_pipe_end_error takes caller_facing, and TraceContext.copy_for_child requires invocation_path. An event stored without these fields by an earlier version is refused with EventLogSchemaMismatchError, and a consumer that builds trace events passes them.
• Trace events name the attempt of the execution that wrote them (Breaking): every trace event carries attempt, the attempt of its execution counting from 1, and lineage, the {execution, attempt} entries it was dispatched under, empty for the run's own execution, beside workflow_id, which names the execution, direct in direct mode. GraphTracerManager.open_tracer takes attempt and received_context, the trace context a dispatched workflow received, which it continues: its parent node, its path and, when it names the workflow's place as a batch item's does, its chain as the workflow's lineage; workflow_id must be the id the engine keeps across attempts, and TraceContext carries the new parent_path, child_segment and chain, the last required with no default, so a host building a context of its own states it, make_direct_chain() in a single process. Node and edge ids name the chain that minted them, <graph_id>:<workflow_id>:attempt_<n>:node_<k>, followed after the attempt by a digest of the lineage for a dispatched workflow, so two attempts of one workflow never mint the same id; direct mode keeps <graph_id>:node_<k>. ReportingManager.set_event_log no longer takes workflow_id: a usage event takes its execution, attempt and lineage from the chain of its trace context, on the registered path as on the runner fallback. A trace event is frozen, and one whose workflow_id is empty is refused with EventLogSchemaMismatchError. The event logs keep every attempt's events, and every one of them, the DynamoDB and buffering logs included, returns a run's events deduplicated on the event's chain, writer, kind and sequence and ordered by chain, sequence and writer; the DynamoDB log's sort key becomes EVENT#<chain digest>#<writer_id>#<sequence>, the chain digest being the SHA-256 of the chain key, so the key stays within DynamoDB's limit however deep the lineage, and the NDJSON log writes one file per attempt of each execution, wf_<workflow_id>__c_<chain digest>.ndjson, __w_<writer_id> added for a writer other than primary. GraphSpecAssembler builds the graph, and dates it, from current events only: a higher attempt of an execution supersedes the earlier one and everything it dispatched, so a retried invocation appears once at its path, a lost attempt leaves no failed node, and a superseded attempt's usage counts in the run's total as unattributed usage.

Fixed

• Trace events written to DynamoDB expire (Breaking): the DynamoDB event log now writes every event with a ttl in epoch seconds, its write time plus the new runtime.tracing.dynamodb.retention_days (30 by default, at least 1), so a table that expires items on ttl deletes a run's events, full output data included, where it used to keep them forever. Only events written from this version on carry a ttl, so the rows an earlier version wrote stay until they are deleted or given a ttl by hand. DynamoDBEventLog takes retention_days and now takes all its arguments by keyword; make_event_log reads the setting from the configuration.

[v0.85.1] - 2026-10-12

Fixed

• A PipeDocGen document's name is one the hosted API serves: a rendered filename holding a letter outside ASCII or a dot, such as Zoë Ångström — Q3.2026, was stored under a pipelex-storage:// URI the hosted API refuses to serve, so the completed document could never be downloaded. The name is now spelled in ASCII where it can be, accents dropped and letters such as ø, æ, ł, ß, đ, þ, œ and ı transliterated, every other character, an inner dot included, becomes a hyphen, repeated separators collapse, and a name that leaves nothing, one written wholly in Greek, Cyrillic, Han or Arabic for one, falls back to the pipe's code, so that name is Zoe-Angstrom-Q3-2026.pdf, on a local run as on a hosted one.
• The files a run stores from what it was sent are named and typed for their readers: the copy of a .docx, .xlsx or .pptx template file a run stores under assets/bundle/ before it is dispatched now carries its Office Open XML content type, named in code, where a host whose mimetypes table did not know the extension stored it as binary/octet-stream, and its name follows the rule a document's name follows, so Modèle trimestriel.v2.docx is stored as Modele-trimestriel-v2.docx. A local file input stored under assets/ that its bytes and type do not identify keeps its own suffix only when it is plainly letters and digits, and is stored as .bin otherwise.
• The refusals of the files sent with a bundle say a retry cannot succeed: BundleResourceNotNamedError, BundleResourcesTooLargeError and BundleResourcePathError now carry retryable: false in their error report, and so in the API server's problem document, as InvalidResourcePath already did. A PipelexError subclass declares it with the new class attribute retryable, which its report carries and the generated error reference shows; a wrapper raised from such an error inherits it, as it does error_domain.

[v0.85.0] - 2026-10-12

Highlights

A method that prints with a template file now runs wherever it is sent. A PipeDocGen step's .xlsx, .docx, .pptx or .html template file travels with its bundle, as resources on the API server's routes, inside a bundle_b64 or files bundle, or as bundle_resources in Python, so a caller with no local pipelex can validate, dry-run and run it, and a bundle loaded from content strings never reads the runtime's own disk.

Added

• resources on the API server's routes: POST /v1/validate, /v1/execute, /v1/start, /v1/pipe-io, /v1/resolve and /v1/codegen take the files a bundle sent as content reads, such as a PipeDocGen step's template_file, as a map from the path the step names to the file's bytes in standard base64, so a caller with no local pipelex can validate, dry-run and run a method that prints with an .xlsx, .docx, .pptx or .html template file. A key that cannot name a file inside the bundle answers 422 InvalidResourcePath, a file no step names 422 BundleResourceNotNamedError, a value that is not base64 400 InvalidBase64, and a request over MAX_RESOURCES_PER_REQUEST, MAX_RESOURCE_FILE_KIB or MAX_RESOURCES_TOTAL_KIB (32 files, 5 MiB each and 10 MiB in all by default) 413 PayloadTooLarge; resources beside a method_ref is a 422. A method bundle sent as bundle_b64 or files may ship such a file instead, beside the .mthds file whose step names it, and it reaches the step the same way, under the same limits; two different files under one path, shipped twice or shipped and sent, answer 422 InvalidResourcePath, as two spellings of one key do before any value is decoded. On an orchestrator other than direct, such as Temporal, a run stores each office template file under its storage_scope at assets/bundle/ before it is dispatched, so the job carries a pipelex-storage:// reference rather than the bytes, while the .html template files, which travel inline with the method, may total 512 KiB at most, a fixed bound refused with 413 BundleResourcesTooLargeError once the bundle is parsed.
• Template files sent with a bundle loaded from content strings: PipelexMTHDSProtocol, validate_bundle, validate_bundles_in_process, acquire_library, pipeline_run_setup and resolve_crate_from_contents take bundle_resources, built with make_bundle_resources from the bytes of each file keyed by the path its step names. The library holds them and its LibraryCrate carries them, outside its fingerprint, so a PipeDocGen step finds its template file wherever the bundle is loaded: an .html one is checked against the inputs at load, the engine's template check runs on an office one at validation and in the dry run, and the print stage reads it, from the run's storage when the crate carries a reference. Before a run, live or dry, leaves the process, prepare_job_for_remote_dispatch stores its office template files under the run's storage scope; PipelexMTHDSProtocol.execute calls it when the hub's pipe run is a boot orchestrator's, and a dry run's template check reads a stored file under the run's read scope, as the print stage does. A step of a bundle the runtime read from its own disk, such as the host's library, still reads only beside it, so a file sent under the same path never stands in for its template. A file no step names raises BundleResourceNotNamedError, a path outside the bundle BundleResourcePathError, and .html template files totalling more than MAX_LOAD_STAGE_RESOURCES_BYTES (512 KiB), which travel inline with the method wherever it runs, BundleResourcesTooLargeError.
• Template-check warnings in the validation verdict: a warning the engine's template check finds in a PipeDocGen step's office template file, such as an Excel defined name or a PowerPoint shape name that matches no input field, now rides the verdict's advisory warnings on pipelex validate, pipelex-agent validate and the API server's POST /v1/validate, where it was only logged. It is a dry_run item with the new error_type template_check_warning, the step's pipe_code and domain_code, and two new optional locators of ValidationErrorItem, template_file and template_location, the latter unset when the engine names no place, which the server's OpenAPI schema publishes, a step of the server's own library directories naming no file of theirs; an error finding still fails the validation, validate pipe <code> on both CLIs carries these warnings alone, and a dry run that returns no verdict, such as pipelex run --dry-run, pipelex fix bundle or pipelex build inputs, still logs them.

Changed

• BundleValidatorProtocol.validate_bundles takes bundle_resources (Breaking): a bundle validator registered for an orchestration mode receives the files sent with the contents, or None, and hands them to the validation it runs, so a remote validator implements the parameter and carries the files to its worker.
• InterpreterHub.set_pipe_run takes leaves_process (Breaking): whoever sets the hub's pipe run says whether it hands each job to an orchestrator outside the process, as a boot orchestrator's does, which does_pipe_run_leave_process reads back so a run's submitted files are stored before it leaves.
• DocumentComposition.make_render_job is asynchronous (Breaking): it takes the run's storage_provider, since a composition's template file may be a BundleResource read back from storage, and a TEMPLATE_FILE composition carries either template_path or template_resource. A stored template file's URI is among the composition's referenced_uris(), so the run's read scope authorizes it before the print stage reads it.
• A PipeDocGen step's template_file must be a path inside its bundle (Breaking): an empty or absolute path, a Windows root, a drive, a UNC share, a .. segment, a backslash or a colon is refused when the blueprint validates, by the rule the files sent with a bundle are keyed by, so every template file a step names can be sent with its bundle; an absolute path naming a file inside the bundle's directory, a path such as templates/../invoice.docx and a file name holding a colon used to load. The refusal does not repeat the path, so a host library's step can no longer put the host's own path into a caller's verdict through its template file. Beside a server's own library directories, the verdict also withholds the template files their steps name, as their bundle files already were, both when such a step is refused while they load and when the engine's template check refuses its template in the dry run of a caller's pipe that runs it; a template file the caller's own content names is kept.
• A string-loaded PipeDocGen step without its template file says it was not supplied: the load refusal now names the path the file is expected under and says to send it with the bundle, where it used to say the bundle was not loaded from a file on disk.
• build_advisory_warnings and collect_advisory_warnings take the sweep's dry_run_result (Breaking): the composition point of the advisory warnings reads what the dry runs found from the per-pipe status map, so a caller passes the map its validation sweep returned. DryRunOutput carries those findings in its new warnings when the sweep is asked to collect them with the new collect_dry_run_warnings of validate_bundle, BundleValidator.validate_pipes and BundleValidator.validate_current_library; a sweep that is not asked leaves them to the log, as before.

Fixed

• Contents named by bundle_uris read their template files beside their file: a bundle passed as mthds_contents with the path of the file it was read from in bundle_uris, to PipelexMTHDSProtocol, acquire_library or pipeline_run_setup, and not already loaded from the library directories, now loads as read from that file, so a PipeDocGen step's template_file is found beside it, where it was refused as if the bundle had no directory, and an address-based reference is looked for in a .mthds/methods/ directory above it.

Security

• A bundle loaded from content strings never reads the runtime's disk: a PipeDocGen step of such a bundle read its template_file beside whatever its source named, so a caller's mthds_sources on /v1/validate, a files[].source on /v1/resolve, /v1/codegen or /v1/pipe-io, or a source key written on the step in the bundle's text could make the runner read a file from its own disk, and an address-based reference searched .mthds/methods/ directories above that label too. Both now start only from a bundle file the runtime read itself, which the parser records as PipelexBundleBlueprint.host_bundle_file and the crate carries as LibraryCrate.host_bundle_files, outside its fingerprint and its normalized form; a content-string bundle reads only the files sent with it, and a step's source is overwritten whenever the pipe is built.

[v0.84.0] - 2026-10-12

Highlights

pipelex now reports anonymous usage statistics, on by default. Commands, runs, validations and code generations are counted with closed-list properties only, never a method, a prompt, an input or an output, and DO_NOT_TRACK, PIPELEX_USAGE_STATS=0, pipelex usage-stats disable or [usage_stats] enabled = false in a project turn them off.

Added

• Anonymous usage statistics: pipelex now reports anonymous counts of its use to Pipelex, on by default: a command_completed per command of the pipelex and pipelex-agent CLIs, a run_completed per run however it ended, with a model_used per model when the run's usage events were read, a method_validated per validation and a code_generated per code generation, whatever started them. Every property is a count, a boolean or a value from a closed list: no method, pipe code, concept name, prompt, input, output, file name, error message or argument is ever sent, and a model outside the backend tables pipelex ships is sent as other. The first command with statistics on prints a notice on stderr, once per machine, except where stderr is a machine contract (pipelex-agent with JSON errors), and pipelex init shows the same text on stderr whenever statistics are on, once per run. Statistics stay off under DO_NOT_TRACK, PIPELEX_USAGE_STATS=0, pipelex usage-stats disable, the mthds CLI's former DISABLE_TELEMETRY opt-out, [usage_stats] enabled = false in a project's .pipelex/pipelex.toml or in the packaged configuration, a ~/.mthds/usage-stats/ pipelex cannot look into, and the pytest integration mode; the usage statistics page lists what is collected. A dedicated client sends them to PostHog's EU region, from a detached sender after a CLI command and from a daemon thread in a Python program or the API server; telemetry.toml and the telemetry you configure are untouched.
• pipelex usage-stats: status (with --format json), disable, enable and reset-id show and change the statistics of every Pipelex tool on the machine, through the state they share in ~/.mthds/usage-stats/. PIPELEX_USAGE_STATS_DEBUG prints each event to stderr as a JSON line instead of sending it, and PIPELEX_USAGE_STATS_ENDPOINT sends to a loopback origin for tests. Each queued file names the endpoint its events were queued for, and a sender posts the files naming its own origin and those naming none, so events queued under the variable never reach PostHog.
• [usage_stats] enabled: a new pipelex.toml section, true in the packaged configuration. Set to false in a project's .pipelex/pipelex.toml it turns statistics off for everyone working in the project; it is read from the project's own file, never from ~/.pipelex/, and a file that cannot be read turns them off too.
• Token usage names the backend that served the call: LLMTokensUsage, ImgGenTokensUsage, ExtractTokensUsage, SearchTokensUsage and JudgmentTokensUsage gain backend_name, set by the job from the backend whose worker ran it, so a run's usage events credit each call to its own backend even when two backends call the model by the same id, as after a fallback. A synthetic report no backend made, a dry run's, leaves it None.
• @default-judgment-vision: the judgment deck names a second alias, for a judgment model that reads images, beside @default-judgment, which stays TypeSafe's text-only jev-1.13.0. It points at OpenAI's gpt-6-luna, which judges through OpenAI's Decisions API; no inference backend of Pipelex calls that API yet, so on your own keys a PipeJudge naming the alias finds no model when it runs. Run pipelex update to bring the alias into an installed deck.

Changed

• ConceptLibraryAbstract.list_own_concepts (Breaking): the concept library declares the concepts a loaded method declares itself, without the natives and the concepts of its dependency packages, so a custom implementation of ConceptLibraryAbstract implements it.

Fixed

• A {% filter %} block prints its result as a {{ }} tag does: a filter block whose filter returns something other than text, such as {% filter markdown %}…{% endfilter %} in a document template or {% filter length %}, now prints its result as a {{ }} tag prints a value, through the environment's finalize and then as text, where it used to fail the render with a type error naming a Python type. A block whose filter returns text prints as before, and the printed result is charged to the render's budget like any printed value.

Security

• uv.lock refreshed past the open Dependabot alerts: the lock the pipelex/pipelex-api Docker image installs from now holds patched releases of anyio, datamodel-code-generator, multidict, oauthlib and urllib3, and a development checkout also gets patched docling, transformers, torch, accelerate, fsspec and setuptools through the docling extra and a patched Werkzeug through the dev extra. No pyproject.toml range moved, so an application installing the pipelex wheel picks these releases up through its own resolution.

[v0.83.0] - 2026-10-11

Added

• LLMCompletionTruncatedError and LLMCompletionRefusedError: two subclasses of LLMCompletionError, the first for a text completion cut at its output limit or its context window, the second for one the model declined to write or a safety filter stopped. Both are content errors in the input domain, not retryable, answered with HTTP 422 and caller-facing under STRICT disclosure, and carry model_handle, pipe_code and the provider's stop_reason, a truncation also carrying the limit it hit as truncation_limit, max_tokens or context_window, the output_tokens used and the max_tokens sent; the message names the model, the pipe and those values, never the partial text. Each ends with a change_input next step fitted to what stopped the text: revise the prompt or the input after a refusal, raise the pipe's max_tokens or shorten its input at the output limit, set the pipe's max_tokens up to the model's limit when the request sent none, and shorten the input, lower the reasoning effort or choose a model with a larger window, never a higher max_tokens, at the context window.

Changed

• The Bedrock client's chat returns a BedrockChatResult (Breaking): BedrockClientProtocol.chat returns a named result holding the text, the token usage and Converse's stopReason, in place of a (text, usage) tuple, so a custom Bedrock client returns read_converse_response(response=…) or builds the result itself.
• A lowered Anthropic structured-output limit is said: when a structured generation on an Anthropic model lowers max_tokens to fit its structured-output timeout, the call logs it, at warning level when the pipe set the limit and at debug level when it is the model's default, and an error the lowered limit can explain, a structured output that failed validation or came back incomplete, or a timeout, ends with a sentence saying the limit was lowered and to what, never a rate limit, an authentication failure, an overload, a server error or a lost connection.

Fixed

• A truncated, refused or filtered text no longer passes for a result (Breaking): every LLM worker, OpenAI chat completions whether direct or behind a gateway such as Portkey or OpenRouter, the OpenAI Responses API, Anthropic, Google, Bedrock and Mistral, now reads its response's stop value before it returns a text, so a text that stopped short fails its pipe with LLMCompletionTruncatedError or LLMCompletionRefusedError where it used to come back as a successful output, empty or partial, its billed usage still reported and recorded on its span. Each provider's vocabulary is read, including a gateway's pass-through of another provider's value such as max_tokens or content_filtered, an unknown value being logged at warning level and taken as normal, except that an incomplete Responses API answer is a truncation whatever its reason; a Gemini prompt blocked before any candidate is a refusal, and structured generation keeps its configured re-asks. A Bedrock answer is read for every text block it holds, so one holding none fails with an LLMCompletionError where it used to raise an IndexError when its message was empty, or a KeyError when its first block was not text.

[v0.82.0] - 2026-10-10

Added

• Rating carries the label of its level: the Rating native has an optional label, which the MTHDS standard's native set pinned at 5.0.0 defines as the name of the selected level when the scale declares labels, held in RatingContent.label and stated by the input-form descriptor, the I/O contracts and the generated Python and TypeScript types. A PipeJudge whose levels carry labels fills it with the label of the level it chose, while a PipeLLM whose output is Rating, or any other producer, may fill it like any optional member; either way a Rating renders in a prompt as its label when it has one and as its level otherwise, so $severity reads Workaround available for a rating carrying that label and 1 for one carrying none, and its JSON rendering carries the label only when present. Since a crate materializes the pinned definition, a crate whose methods use Rating gets a new normalized fingerprint, and types generated before this release gain the field when pipelex codegen types regenerates them.
• A log line's advice in user_action: a log call puts what its reader should do in a user_action field, one imperative sentence, and the console sink prints it whole on a line of its own under the record, after →, in cyan, while every other sink writes it as a field like any other. Pipelex's own warnings carry their advice there, such as Run pipelex migrate to update it on a stale configuration file, so their message says only what happened.
• A PipeJudge asks several questions in one request: a PipeJudge may set questions instead of question, a table of questions keyed by name, each holding its question and its own options, levels, criteria and threshold, checked under the single form's rules with a refusal naming the question, and the judging model answers them all in one request over the same evidence; the verdicts fill the output's structure, whose fields must be exactly the question names, each holding its question's YesNo, Choice or Rating or a concept refining it, which the load checks field by field (inadequate_output_concept). A question the model declines leaves its field holding nothing when the field may hold nothing, being neither required nor given a default_value, or, in a structure class, typed to admit None, with a warning naming it under judgment_question and its refusal in the step's execution data, and fails the step with JudgmentRefusedError naming the question otherwise, since a default would read as a verdict the model never gave. The kernel's run_multi_judgment does the same for a programmatic caller, taking the questions as AskedQuestions and the output's content class, and returning a MultiJudgmentResult with each question's outcome; a class whose fields are not the questions' names is refused with JudgmentOutputFieldsError before the model is called.
• package_prefix chooses which console lines name their package: a setting under [runtime.log.rich_log] decides which lines the console sink starts with their logger's top-level package name, dimmed. libraries, the default, keeps the rule that names another library's package and leaves a line from pipelex or a pipelex_ package bare; all names every line's package, so pipelex:, pipelex_api: and a plugin's name tell apart which component spoke; none names none. A line logged on the root logger never carries one.

Changed

• MTHDS standard 5.0.0 (Breaking): pipelex now requires mthds==0.21.0 and pipelex-sdk==0.38.0, the releases that report MTHDS standard 5.0.0, so everyone downstream inherits those exact versions and a project that pins either package itself has to move with them. pipelex --version prints mthds-standard 5.0.0, every crate pipelex normalizes is stamped with mthds_version 5.0.0 and materializes the native set the standard pinned at 5.0.0, and a package whose METHODS.toml constrains mthds_version to ^4.0.0, ~4.0.0, 4.* or exactly 4.0.0 now logs a warning when it loads, which >=4.0.0 or ^5.0.0 does not. PipeJudge judges the evidence of its prompt with two-sided criteria and labelled levels, and asks several questions in one request, as the standard's 5.0.0 PipeJudge defines.
• PipeJudge judges the evidence of its prompt (Breaking): prompt is now required and holds the evidence, a template rendered exactly as a PipeLLM's prompt is with its images and documents presented to the judging model as files, beside a required question: prompt is no longer a synonym of question, a pipe writing its question there is refused with a message saying where each goes, and a pipe is rewritten as prompt = "@message" beside its question. The model sees an input only as the two templates render it: every declared input must be read by the prompt or the question (extraneous_input_variable), an image or a document read by the question is refused (input_stuff_spec_mismatch), the model's file capability is checked against what the prompt reads, an absent optional input renders as its guard says, such as @?note, and a Dynamic input renders as text. criteria takes both yes and no, a one-sided or empty table being refused; a level of levels may be a { label, description } table, labels all or none and distinct, and the Rating verdict then carries the label of the level chosen; a model that declines the question fails the step with the new JudgmentRefusedError, a content error naming the pipe and the model, where no verdict is ever read off a refusal.
• The judgment worker contract carries a rendered prompt (Breaking): JudgmentJob and JudgmentAssignment carry a JudgmentPrompt, the rendered text with its images and documents, in place of the state, images and documents keyed by input name, and JudgmentState is gone; YesNoQuestion carries one optional criteria of type YesNoCriteria with both sides in place of yes_criterion and no_criterion; RatingQuestion.levels is a list of RatingLevel, each with a label, a description or both; and JudgmentWorkerAbstract.judge returns a JudgmentOutcome per question, an answer or a JudgmentRefusal. The judgment contract a backend plugin implements, with the family's errors a worker raises, is published in the Inference SPI table, and the kernel's run_judgment takes the evidence as a UserPromptContent, build_judgment_material and material_value being gone.
• Console lines without the emoji prefix or the path column (Breaking): a line logged under the pipelex package or a pipelex_ one, the runtime's, the API server's or a plugin's named that way, and a line logged on the root logger start with their message, and a line another library logged starts with that library's top-level package name, dimmed, such as httpx:, where every line used to start with an emoji or a bracketed logger name. The column naming the source file and line of each record is off by default; set is_show_path = true under [runtime.log.rich_log] to show it, is_link_path_enabled still making it clickable. The pipelex.tools.log.log_formatter module is gone with its EmojiLogFormatter, so code that formatted records with it uses the stdlib's logging.Formatter.
• Log messages are one short sentence (Breaking): Pipelex's log messages, and its API server's, say what happened in one sentence that starts with a capital and ends with no period, and at INFO and above hold no identifier and no backtick in at most 80 characters, the advice they used to append now riding user_action. Warnings about one event became one: whichever kind of inference job carried no usage, the line is An inference job reported no usage with inference_job_type; a stale configuration file is A configuration file is out of date and was migrated in memory only whatever its remedy; and a PipeBatch over a large list is A PipeBatch fans out over a large list without durable execution, bounded or not, with max_concurrency absent when the fan-out is unbounded. What breaks is a log query or an alert written against an old message.
• The API server's refusals of a caller's credentials log at DEBUG (Breaking): a request with no bearer token, an expired or invalid token or a wrong API key logs A caller's credentials were refused at DEBUG, with auth_mode and auth_refusal_reason (missing_bearer_token, expired_token, invalid_token or api_key_mismatch), since the error line the server writes at WARNING for every 401 already records the refusal. A token that verifies but whose user_id claim is missing, not a path-safe segment or the reserved single-tenant id still logs at WARNING, its user_action telling the token issuer what to fix, and an unset JWT_SECRET_KEY or API_KEY logs at ERROR with the variable's name in env_var. An alert on the old authentication warnings counts the 401 error lines instead.
• Exceptions ride as fields at every level: a DEBUG or VERBOSE line about a handled exception, such as a Google client that could not be closed, has a fixed message and carries the exception's class and text as error.type and error.message, as the lines at INFO and above already did, rather than splicing them into its text. The retry line names the class of what the attempt raised under error.type rather than exception_type.
• make check-log-calls holds a message's wording and its exceptions: the log-call guard also refuses, at every level, a message that starts with a lowercase letter, ends with a period or an ellipsis, holds a backtick or splices a handled exception into its text, through an f-string, a %, a .format() or a task's exception(), and, at INFO and above, a message that holds an identifier, a word with an underscore or a call such as setup(), or runs past 80 characters. The rules are lowercase-start, trailing-period, backtick, spliced-exception, identifier and length, specified on the log-call guard's page of the contributor documentation, and every call in the tree passes them with an empty baseline.
• A refused enum value names the valid ones: a validation error for an unknown enum value, in a configuration file or anywhere else Pipelex formats pydantic's errors, now lists the values the field accepts, invalid enum value 'inptu', expected 'input', 'input_cached', …, where it used to name only the refused value.
• A field that never holds nothing refuses null (Breaking): a structure field with a default_value is generated as X = Field(default=…) rather than X | None, and a required field naming native.Anything as NonNullAny (pipelex.core.stuffs.non_null_any), any value but None, so a value setting either to null, an input or a model's answer, is refused, and a binding step reading such a field never records an absence its static analysis ruled out. Leave the key out, or leave its CSV cell empty, to get a field's default. The codegen projections follow: a defaulted field is X = Field(default=…) in python-pydantic and python-structures and a bare .default(…) in ts-zod, typed T rather than T | null. The JSON schema of a defaulted field, the one a pipe's IO contract publishes as an input's json_schema and a model is asked to fill, drops its null arm: {"type": "string", "default": …} rather than {"anyOf": [{"type": "string"}, {"type": "null"}], "default": …}.

Fixed

• An absent optional image or document is left out of its prompt: a PipeLLM or PipeImgGen whose prompt read an optional image or document behind its guard, such as @?photo or {% if photo %}, failed with "Could not find image 'photo' in context" when the input was not given, dry runs included. The file is now left out, taking no number and reaching no model, while an absent required file is still refused. A template reading a name aliased to a slot later resolved absent no longer fails with a KeyError either: the alias holds nothing, as its target does.
• A Google client's close at teardown is no longer garbage-collected: when a Google LLM or image-generation worker was torn down inside a running event loop, nothing but the loop referenced the background task closing its async client, and a loop holds its tasks weakly, so the task could be collected before the client was closed, with the asyncio error Task was destroyed but it is pending!. Each close task is now held until it is done.
• A condition whose outcome may be skipped declares it: a PipeCondition routing to an outcome pipe that takes plainly an input the condition declares optional must declare its own output optional, and is refused with optional_not_handled otherwise, since a run without that input skips the outcome and resolves the condition's output absent; an outcome the condition's expression chooses only with that input present declares it forced (!) instead, since validation does not read the expression. Every name such an outcome always stores in its caller's memory counts as maybe-absent too, so a sequence binding one into a plain output is refused where it used to validate and then resolve absent; the outcome is listed in liftable_pipes under its condition, and a ! input on an outcome counts in the optional_force_redundant lint.
• A sequence step that may be skipped keeps what its run may store: a step an absent input may lift, whose pipe stores a name on some runs only, now leaves that name maybe-absent when a run may store an absence there, so a sequence binding it into a plain output is refused with optional_not_handled rather than validating and then resolving absent.
• A configuration value of the wrong type is a validation error (Breaking): a model's costs, listed_constraints, valued_constraints or rules in a backend file or in a plugin's internal model, a backend's constraints in backends.toml, and package_log_levels in pipelex.toml no longer crash the boot with a bare AttributeError or TypeError naming nothing when written as a value of the wrong shape, such as costs = "free" or a date; the boot fails with a message naming the field, the model, the backend and the file, or the plugin, and an empty inference.dry_run.image_urls is reported the same way. A plugin may set an internal model's costs to None. Some values that used to be accepted are now refused: a table as listed_constraints, a string as interpreter.scan.excluded_dirs, a price that is nan or infinite, and a max_tokens setting that is neither an integer nor "auto", which used to fall back to the model's default.
• A construct path holding nothing leaves a defaulted field to its default: a PipeCompose construct field fed { from = "doc.note" } where note holds nothing is left unset when the target field refuses null but has a default, so it takes that default rather than failing the composition; a target field that admits null still receives it.
• A model's null on a defaulted field is refused where it can be asked again: the class a worker rebuilds from a structure's JSON schema keeps a defaulted field non-nullable, so a model answering null there is asked again rather than failing when its answer reaches the caller's class. A model answering null on a required native.Anything field is asked again in process, but across a worker boundary its schema stays open, so the step fails there.
• A field whose Literal lists None may hold nothing: a Python class field typed Literal["a", None] or object is read as one that may hold nothing, so a binding step reading it declares a possible absence and a PipeCompose path holding nothing gives it None rather than its default.
• Binding and batch refusals name what the author wrote: a binding step carrying a pipe step's fields proposes the remedy that applies, a dotted batch_over for a dotted from, a plain batch for a bare name, or moving nb_output and multiple_output to a pipe step, and a sequence step's refusal of its batch or count fields names the step rather than blaming the pipe the step runs. At run time, a batch over a dotted batch_over names that path, never the private _bound_ name the sequence binds it under, in its message and in the error's variable_name, and a value there that is not a list is refused with PipeRunInputsError rather than an uncaught WorkingMemoryTypeError.

Removed

• ConfigModelError and ConfigModel's conversion helpers (Breaking): ConfigModel.transform_dict_str_to_enum, transform_dict_of_floats_str_to_enum, transform_dict_keys_str_to_enum and transform_list_of_str_to_enum are gone, and with them ConfigModelError, which only they raised. A configuration model holding enums in a container annotates them with LaxEnum from pipelex.system.configuration.config_model, list[LaxEnum[MyEnum]], and pydantic converts the strings itself.
• [inference.gateway_test] (Breaking): the maintainer-only section whose config_id_substitutions map swapped the Pipelex Gateway's model configurations is gone, with its GatewayTestConfig model and the gateway_test field of InferenceConfig, as nothing has read it since the Gateway backend left in 0.73.0. Migration: run pipelex migrate, which deletes the section from the file on disk (ledger entry pipelex-config@8).

Security

• The API server refuses to start on an unknown AUTH_MODE (Breaking): a value that is not exactly none, jwt or api_key, such as jwtt or JWT, now stops the server at startup with InvalidAuthModeError, whose message names the valid modes, where the server used to log a warning and serve every /v1 route without authentication. An unset or empty AUTH_MODE still means none. A deployment that booted on a mistyped mode sets it to the mode it meant.

[v0.81.1] - 2026-10-10

Added

• Formatted Markdown for document engines, and a markdown filter for plain-data templates: the document engine contract gains format_markdown in pipelex.cogt.doc_gen.formatted_markdown, which reads a Markdown text by the rules the built-in PDF engine prints it by and returns a FormattedMarkdown, plain data of paragraphs, headings, list items with their marker and the paragraph or heading they open with, code blocks, rules and tables whose cells carry their column's alignment, every block with the list depth and the quote depth it sits at and holding text spans with their bold, italic, strikethrough, code and link, whose str() is its plain text and which is false when the text formats into nothing, so an engine prints Markdown formatted in its own format. make_plain_data_template_environment() registers a markdown filter that returns one, {{ invoice.notes | markdown }}, which is false for an empty or a blank text, so {% set notes = invoice.notes | markdown %}{% if notes %}…{{ notes }}…{% endif %} converts the text once to test and print it, and takes an optional finalize through which an engine prints it, a value printing its plain text without one. Inside a template render the conversion is charged to the render's budget; called from an engine's own code it spends from a budget of its own, as large as one render's, and an overdraft raises MarkdownFormattingBudgetError.

Fixed

• A PDF of deeply nested emphasis prints: the built-in PDF engine no longer fails with a RecursionError on a Markdown text whose emphasis nests hundreds deep, such as four hundred *a before a word and four hundred c* after it; inline markup nested past fifty levels is dropped and its text printed.

[v0.81.0] - 2026-10-10

Added

• The console shows a log call's fields and renders named layouts: the console sink prints a record's fields after its message as a key=value suffix, Scanned the inputs files=7, each value on one line and cut short past 80 characters, a string or the JSON of a list or a mapping before it is quoted so a quoted value keeps both its quotes and a cut one leaves no unbalanced quote or bracket, a path or a list of paths (a field named file.path or ending in _path, _paths, _dir, _dirs, _file or _files) at its start so the last file's name stays, a handled exception's error.message and a PipeDocGen template finding's text only past 2000, leaving out the run identifiers, and colours a value by its field's name, a pipe code red and a concept bold green, with any other field dimmed. A call can name a console layout with layout=, a Rich template over its fields in which every value is escaped, starting with LogLayout.PIPE_RUN for the pipe-run tree; every other sink writes the plain message and the fields.
• Log-call conventions and their guard: the logging documentation states how Pipelex's own log calls are written, a fixed message with its values in fields named from a shared vocabulary, an exception carried by the record rather than spliced into the text, no run identifier, payload, markup or emoji, and what each level promises. make check-log-calls (pipelex-dev check-log-calls), part of make agent-check and CI, refuses an interpolated or non-literal message at INFO and above and a Rich markup tag in a message at any level, against a committed baseline of the existing calls that only shrinks: --against <ref> and --against-merge-base <ref> refuse an entry the baseline at the base revision does not list, which CI runs against a pull request's base and make against the merge base with origin/dev. pipelex.tools.log.error_fields gives a handled exception's class and text as the error.type and error.message fields of a line that carries no traceback, a pydantic ValidationError's text as its locations and reasons without the values it refused or the name of a key the model forbids, and any message that may quote the input, a custom validator's or one of pydantic's own templates', such as an unknown discriminator tag, as its error type alone.
• Summary events for inference calls and pipe runs: every inference call, an LLM call, an image generation, an extraction, a search, a judgment or a document print, a call its checks refuse included, ends with one INFO event, Inference call ends, carrying the operation under gen_ai.operation.name, the model under model_handle, backend_name, sdk, gen_ai.request.model and gen_ai.response.model, the tokens under gen_ai.usage.input_tokens and gen_ai.usage.output_tokens and the price under cost_usd where the call recorded them, duration_ms, and outcome, success, error with error.type, or cancelled for work stopped from outside, logged by the worker bases so every provider's and plugin's worker gets it. Every live pipe run ends with Pipe run ends, logged as the pipe's own span closes and carrying its ids, with the announcement's fields, duration_ms, outcome and error.type, so a run's json output alone gives latency and cost per operation and model; an event that cannot be built is replaced by the warning A summary event could not be logged and never changes the work's outcome. The console draws each on one line through LogLayout.INFERENCE_CALL_END and LogLayout.PIPE_RUN_END; a document engine overrides render alone, and the print stage that calls it logs the event.
• Request- and page-priced usage: a usage says what its counts are in pricing_unit (PricingUnit in pipelex.cogt.usage.pricing_unit), token, request or page, and a worker billed by the request or by the page records it with record_unit_priced_usage (pipelex.cogt.usage.usage_cost), as the Linkup workers and the extraction page fallback now do, so the summary event carries the call's cost and no token counts.

Changed

• Log lines carry a fixed message and their values as fields (Breaking): every INFO, WARNING, ERROR and CRITICAL line of Pipelex and of its API server has one fixed sentence for its message and carries what varies, a pipe code, a model handle, a file path, a handled error's error.type and error.message, as fields named from the vocabulary in the logging documentation, so a log store groups a line by its message and filters it by its fields, and the baseline of make check-log-calls is empty, every call being held to the conventions. A line nobody can act on moved down to DEBUG, a lost inference usage record up to ERROR, an exception logged and then re-raised, a cleanup's failure while another error propagates and a swallowed ValidationError carry no traceback, whose text could quote a run's inputs, so a failed pipelex run prints one, and pipelex run and pipelex graph render log an unexpected failure at ERROR with its traceback, which the console renders under the line without its local variables and a structured sink writes to the log store, while the command's own output names the exception's type and message whatever the sink and the level. What breaks is a log query: the API server's error record drops its event: api_error field and renames route, user_id, error_type, status, provider and model to url.path, user.id, error.type, http.response.status_code, backend_name and model_handle, the API server no longer writes a refused user_id claim or X-User-Id header under user.id, the claim's type riding claim_type instead, and the warning that a configuration file is out of date is one line per stale file, the file in file.path, where it used to list them all in one.
• Debug and verbose log output: the DEBUG and VERBOSE lines are fewer and shorter, each naming what it is about rather than narrating every step, and none carries a payload any more: no base64 data, prompt, rendered template, raw response or model dump. An LLM call's reasoning settings are logged once per call, at DEBUG with each setting sent as a field, rather than twice at VERBOSE, and the error for undecodable base64 input gives the input's length instead of its first bytes.
• The pipe announcement is a plain message with fields: every live pipe run logs Pipe run starts with pipe_type, pipe_code, output_concept and pipe_depth as fields, where the json, otlp and gcp sinks used to receive Rich markup inside the message, and the console draws the same coloured pipe tree from those fields through LogLayout.PIPE_RUN. The warning that a model's fixed temperature replaced the requested one carries its values as fields in the same way: model_handle, backend_name, sdk, the model's handle under gen_ai.request.model and the provider's model id under gen_ai.response.model as on the LLM call's span, the requested temperature under gen_ai.request.temperature, and fixed_temperature; the verbose line saying a model's settings were not checked, since its backend's SDK is not installed, carries the same model fields.
• The default output logs every inference call and every live pipe run: at the default INFO level an application embedding pipelex now gets an Inference call ends line after each inference call and a Pipe run ends line after each live pipe run. To quiet either, raise its logger's level in [runtime.log.package_log_levels]: pipelex-cogt-inference-inference_call_summary = "WARNING" for the inference event, and pipelex-pipe_machinery-pipe_abstract = "WARNING" for the pipe-run end, which quiets the pipe announcement too, since the two share that logger.
• log.set_level_by_name takes only Pipelex level names (Breaking): it accepts a LogLevel name in any case and raises ValueError for any other, so the stdlib spellings WARN, FATAL and NOTSET it used to accept are refused. Pass WARNING for WARN and CRITICAL for FATAL; NOTSET has no counterpart, VERBOSE being the lowest level.

Fixed

• Model descriptions and credential errors carry no backslashes: a model's description in an error message or a log line, such as gpt-5 → SDK[openai]•Backend[openai]•Model[gpt-5-2025], no longer has a backslash before each bracket, and the error naming a backend's missing credentials tells you to add enabled = false under [openai] rather than \[openai]. pipelex run prints a failed run's message exactly as written rather than reading it as markup.
• No HTTP request line per inference call: at the default INFO level an inference call made through openai 3.x no longer logs an HTTP Request: POST https://… "HTTP/1.1 200 OK" line, carrying the provider's endpoint URL and the HTTP status, on the console or in the json sink. The defaults under [runtime.log.package_log_levels] now give httpx2 and httpcore2, the HTTP client forks openai 3.x sends its requests through, the levels httpx and httpcore already had, WARNING and INFO; set httpx2 = "INFO" there to see the line again.
• An empty list's output panel says so: the title of the panel showing an operator pipe's output ends with [empty list] when the pipe produced an empty list, a label the console used to drop, as it already showed [1 item] or [3 items].

Removed

• The DEV log level (Breaking): LogLevel.DEV, LOGGING_LEVEL_DEV and log.dev() are gone; the levels are VERBOSE, DEBUG, INFO, WARNING, ERROR, CRITICAL and OFF, and code calling log.dev() calls log.debug() instead. A configuration file naming DEV, as default_log_level or as a level under [runtime.log.package_log_levels], is migrated in memory at boot by ledger entry pipelex-config@6, which reads it as INFO, the level that lets through the same records now that nothing logs at DEV, and the boot warns that the file is out of date. Migration: run pipelex migrate, which rewrites DEV to INFO in the file on disk.
• Logging helpers nothing called (Breaking): FuncRegistry.log() and FuncRegistry.set_logger(), with the func_registry logger they wrote to, InferenceManager.print_workers() and LogLevel.from_int() are gone, with no replacement. Code that needs a LogLevel from a stdlib level number maps it itself.
• Cost helpers outside pipelex.cogt.usage.usage_cost (Breaking): compute_tokens_usage_cost is imported from pipelex.cogt.usage.usage_cost rather than pipelex.cogt.usage.cost_registry, CostRegistry.compute_total_cost is gone for compute_total_cost in the same module, and the TokensUsage alias of pipelex.reporting.reporting_types is gone: import TokensUsage from pipelex.cogt.usage.usage_cost, where it is a plain union of the usage types without the old discriminator, or use the discriminated AnyTokensUsage, which stays in pipelex.reporting.reporting_types.
• is_markup_enabled (Breaking): the console reads no log message as Rich markup, so the [runtime.log.rich_log] key that switched it is gone, along with VERBATIM_MARK in pipelex.tools.log.log_fields. A message now prints exactly as written, so a list[int], a bracketed path, the [myapp.jobs.nightly]: prefix of a logger named in lowercase and the [cycle] marker of a circular content no longer vanish, while a message of your own that relied on markup for its colour shows its tags and should put its values in fields. Migration: run pipelex migrate, which deletes the key from the file on disk (ledger entry pipelex-config@7).

[v0.80.0] - 2026-10-09

Changed

• MTHDS standard 4.0.0 (Breaking): pipelex now requires mthds==0.20.0 and pipelex-sdk==0.37.0, the releases that report MTHDS standard 4.0.0, the language this runtime has implemented since v0.75.0, so everyone downstream inherits those exact versions and a project that pins either package itself has to move with them. pipelex --version prints mthds-standard 4.0.0, every crate pipelex normalizes is stamped with mthds_version 4.0.0 while crate fingerprints stay the same, and a package whose METHODS.toml constrains mthds_version to ^3.0.0, ~3.0.0 or exactly 3.0.0 now logs a warning when it loads, which >=3.0.0 or ^4.0.0 does not.
• Stored names are plain input names (Breaking): every name under which a step stores a value in working memory, a PipeSequence step's or a PipeParallel branch's result, the batch_as of either, and a PipeBatch's input_item_name, must now be a plain input name matching [a-z][a-z0-9_]*, as a binding step's result already had to, and a name in any other form, such as Pages, doc.pages or _pages, is refused as invalid_input_name wherever a bundle loads, and by the MTHDS JSON Schema, which now carries the input-name pattern on these fields. Rename such a name to a plain one, such as pages, along with every input, binding path and batch_over that reads it; a plain batch_over is still refused only when it starts with the reserved _bound_.
• Hosted-run guidance in messages and help: the next step of a refused Pipelex API key names pipelex login and the working directory's .env rather than a shell export, which a .env file setting the key overrides, and pipelex login names [run] execution = "hosted" rather than pipelex init to make hosted runs the default. A CLI run missing a provider key, and the pipelex doctor report, offer the hosted Pipelex API as a way out; a failed pipelex-agent boot points at pipelex-agent migrate and pipelex-agent init rather than the interactive pipelex init config; and FormerReleaseConfigError carries its remedy, pipelex migrate, as its user_action. The run help of both CLIs names hosted runs, catalog ids, local method directories and TOML or inline inputs, and pipelex-agent --help describes the program rather than printing an internal note.

Fixed

• The json log sink keeps each field's type: a field value JSON refuses outright, a mapping with a non-string key or a circular reference, is written as its repr alone, where it used to turn every other field on the line into its repr as well, so a number or a boolean beside it arrived as "7" or "True" and a query over that field missed the line. The other fields now keep their JSON types, as they already did under the gcp sink.

[v0.79.1] - 2026-10-09

Fixed

• The wait_and_retry advice says to run again: the user_action.detail of a transient inference failure said "the system will retry automatically", which no longer held by the time anyone read the failed run's report, and now says to wait, at least the provider's Retry-After delay when it gave one, then run it again; the advice on an empty or malformed Mistral response says the same.
• A malformed Retry-After is no delay: a provider's Retry-After that is negative or not a finite number (inf, nan, 1e999) is ignored rather than taken as a delay, so the advice says to wait a moment instead of naming an impossible wait.

[v0.79.0] - 2026-10-09

Highlights

Run any method on the hosted Pipelex API with nothing but a Pipelex API key. pipelex run --hosted sends your bundle, a published address or a catalog id (mt_…) to the hosted API and saves the outputs where a local run would, with no provider key and no inference configuration on your machine. pipelex login gets the key through your browser, pipelex init offers the hosted API as its default, and Python code runs there directly with pipelex-sdk's PipelexAPIClient, which now ships with pipelex.

Added

• Hosted runs with --hosted, --local and [run] execution (Breaking): pipelex run method|pipe|bundle and pipelex-agent run run on the hosted Pipelex API under --hosted and on this machine under --local, the new [run] execution setting (default local) choosing when neither is given, and --base-url or PIPELEX_BASE_URL naming another server. A hosted run boots nothing locally, uploads the local files its inputs name, prints the run id as soon as the run is acknowledged and names it in any later failure, Ctrl-C included. The agent CLI's --runner pipelex|api becomes --runner local|hosted, on pipelex-sdk's PipelexAPIClient, which pipelex now pins exactly.
• pipelex login: gets a Pipelex API key through the browser, or from a hidden prompt with --paste, checks it against the hosted API and saves it to ~/.pipelex/.env as PIPELEX_API_KEY without ever printing it. It warns when a working-directory .env would override the saved key, and PIPELEX_APP_URL aims it at another Pipelex app.
• pipelex init asks where runs execute: Enter takes the hosted Pipelex API, which signs you in and needs no provider key, while the other answer sets up local backends and credentials as before; the answer is saved as [run] execution. pipelex doctor and pipelex-agent doctor judge a hosted setup by its API key, pipelex doctor --fix takes the hosted default only for a brand-new home, and pipelex-agent init accepts "execution": "hosted" in --config.
• pipelex migrate removes what a former release left for the Pipelex Gateway: a configuration written for the Pipelex Gateway is refused at boot with the new FormerReleaseConfigError, which points at pipelex migrate. That command, pipelex-agent migrate (under former_release), pipelex init and pipelex doctor --fix remove the Gateway's backend, routing profiles, routes and files, keeping Pipelex Manifold's and a copy of every file they change.
• Shared helpers in the document engine contract: pipelex.cogt.doc_gen.layout_display (display_scalar, is_numeric_column, markdown_as_html) and pipelex.cogt.doc_gen.template_environment (make_plain_data_template_environment()) give a plugin's engines the value display, Markdown conversion and sandboxed, strict Jinja environment of the built-in PDF engine, without importing ReportLab or Pipelex's internals.

Changed

• RenderResources.load returns the media type with the bytes (Breaking): a document engine's load returns a LoadedResource holding data and the mime_type its source declares (an https:// response's Content-Type, a data: URL's type, or the storage provider's type for a pipelex-storage:// key), else None. PLUGIN_API_VERSION moves to 6, so a plugin declaring targets_api = 5 is refused at discovery until it is rebuilt to read .data.

Fixed

• A partial home configuration directory gets the kit's missing files: every boot copies into ~/.pipelex/ (or PIPELEX_HOME) each kit file it lacks, never overwriting a file or writing through a symbolic link, the inference files as one unit only when inference/backends.toml is absent. A directory holding anything at all, such as an earlier release's pipelex_service.toml, was left as it was, and every boot then failed with "Config files are missing for the inference backend library".
• The internal backend's models are served whatever the routing profile: a profile routing a model's name to no enabled backend left the internal models (reportlab-pdf, pypdfium2-extract-pdf, docling-extract-text and those plugins add) unserved, so local extraction and document steps were refused at load, as under the default all_enabled_backends profile with only the internal backend enabled. The internal backend now serves such a name, while a route sending it elsewhere still decides and disabling the backend still withholds its models.
• pipelex-agent init --help prints list[str]: the --config help showed the schema's "backends": list[str] as list, because Rich read [str] as markup.

[v0.78.0] - 2026-10-08

Highlights

A client can ask the runner what a model reference means. GET /v1/models/check answers whether a reference resolves, as what kind, and to the model a run would call, from pipelex's own parser and deck, so a client keeps no grammar of model references of its own.

A handle names one model per model type. One handle can be an LLM and a judgment model at once, and a pipe naming a model served only as another type is refused when the method loads rather than at its first call.

Added

• Claude Haiku 5.5 on the anthropic backend: claude-5.5-haiku (model id claude-haiku-5-5) takes text, images and PDF, produces text and structured output, and reasons with adaptive thinking, with up to 128K output tokens. It costs $0.10 / $0.50 per million tokens for a prompt up to 100,000 tokens and $0.50 / $2.50 above, of which the backend file records the first. It refuses temperature but, unlike Sonnet 5.5 and Opus 5.5, accepts a forced tool_choice, so structured output keeps instructor/anthropic_tools.
• One handle, one model per model type: two models of different model types may share a handle, so gpt-6-luna can be an LLM and a judgment model at once, and each pipe reaches the one its family asks for. A backend file declares the second model of a handle on a table of its own with the new handle key, which may not appear in [defaults], and a file declaring one handle twice as the same type fails to load, naming both tables. A plugin may declare an internal model under a name internal.toml already declares as another type.
• GET /v1/models/check, the model reference check: the server answers whether one model reference (?reference=, optionally in one ?type= category, doc_gen included) resolves on this runner, as a 200 verdict discriminated on resolution (resolved or not_found) that carries the reference's kind and name, one match per category where it resolves with the model a run would call (resolves_to, null where its binding reaches no model the runner can call) and its target, description, fallbacks or via, and, on not_found, the suggestions, other_kinds and other_categories a failing validation of the same reference offers, written as references. It answers from pipelex's own parser and the deck lookups a validation runs, so a client no longer keeps its own grammar of model references, and it is a Pipelex API extension, not tagged x-mthds-protocol. A missing or repeated reference or a repeated type is a 422 ValidationError, a reference that is blank, a sigil or a namespace alone, or longer than 199 characters once trimmed is a 422 of the new error_type InvalidModelReference, and an unknown or empty type is a 422 InvalidModelCategory. The library serves the same check as check_model_reference in pipelex.cogt.models.model_reference_check, and the suggestion rule as find_model_alternatives in pipelex.cogt.models.model_suggestion.

Changed

• A model served only as another type is refused when the method loads (Breaking): a pipe naming a handle the deck serves only as another model type, such as a PipeJudge naming an LLM, is refused by pipelex validate, POST /v1/validate and a run's load as an unknown_model item saying the deck serves the handle but not as the type the pipe needs, whose suggestions list only models of that type, where it passed validation and failed at its first call; a deck preset naming one is reported at boot in the same words (a warning, or a refusal under missing_presets_reaction = "raise"), and an LLM override naming one refuses boot. A bare name resolves as a model of the pipe's type, then an alias of that type, then a waterfall of that type, an order the validation and the run's lookup share, so a handle served as another type no longer hides an alias or a waterfall of the same name, and the validation and the setting a pipe's model field is read into accept the waterfall only while model fallback is on. ModelDeck gains is_bare_handle_resolvable, is_reference_defined, get_presets_for_type and peek_inference_model, the run's model lookup without its logs.
• Model specs are keyed by model type and handle (Breaking): InferenceBackend.model_specs and ModelDeck.inference_models are the new ModelSpecIndex, read through get(model_type=…, handle=…), handles_of_type, all_specs, all_handles and types_serving, and InferenceBackend.get_model_spec takes model_type and handle. InferenceBackend.list_model_names, InferenceBackendLibrary.list_all_model_names and InferenceBackendLibrary.get_all_models_and_possible_backends are removed. PluginModelDeclarations.internal_models is a tuple of PluginInternalModel, which carries its name, and DuplicateInternalModelError names the model_type two plugins both declared.
• Usage is reported per model type and name (Breaking): a run calling both kinds of one handle reports two rows in the cost table and the agent CLI's cost summary, and two entries in the graph's usage attribution, where they merged into one row typed by whichever call came last. AggregatedCosts.grouped_by_model is keyed by the new ModelUsageKey, and its model_types is removed.
• handle: reads no sigil (Breaking): a handle: reference writes a bare name without reading a sigil in the validation, the run and the check alike, so handle:@name is the bare name @name, not the alias name, and like any bare name it resolves as a model, then an alias, then a waterfall of that name, a validation refusing it where the deck has none.

Fixed

• A ~name model reference runs the waterfall: a pipe naming ~name or waterfall:name called a model or an alias that shares the waterfall's name, because its setting kept the bare name, and every model type's setting now keeps the sigil, so a run calls the model the validation and GET /v1/models/check name; the resolved_model every pipe reports, and a PipeLLM's resolved_model_for_object, now write such a waterfall ~name, and so does a refusal of a file input naming one.
• A waterfall step that leads back to itself or runs out serves no model: an alias and a waterfall leading to each other, or a waterfall listing its own name, overflowed the stack, and a step naming another waterfall, directly or through an alias, none of whose models is served failed its waterfall with that inner waterfall's error. Such a step, whether it leads back to an alias or a waterfall being resolved or reaches a waterfall that runs out, now serves no model, so the waterfall goes on to its next step, and a run fails with the waterfall's own error only when none of its steps serves a model.
• pipelex-agent models --backend lists past a binding no backend serves: an alias or a preset bound to a waterfall none of whose models the deck serves failed the listing with ModelWaterfallError, and it is now left out like any binding of another backend, the listing reading the deck without a run's logs.
• pipelex-agent check-model applies the validation's rule: a bare alias name, or a bare waterfall name while model fallback is on, is now valid, as pipelex validate and GET /v1/models/check answer, and --type takes doc_gen as the check does.

[v0.77.0] - 2026-10-07

Added

• Claude Opus 5.5 and Claude Sonnet 5.5 on the anthropic backend: claude-5.5-opus (model id claude-opus-5-5, $4 / $20 per million tokens) and claude-5.5-sonnet (model id claude-sonnet-5-5, $2 / $10) take text, images and PDF, produce text and structured output, and reason with adaptive thinking, with up to 128K output tokens each. Both refuse temperature and a forced tool_choice, so structured output uses instructor/anthropic_reasoning_tools, as claude-5.1-fable does.
• GPT-6.1 Sol and GPT-6 Luna on the openai and azure_openai backends: gpt-6.1-sol ($2 / $10 per million tokens) and gpt-6-luna ($0.10 / $0.50) take text, images and PDF, produce text and structured output, reason with a manual effort and fix their temperature at 1, like the rest of the GPT-6 series. On azure_openai their model ids are the deployments gpt-6.1-sol-2026-09-29 and gpt-6-luna-2026-09-22. The shipped deck is unchanged.

Fixed

• A reasoning setting reaches a structured output: a pipe whose model setting carries reasoning_effort or reasoning_budget, the deck's $deep-analysis, $quick-reasoning and $retrieval-premium presets included, now generates its structured output with that setting on every provider, where every language-model worker refused it with LLMCapabilityError "does not support reasoning parameters for structured generation". A model refuses a reasoning setting on a structured output only where it refuses it on text, or on Mistral where its structure method is not instructor/mistral_tools, whose JSON parsing cannot read a reasoning reply; a structured call on an Anthropic tool method with thinking on leaves the tool choice to the model, since a forced tool choice cannot carry thinking.
• A manual thinking budget leaves room for the answer and stays in the model's range (Breaking): an Anthropic or Gemini thinking budget, resolved from an effort or set explicitly, is cut to leave a quarter of max_tokens for the answer, where it could take all but one token of it, and held within the range the model declares with the new min_thinking_budget and max_thinking_budget valued constraints. The kit's Anthropic models declare the API's minimum of 1,024 tokens, so the 512 that minimal maps to is raised to it, and its Gemini 2.5 models declare their ranges, so max effort's 65,536 tokens, which every Gemini 2.5 model refused, are cut to the model's maximum even without a max_tokens. A max_tokens too small to hold the model's minimum beside the answer reserve is refused with an LLMCapabilityError naming the numbers, where the request was sent, and a reasoning effort of none on a Gemini model that always thinks, which the kit marks with the new thinking_cannot_be_disabled listed constraint, is refused rather than sent as a budget of 0 that Gemini answers with a 400; a project that copied the kit's anthropic.toml, bedrock.toml or google.toml gets the bounds by declaring them in its copy.
• Mistral reasoning is sent as reasoning_effort: a reasoning effort on a Mistral model is sent as reasoning_effort = "high", the only reasoning value Mistral's reasoning models accept, where it was sent as prompt_mode = "reasoning", which every current Mistral model refuses, so any reasoning effort on Mistral failed. The reasoning level of [inference.llm.mistral.effort_to_level_map] is unchanged.
• A model setting its model refuses is refused when the method loads (Breaking): a PipeLLM or PipeStructure whose model setting the model it resolves to cannot take, such as a reasoning setting on a model declaring thinking_mode = "none", a reasoning budget on an OpenAI or Mistral model, a thinking budget its max_tokens cannot hold, or a structured output on a Bedrock native model, is refused by pipelex validate, POST /v1/validate and a run's load as an item of the new PipeValidationErrorType value llm_setting_refused_by_model on its model or model_to_structure field, where it validated as runnable and failed at its first call. The check is the new check_request classmethod of the LLM workers, which LLMWorkerAbstract now runs before every provider call and which an LLM backend registers for validation through the new optional check_llm_request of PluginRegistrar.add_inference_backend, whose CheckLLMRequestFn, LLMJobParams and LLMCapabilityError the Inference SPI table publishes; a backend registering none, an external plugin's included, is held to the rule every worker shares, that a model declaring thinking_mode = "none" takes no reasoning setting. The item names the model by its deck handle and is shown even under strict error disclosure, so an external plugin's refusal is shown as written only when the plugin raises it as caller-facing copy with as_caller_fault(), and by its title otherwise.
• A structured output on Google without a system prompt no longer fails: a structured call on the google backend whose prompt has no system text failed with TypeError "generate_content() got an unexpected keyword argument 'system'", and is now sent with no system instruction.
• A model listing temperature_unsupported gets no temperature on any SDK: a model whose backend file lists the temperature_unsupported constraint is now called without a temperature on the OpenAI Responses, Google, Mistral and Bedrock-native SDKs too, where those sent one anyway and only the Anthropic and OpenAI chat-completions SDKs honoured the constraint. The model spec answers it as the new accepts_temperature property, and a Bedrock client's chat now takes temperature=None to send none.
• A binding step survives a kajson round trip: BindingStepBlueprint is encoded under from, the key it validates, where kajson wrote its field name from_path, which decoding refused as an extra field. A library crate holding a sequence with a binding step can now cross a process boundary, so a run of such a method no longer fails to start on a Temporal worker with "Could not instantiate pydantic BaseModel … BindingStepBlueprint".

[v0.76.0] - 2026-10-06

Added

• A run request carries the method packages its bundle calls (Breaking): a files or bundle_b64 request to /v1/execute or /v1/start may ship each package its bundle calls by address under .mthds/methods/<name>/ at its root, with its METHODS.toml, and the server searches them before its installed copies and fetch-on-miss, for that run alone, so a shipped package wins over an installed copy and runs with fetching off; a package fetched by method_ref that ships its own .mthds/methods/ is handled the same way. Those files no longer join the bundle's own .mthds content or its library directory, any other .mthds path in a bundle is refused with a 422 InvalidBundle naming the entry, as are two shipped packages declaring the same address and name without regard to case, and on a sandbox-hosted deployment a shipped package declaring a Python structure class is refused with 403 MethodStructuresRefusedError. The engine takes these directories as the new keyword-only methods_dirs of PipelexMTHDSProtocol, pipeline_run_setup, acquire_library and LibraryManagerAbstract.load_from_blueprints, which every implementation of the abstract must accept.
• The MTHDS Test Corpus covers a sequence step's multiplicity: the invalid entry invalid_input_stuff_spec_mismatch_step_multiplicity has a step read as a single Page the pages an earlier extraction stored as Page[], and fails with input_stuff_spec_mismatch; the valid offline entry controller_sequence_house_rules declares house_rules = "Markdown" for a sequence whose first step reads it as Markdown and whose second reads it as Text, and runs it.
• The MTHDS Test Corpus covers the markdown template filter: the new hand-maintained feature.markdown_filter tag names the filter of HTML templates that turns Markdown held in a plain text field into HTML, and the offline-tier entry feature_markdown_filter_cake_order_slip covers it with a PipeCompose run that pins its output, raw HTML in the source shown as text and only a URL with a scheme made a link.

Changed

• The documentation no longer describes the Pipelex Gateway: Configure AI Providers offers your own provider keys or a local model, says that the shipped defaults run as they are on OpenAI or Azure OpenAI and must be repointed for any other provider, OpenRouter included, and points to the Quick Start for running on the hosted API; the MTHDS language tutorial no longer runs pipelex login. The telemetry, logging, feature and under-the-hood pages describe only the telemetry streams you configure yourself and the backends the runtime ships, without the Gateway stream, its backend or its plugin.
• A call into a method package that cannot be resolved is a verdict item (Breaking): when a bundle names a pipe of another package by its address and the package is not installed and cannot be fetched (fetch-on-miss off, an address this runtime cannot fetch, a failed fetch), the load is refused with one item of the new PipeValidationErrorType value unresolved_package_dependency per package, on the first pipe naming it, with the reference as written in missing_pipe_code, where it raised MethodFetchDisabledError or MethodDependencyFetchError and the API answered a no-verdict 500. POST /v1/validate now answers 200 with is_valid: false and the run routes a 422, every package of the bundle is tried before the refusal, a failed clone's message no longer names the runner's temporary clone directory, and the remedies name no directory on the host and include shipping the package with the bundle under .mthds/methods/<name>/. The MTHDS Test Corpus covers it as invalid_unresolved_package_dependency.
• A package bundle that does not parse refuses the load (Breaking): when a bundle of a package the consumer calls by address does not parse, the load is refused with the parser's items, each naming the file as <address>/<path inside the package> and never by its path on the host, whether the package was shipped with the bundle, installed or fetched. It used to be skipped with a warning, so the caller learned of it from a later refusal about a pipe.

Fixed

• A validation message no longer names one concept as both required and provided: the (required: …, provided: …) suffix of a validation item is left off when the provided concept is among the required ones, since the disagreement then lies elsewhere, so a step reading one Page where an earlier step stored Page[] no longer ends its message with (required: native.Page, provided: native.Page).
• A provenance sidecar that is not UTF-8 no longer breaks method discovery: an installed or shipped method package whose .provenance.json is not valid UTF-8 is discovered with no recorded provenance, as one that does not parse already was, where discovery raised UnicodeDecodeError and a run calling the package answered a 500.
• A files entry holding a lone surrogate is refused as an invalid bundle: a name or a text in a run request's files map holding an escaped lone surrogate such as "\ud800", which JSON carries but UTF-8 cannot encode, is refused with a 422 InvalidBundle naming the entry, where the server answered a 500.
• A bundle naming one path twice is refused: a run request whose bundle holds two entries for one file, spelled differently in a files map (a/./b beside a/b) or twice in a zip, or a file that is also the directory of another entry, is refused with a 422 InvalidBundle naming the path, where the engine silently took the last copy of a file named twice and the server answered a 500 for a file that is also a directory.

[v0.75.0] - 2026-10-06

Added

• The binding step: a PipeSequence step { from = "invoice.total", result = "total_amount" } binds a deep copy of the value at a path in working memory to a new name, as a fresh stuff whose concept is derived from the declared structures the path walks, a path crossing a list binding one flattened X[], and a later step reads it under that plain name. The sequence checks a step reading a binding, or a binding ending it, against the derived concept and multiplicity, a path reaching nothing records an absence under the optionality model, and the execution graph draws each binding as a node of the new NodeKind binding. A malformed step is refused as the new PipeValidationErrorType value binding_step_invalid, which the MTHDS JSON Schema refuses too, and a path the declared structures cannot walk as binding_path_unresolved; the MTHDS Test Corpus covers both under the feature.binding_step tag, and its offline-tier entries now run with their inputs.json in the test suite.
• pipelex fix bundle deletes a dotted input key beside its root: the new rule delete-redundant-dotted-input removes a key such as "page.page_view" = "Image" from a pipe's inputs when the same table declares its root page, which already supplies every field a template reads through it. The fix is safe, and applied, only when the root's declared concept holds the field the key names and the root keeps the presence marker and multiplicity the table gave it: a root declared with a concept that lacks the field, such as data = "Number" beside "data.text" = "Text", or a key that set the markers otherwise, such as "data.text" = "Text!" declared after data = "Text?", gets an unsafe fix that pipelex fix bundle never applies, and both the fix and the refusal name what differs, with the edit that settles it on the root (here, replace ? with ! on data). A lone dotted key gets no automatic fix, since nothing states its root's concept, and its refusal names the two remedies instead.

Changed

• GraphAnalysis.stuff_producers lists every producer (Breaking): it maps a digest to a list of node ids, get_producer is replaced by get_producers, and the new shared_stuff_controllers names the controller a stuff with several writers belongs to, a parallel or batch controller combining or aggregating into the stuff counting as one of them. The Mermaid graph draws such a stuff once, inside that controller, with an edge from each producer.
• InferenceBackendLibrary.load takes credentials (Breaking): its lenient flag is replaced by credentials: CredentialResolution, REQUIRE or SKIP. A backend a SKIP load built records what it left unresolved in InferenceBackend.unresolved_credentials, and ModelManager.get_required_inference_backend refuses it with an InferenceBackendCredentialsError of type not_resolved_on_keyless_boot that names the variables.
• A routing profile naming a disabled backend is refused on every boot (Breaking): a boot without inference, such as pipelex validate, now refuses a routing profile whose default or routes name a backend that is not enabled, as a boot with inference already did, and load_active_routing_profile loses its lenient argument.
• A variable in a field that describes a model is refused on every boot (Breaking): a ${…} placeholder may stand only in a value a call sends, which means api_key, endpoint and a backend's extra keys, or a model's model_id, endpoint_path and request headers. A placeholder in a field such as model_type, sdk, thinking_mode or the constraints is now refused with an error naming the field, where a boot with inference substituted it and a boot without inference could not, so the two gave different verdicts.
• An unknown variable prefix is refused wherever it stands in a fallback chain (Breaking): ${env:KEY|secrte:KEY} is refused for its secrte prefix whether or not KEY is set, where a boot read the candidates in turn and accepted the chain whenever an earlier one resolved. A boot without inference, which resolves nothing, refuses it too, so a file gets the same verdict on its syntax on every boot and every machine.
• pipelex show backends lists every backend with its credential variables: a backend whose key is unset is listed instead of hidden, a new column names the variables each backend reads its credentials from, and an endpoint read from a variable is shown as not resolved.
• An input name is a plain name (Breaking): every key of a pipe's inputs, on every operator, controller and signature, and a PipeBatch's input_list_name must match [a-z][a-z0-9_]*, so a dotted name such as "invoice.total" = "Number" or a malformed one such as InvoiceTotal is refused when the bundle is parsed, as the new PipeValidationErrorType value invalid_input_name, which also replaces PipeJudge's own refusal that reached callers with no error_type. Its message names the remedies: declare the root with its whole concept (invoice = "Invoice") and read the field in the template ($invoice.total), which every operator handles by the concept the path reaches, so @page.page_view with page = "Page" is still attached as an image, or have the calling sequence bind the field with a binding step ({ from = "invoice.total", result = "total_amount" }). The generated MTHDS JSON Schema refuses the same names, through patternProperties on every inputs table and a pattern on input_list_name, and the corpus vocabulary records error.invalid_input_name with fails_at = "schema". The dotted-input fold goes with them: InputStuffSpecs no longer rewrites an input key to its root, NamedStuffSpec.requirement_expression is gone, pipelex.pipe_machinery.validation drops is_variable_satisfied_by_inputs, validate_input_name and the dotted_input_supplies_its_path argument of check_inputs_match_variables and check_variables_are_declared, in favour of validate_input_names and check_input_list_name, and build_judgment_material no longer walks a dotted input name as a path.
• A sequence's steps include binding steps (Breaking): PipeSequenceBlueprint.steps holds BindingStepBlueprint beside SubPipeBlueprint, and PipeSequence.sequential_sub_pipes holds BindingStep beside SubPipe, so code reading pipe or pipe_code off every step reads the new pipe_steps property instead. A PipeParallel's branches keep the pipe-step shape.
• Names a nested controller stores (Breaking): a name a nested sequence, a condition's outcomes or an add_each_output parallel always stores in the caller's memory counts as stored by the step calling it, so it is no input of the caller, and a sequence that declared such a name only to pass validation is now refused as extraneous_input_variable: remove the declaration. A nested sequence or condition skipped for an absent plain input now records an absence for every name it always stores, so a later step finds a value or an absence there, never nothing.
• Every sequence step is checked against what it reads (Breaking): validation follows a PipeSequence step by step and refuses, as input_stuff_spec_mismatch, a pipe step whose pipe reads a name as a concept or a multiplicity the value stored there does not have, whether the sequence declared it or an earlier step stored it, so a step reading cv_pages = "Page" where an extraction stored Page[] now fails before anything runs: declare Page[]. A declared input every step reading it accepts validates even when it differs from what the last one reads, so a sequence whose first step reads note as Markdown and a later one as Text declares note = "Markdown", which the sequence's inputs check used to refuse for not being the last step's Text, and that declaration is what the sequence needs from its caller, so a step calling it with a Text under note is refused. A step calling a nested controller is checked against the inputs the controller declares. A value a pipe step stores as Anything or Dynamic, as a condition whose outcomes produce different concepts declares its output, is assumed to be the concept a later step reads, its multiplicity still checked, while a sequence's own input declared Anything and a binding's value are checked as any other, also where a condition whose outcomes do not all store the name may leave them in place. A batched last step yields X[] whatever nb_output it asks for, so a sequence ending with one declares a variable list, where a fixed count or a single output used to pass. PipeLibraryAbstract and ConceptLibraryAbstract gain the abstract property state_token, which every change to a library replaces, so a sequence builds its typed flow once per state of the libraries it resolves in.
• A dotted batch_over is a binding followed by a batch (Breaking): a sequence step's batch_over = "catalog.pages" binds the list at that path under a private name, _bound_catalog_pages, by every rule of a binding step, then batches over it, so a list root such as catalogs.pages batches over the pages of every catalog, the sequence needs the root as its own concept, and the execution graph draws the binding feeding the batch. A path deriving a single value is refused before the run as input_stuff_spec_mismatch, as a batch over a value that is not a list is, and a path outside the path grammar, or a dotted batch_over on a PipeParallel branch, as binding_step_invalid, which the MTHDS JSON Schema refuses too. The file-format check before the run follows each item of the bound list back to where it sits, as it does after an explicit binding step, so a document at cases[1].transcripts[0] that the batched pipe's model cannot read is refused before the batch starts. The _bound_ prefix is reserved for these private names, since a nested sequence binds in its caller's working memory and would otherwise overwrite a caller's value stored under one: a pipe step's or a PipeParallel branch's result, batch_as or plain batch_over, or a PipeBatch's input_item_name, starting with _bound_ is refused as invalid_input_name, which the MTHDS JSON Schema refuses too.

Fixed

• A batched step's other inputs: a sequence now needs every input a batched step's pipe reads besides its item even when an earlier step stored the list, where it needed them only for a list the sequence received, so declaring one was refused as extraneous_input_variable and leaving it out failed the run inside the batch.
• A PipeBatch branch gets its own copy of its item: each branch's item is taken from the branch's own copy of the batched list, so a branch that rewrites its item in place, as a PipeFunc can, no longer changes the batch's input list.
• A dry-run condition's output is one stuff every outcome produces: in the graph of a dry run, every outcome of a PipeCondition now carries the condition's output digest, so the step reading the condition's result is wired to all of them rather than to the outcome whose pipe code sorts last, and when the outcomes write or declare different outputs, the condition's declared output types that stuff on every node outside the outcomes: the condition, the controllers whose output it is, such as a sequence ending on the condition, and the steps reading it, while each outcome keeps the concept it writes. Each outcome but the last now runs on a copy of the memory the condition received, so an outcome reading the condition's slot reads the value from before the condition rather than a sibling's output, and the default outcome runs last, so the steps after the condition read its value.
• Validation and dry runs no longer depend on which keys the machine holds: a boot without inference (Pipelex.make(needs_inference=False), used by pipelex validate, pipelex run --dry-run, pipelex show and the agent CLI's validation) now loads every enabled backend with its models and constraints and resolves none of their credentials, where it dropped every backend whose key was missing. A method using a search preset or pinning a bare handle such as model = "gpt-4o-mini" now validates on a machine or CI runner with no key, and such a boot no longer reads the backends' keys or requests a Vertex AI token.
• Linkup uses the key its backend names: the Linkup search and fetch workers take the key from the [linkup] table's api_key, like every other provider, where they read LINKUP_API_KEY themselves and ignored a configuration naming another variable. A Linkup backend with no api_key is refused with LinkupError when its worker is built.

[v0.74.1] - 2026-10-05

Added

• PIPELEX_HOME relocates the home configuration directory: when set and not empty, it names the directory Pipelex uses in place of ~/.pipelex, for the configuration layers, the inference files and their overrides, the credentials .env, the first-boot copy of the kit, pipelex init, pipelex doctor, pipelex update, pipelex migrate and the agent CLI's --global. It must be in the process environment before Pipelex is imported, a relative value is resolved against the working directory at import, and a PIPELEX_HOME line in a .env file is ignored. The first boot now fills the home directory from the kit when it exists but is empty, as it already did when it was missing, so an empty volume mount or a mktemp -d works as it is.

[v0.74.0] - 2026-10-05

Added

• A reference to a package's private pipe is refused as unexported: a consumer naming a pipe that a loaded dependency package declares but does not export is refused at load with the new PipeValidationErrorType value unexported_pipe_dependency, whose item names the referring pipe in pipe_code and the reference in missing_pipe_code.

Changed

• The hosted-only inference provider plugin is no longer shipped (Breaking): its built-in plugin, its sdk tokens, its error classes and their reference pages, and the PipelexBackend member naming its backend are removed, leaving PipelexBackend.INTERNAL alone. A project config that still declares the hosted backend disabled, or a routing profile that names it but is not active, keeps booting; a model spec naming one of its sdk tokens now fails when its worker is built, unless a plugin of your own registers that token.

Fixed

• A dependency package's pipes call their own sub-pipes: a sequence, parallel, condition or batch inside an installed package now reaches the package's own pipe, stored as alias->domain.code, where it used to look the plain domain.code up in the consumer's library. A package whose controllers call its own pipes, such as github.com/Pipelex/methods/documents from 0.1.3, no longer fails to load with PipeNotFoundError, and a consumer pipe of the same domain and code is no longer run in the package's place.
• An exported pipe can call its package's private pipes (Breaking): a package with [exports] loads every pipe its exported pipes and main_pipes reach, not the exported ones alone, and a private pipe nothing public reaches is not built. Exports are read by domain, so exporting x from one domain no longer exports a pipe named x in another, and PipeLibrary.add_dependency_pipe takes is_exported.
• A missing pipe of a loaded package is refused at load: a reference to a pipe a loaded dependency package does not have is refused as unresolved_pipe_dependency, naming the package, where it was skipped and reported as an extraneous input with a wrong suggested fix. A dependency's own reference to another package is not checked against the consumer's packages, since a dependency's dependencies are not loaded.
• A pipe wrapping another package's pipe of the same domain and code reports its inputs: the recursion guards of the needed-inputs, signature and file-input walks tell two pipes of the same domain.code apart by object rather than by pipe_ref. A consumer pipe calling a dependency's pipe of its own domain and code, or one package's pipe calling another's, was taken for an already-visited pipe and reported no inputs, so a correct bundle was refused with an extraneous-input error.
• A bare reference into a package ignores its private pipes when an exported one matches: a consumer's alias->code that matches an exported pipe and a private pipe of the same code in another domain resolves to the exported one, where it was refused as ambiguous.
• A dependency pipe that fails to build is refused naming why: a reference to a pipe the package declares but could not build, such as a PipeFunc naming an unregistered function, is refused with that build error, where it was reported as a pipe the package does not have. A bare alias->code matching such a pipe is refused the same way, rather than resolved to another pipe of that code.

[v0.73.0] - 2026-10-05

Added

• Service error codes, contributed by the plugin that speaks to the service: a plugin declares each error code its gateway or hosted service emits on its own as a ServiceErrorCode, with its category, its user action, its advice and whether it means an unknown model, and hands them to PluginRegistrar.add_service_error_codes. classify_inference_error consults the booted plugins' codes ahead of the HTTP status ladder and render_inference_error renders the matched entry's advice; a code two plugins contribute fails the boot with DuplicateServiceErrorCodeError, and one the runtime classifies itself with ReservedServiceErrorCodeError.
• Request extras on the Anthropic worker: AnthropicLLMWorker takes an optional extras_factory, the BackendExtrasFactory the OpenAI-substrate workers already take, whose headers and body additions join every text and structured call, and AnthropicFactory.make_anthropic_client takes an sdk_variant, so a plugin can register an sdk token of its own over the Anthropic protocol.

Changed

• The completions image worker's fixed output format comes from its registration: OpenAICompletionsImgGenWorker takes fixed_output_format, the one image format a service answers in, rather than inferring it from the backend's name; a request for another format is refused before the call, and a URL answer from a worker built without one is refused as unreadable.
• The Inference SPI table lists every symbol a provider plugin builds on: docs/under-the-hood/inference-backend-plugins.md now publishes, one module per row, the worker contracts with their jobs and outputs, the OpenAI- and Anthropic-protocol factories and workers, the image-generation and prompt-preparation helpers, the error pipeline and the runtime accessors, and parse_retry_after_seconds and error_code_from_body_code_first become public in pipelex.cogt.inference.error_classification for a plugin that distils a plain-HTTP failure itself.
• The Anthropic worker no longer adds a backend's headers by backend name (Breaking): a worker built without an extras_factory sends nothing extra, whatever its backend, so a backend that relied on the worker adding its request headers must register its own sdk token with an extras factory and name that token in the sdk of its model specs, local overrides included; a model left on anthropic keeps answering, without those headers.
• The gateway refusal families leave the core classifier (Breaking): GatewayRequestLimit, GatewayUnresolvedReference and GatewayRoutingRefusal, the matching properties of ProviderErrorMetadata and fields of ClassificationResult, and MANAGED_GATEWAY_BACKEND_NAMES are removed; a gateway's own codes now reach ClassificationResult.service_error_code through the plugin that contributes them, and Portkey's model_not_allowed_error is read by ProviderErrorMetadata.is_model_not_allowed and ClassificationResult.is_model_not_allowed. Errors raised by the hosted-only provider plugin now report the type and title of their generic family, such as extract-job-failure-error, rather than pages and titles of their own.
• The default extractors run on your own keys (Breaking): @default-extract-document takes the first of Mistral OCR and pypdfium2-extract-pdf that an enabled backend serves, and @default-extract-image and @default-premium take Mistral OCR, where all three named Azure Document Intelligence, which no shipped backend serves any more. A PipeExtract step naming no model therefore runs on Mistral OCR with your own key or, for a PDF, on its text layer read locally, which recovers no text from a scanned page; a project's managed 3_extract_deck.toml takes the new aliases with pipelex update.

Fixed

• A Manifold failure on the extract and search routes reports the service's own message: extract_manifold_metadata takes the message from the response body's error.message, or else its top-level message, so a refused key now reads Portkey Error: Invalid API Key. Error Code: 03 rather than httpx's Client error '401 Unauthorized' for url …; a body carrying neither, a body that is not JSON and a network failure keep the exception's own text. Because the quota check reads that message, a 429 on those routes whose body names a quota, such as Monthly quota exceeded, now classifies as quota exhaustion, to be fixed in billing, rather than as a transient rate limit to retry.
• A kernel-only boot over a stale configuration file stays kernel-only (Breaking): the boot-tolerance replay no longer loads interpreter modules into a RuntimeBoot process, because the fix-op applier, the file transaction and their errors moved from pipelex.pipeline to the new kernel-layer pipelex.fix_ops package; import FixWriteConflictError and FixTransactionError from pipelex.fix_ops.exceptions, and the applier and transaction from pipelex.fix_ops.applier and pipelex.fix_ops.file_transaction.

Removed

• The builder: pipelex-agent concept, pipelex-agent pipe, pipelex build runner and pipelex.builder (Breaking): the two agent commands that converted a JSON concept or pipe spec into MTHDS TOML, and pipelex build runner bundle and pipelex build runner method, which wrote a Python script running a pipe, are gone with the spec layer behind them, ConceptSpec, PipeSpec, PipelexBundleSpec and the ConceptSpecError, PipeSpecError and PipelexBundleSpecBlueprintError classes; write a method in MTHDS directly and check it with pipelex validate, and take a runner's typed structures from pipelex build structures or pipelex codegen types --target python-structures. The pipelex.builder package no longer exists: the modules the runtime still uses moved, pipelex.builder.conventions to pipelex.pipeline.default_file_names, pipelex.builder.operations.models_ops to pipelex.cogt.models.model_listing and pipelex.builder.operations.inputs_ops to pipelex.pipeline.inputs_template, and the others are deleted with the helpers only they used, force_include_dirs on pipelex.tools.misc.file_utils.find_files_in_dir among them, which only forced the builder package into library loading. The circular_dependency_error validation error type, which only the spec layer's pipe sorter raised, leaves the error_type registry and the API server's OpenAPI schema.
• The Pipelex Gateway backend is gone from the runtime (Breaking): pipelex_gateway leaves the shipped backends.toml, its backends/pipelex_gateway.toml override file and the generated pipelex_gateway_models*.md references leave the kit, the all_pipelex_gateway routing profile is gone, and the pipelex-gateway provider plugin is deleted along with its gateway_* SDKs, its error classes and their docs pages. A backends.toml that still enables a [pipelex_gateway] table, as the previous release's kit did, is refused at boot, because an enabled backend whose file declares no model is now an error rather than a backend every routed model silently goes missing from: disable or remove the table, and move a routing profile naming it, the previous default all_pipelex_gateway included, to another backend. The shipped default routing profile is now all_enabled_backends, which needs no Pipelex account: it sends each model to the first enabled backend that serves it, in the order its fallback_order lists. pipelex init pre-selects OpenAI, whose one key serves every default language-model and image-generation tier of the shipped model deck, and no longer sets all_pipelex_gateway when several backends are chosen; pipelex-agent init given no backend list keeps the template's routing profile rather than demanding a primary_backend. The pipelex/pipelex-api image enables openai in its place and boots on OPENAI_API_KEY, which serves every default language-model and image-generation tier of its deck. Every bring-your-own-keys backend is untouched.
• The Gateway terms of service and the first-run check are gone (Breaking): GatewayTermsNotAcceptedError, the [agreement] section of pipelex_service.toml, pipelex init agreement and the pipelex-agent accept-gateway-terms command are removed, and pipelex-agent init no longer reads accept_gateway_terms from its config. The check that stopped a live run on a Pipelex-managed backend until inference setup had been recorded is removed as well, with InferenceSetupRequiredError, its CLI handling and IntegrationMode.requires_terms_acceptance, so a server, a container or a test suite boots with no setup recorded at all.
• The Pipelex-owned telemetry stream is gone (Breaking): the runtime no longer reports to Pipelex's PostHog on the Gateway's behalf, so GatewayApiKeyMissingError, GatewayDoNotTrackConflictError, GatewayTelemetryManagerInjectedError, TelemetryManagerAbstract.is_pipelex_telemetry_enabled, IntegrationMode.is_test_harness and the maintainer-only [pipelex_gateway] section of telemetry.toml (with its is_pipelex_gateway_portkey_* knobs) are removed; TelemetryFactory.make_telemetry_manager and TelemetryManager take only the user's telemetry_config. The user's own opt-in telemetry under [custom_posthog], [langfuse] and [[otlp]] is untouched. Migration: run pipelex migrate; ledger entry telemetry-config@3 deletes the [pipelex_gateway] table from every telemetry.toml and telemetry_*.toml file in ~/.pipelex/ and in each project .pipelex/, keeping one timestamped backup per file. Nothing else needs deciding, since the section only ever configured the stream that no longer exists.
• pipelex login is gone (Breaking): it wrote a PIPELEX_GATEWAY_API_KEY that nothing reads any more, and it also leaves _CORE_COMMAND_ORDER and the setup-command set that skips the readiness check — an order list naming a command the CLI does not register makes pipelex --help itself exit non-zero. The credential flow for the hosted service is rebuilt separately.
• The check-gateway-models and update-gateway-models dev commands are gone, with their make ugm / make cgm aliases and the ticc config-coverage target that ran the Gateway's Portkey configs.
• The runtime no longer downloads a remote config, and the hosted-only inference backend is no longer shipped (Breaking): the boot fetches nothing, so PIPELEX_REMOTE_CONFIG_URL, the ~/.pipelex/cache/remote_config.json cache, the cache priming in pipelex init and pipelex-agent init, the remote fetch in pipelex doctor and make regenerate-test-models, and the RemoteConfigFetchError, RemoteConfigValidationError, RemoteConfigUnavailableError, GatewayUnknownModelError and GatewayConfigMergeError classes are gone, with the warnings array the agent CLI added to a success envelope for a stale cache. Every backend now reads its model specs from its own file under inference/backends/, so model_specs_section is no longer a backend setting, and the kit no longer ships the hosted-only backend's backends.toml table, its file under inference/backends/ or the routing profile that sent every model to it; a project config that still declares them keeps booting while that backend is disabled, since a disabled backend is skipped and only the active routing profile loads. An enabled backend whose backends.toml table still carries model_specs_section is refused at boot, naming the key: list its models in its backends/<name>.toml and remove the key, or disable it. pipelex_service.toml is retired with its PipelexServiceConfig and PipelexServiceError classes: pipelex-agent init no longer writes it or reports inference_setup_completed, cache_primed or cache_priming_error, and a copy an earlier release left behind is ignored, by pipelex migrate too. The needs_model_specs argument of Pipelex.make, which only chose whether to fetch, is removed.

[v0.72.0] - 2026-10-04

Highlights

PipeJudge brings judgment into MTHDS methods: a step asks a model one closed question about its inputs and gets back a typed verdict with the probabilities behind it. A yes/no question returns a YesNo, a choice among declared options returns a Choice, and a position on a declared scale returns a Rating, so a PipeCondition can route on the verdict or gate a step on how sure the model was.

TypeSafe's Jev is the first judgment model Pipelex runs. Jev answers closed questions with calibrated probabilities rather than free text: install pipelex[typesafe], set TYPESAFE_API_KEY and name @default-judgment in the step.

Added

• PipeJudge, an operator asking a judgment model one closed question about its inputs: a step declaring neither options nor levels asks a yes/no question, which may carry criteria and a threshold, and outputs a YesNo; one declaring options outputs a Choice; one declaring levels outputs a Rating, each verdict carrying the probabilities the model measured. Every declared input is sent to the model as material whether or not the question reads it, and prompt is read as a synonym of question. A step is refused when the method loads if it names no model while the deck names no default for judgments, if its output disagrees with its kind of question (Dynamic included), if an input name reaches into a field with a dot, or if it has an image or a document input its model does not read, and a document a run is given in a format its model does not read is refused before the run starts. The builder and pipelex-agent pipe write it with question, and the MTHDS Test Corpus gains operator_judge_urgent_message and the operator.judge tag.
• A judgment inference family: a new family beside llm, img_gen, extract, search and doc_gen, for models that answer a closed-form question over some material — yes or no, one option out of a declared set, or a position on a declared scale — and report how sure they are. The worker contract is batch-shaped (one state, a map of questions, a map of answers), every measure of uncertainty is optional so a backend that measures none can still serve the family honestly, and usage is reported as real input and output tokens priced per million. A JudgmentJob and its JudgmentAssignment carry images and documents keyed by input name, which a scoped run's read authorization sees, and a judgment worker refuses files its model does not read with JudgmentCapabilityError before calling the provider. The deck gains a [judgment] section in a new managed file, 6_judgment_deck.toml, which pipelex update installs, and a deck installed before it keeps loading with no judgment model; it ships with no choice_default, because the family's models come with your own key and a default the Pipelex Gateway does not serve would fail every boot, so a judgment names its own model. pipelex-agent models lists the new category, and so does the MTHDS protocol's model list, GET /v1/models on the API server, where a judgment preset is an entry typed judgment and ?type=judgment filters on it; a judgment pytest marker joins the inference markers.
• TypeSafe, the judgment family's first backend: a built-in typesafe plugin, installed with the new pipelex[typesafe] extra, serves the family from TypeSafe's System One API and is reachable as @default-judgment, pinned to the versioned model jev-1.13.0. Set TYPESAFE_API_KEY to use it: the default routing profile sends jev-* models to the backend whenever it is enabled, because the Pipelex Gateway does not serve them. A rating scale longer than ten levels is refused by this backend before any request is made, and a response answered by a model other than the pinned one is reported as a warning.
• Log sink settings can name secrets: the values of headers under [runtime.log.otlp] and credentials_file_path under [runtime.log.gcp] accept the ${…} placeholders the inference backends use, resolved through the configured secrets provider, so a collector's token is written "Bearer ${OTLP_AUTH_TOKEN}" and the key path "${GCP_CREDENTIALS_FILE_PATH}". The configuration keeps the placeholders, and one that does not resolve stops the boot with LogSinkVariableError naming the section, the key and the variable. A header value that holds a line break once resolved, as a secret read from a file often does, stops the boot with LogSinkHeaderValueError rather than installing an exporter that refuses every batch. pipelex doctor gains a Secrets Provider row, checks.secrets_provider in pipelex-agent doctor.

Changed

• mthds version, MTHDS protocol 0.7.0 and standard 3.0.0 (Breaking): the pin moves to mthds==0.19.0, which carries protocol 0.7.0, whose model list adds the judgment category beside llm, extract, img_gen and search, so the runner and GET /v1/version report protocol_version 0.7.0, and which implements MTHDS standard 3.0.0. A crate pipelex normalizes is stamped mthds_version 3.0.0, and a METHODS.toml declaring mthds_version = "^2.0.0" now warns that the engine does not satisfy it. PipelexModelDeck inherits the release's open ModelInfo.type, typed ModelCategory | str | None, though pipelex itself only ever emits a protocol category; everyone downstream inherits that exact mthds.
• The native concepts are pinned at MTHDS 3.0.0: YesNo gains a probability, and Choice and Rating are added (Breaking): YesNo carries an optional probability, which a PipeLLM whose output is YesNo may fill with the model's own estimate; Choice (an option key, with optional confidence and probabilities) and Rating (a level index, with optional confidence, probabilities and position) are new natives, so a bundle declaring a concept named Choice or Rating must rename it. A YesNo written to the wire carries "probability": null when none was reported, the output-form descriptor states a YesNo result as an object carrying yes_no and probability while an input stays a bare boolean, and a crate's normalized fingerprint changes wherever it materializes YesNo. Python callers read the new verdicts with main_stuff_as_choice and main_stuff_as_rating. Every measure is a strict number, so a boolean or a numeric string is refused rather than read as 1.0 or 0.9; and a PipeDocGen office template or auto-layout sees a verdict as its verdict alone, while a pdf template reads it whole.
• The method-app template and the SDK references link Pipelex/pipelex-sdk: the SDKs and the method-app templates now live in the Pipelex/pipelex-sdk repository, so the README and the documentation's Quick Start link the method-app template to its method-apps/ directory, the webapp's by-hand commands clone it and copy method-apps/webapp-js/, and the @pipelex/sdk and pipelex-sdk references point at its js/docs/ and python/docs/ directories.
• Boot builds the secrets provider before the log sink, and a sink factory receives it (Breaking): a LogSinkFactoryFn is now called as factory(log_config, secrets_provider=…), and the plugin API version moves to 5, so a plugin declaring targets_api = 4 is refused at discovery and is rebuilt against this release. A secrets provider that fails to build now reports on stderr, redacted, rather than through the configured sink.
• pipelex-agent inputs names the pipe pipe_ref, qualified (Breaking): the JSON success envelope of inputs bundle, inputs pipe and inputs method is {success, pipe_ref, inputs}, as mthds-agent prints on the API runner, where it was pipe_code. The value is the qualified domain.pipe_code of the pipe that was resolved, so a bare --pipe summarize answers doc.summarize and a dependency pipe keeps its alias-> prefix, and a pipe that declares no inputs names its pipe too, where it printed null when --pipe was omitted, and no longer adds a message key. That pipe's message, the TOML comment here and the line pipelex build inputs and pipelex codegen inputs print, now reads Pipe '<pipe_ref>' declares no inputs.

Fixed

• An image worker refusing a model's spec reports a configuration fault: a worker refused a model with no rules, no model_choice or endpoint_path where it needs one, or on the Google Gemini paths an aspect_ratio taxonomy that is missing, unknown to this release or of another family, with ImgGenParameterError in the content category, so a server answered 422 and told the caller to change their input; and a rule value this release does not know escaped the OpenAI, Azure, fal, Hugging Face and gateway image workers as a bare ValueError. Each now raises ImgGenParameterError in the configuration category, naming the model, and answers 500, while a ratio or size the model's grid refuses is still the caller's 422.
• A bare value is refused where it reads as a concept the input does not accept (Breaking): an input declared as a container native (Html, Page, TextAndImages, SearchResult, Composite), as Choice or Rating, or as a concept refining one, built a bare string as a native.Text and handed that text on, so the step reading the input met a text where it declared another concept. The value is now refused with StructureValidationError naming the concept it read as; send it in its {concept, content} envelope. The concept's own content sent without that envelope, such as {"choice": "billing"}, is refused with the same advice, where it was told to redeclare the input as JSON, and so is a bare number or boolean at a Rating or Choice input, such as a level 2 sent alone, where it was told to redeclare the input as Anything. A Dynamic input still keeps whatever its value reads as.
• A name a template sets is read where Jinja binds it (Breaking): the input check of PipeLLM, PipeCompose, PipeSearch, PipeImgGen and PipeDocGen, PipeDocGen's field check and the optional-input guard now treat a {% set %} name as the template's own inside the loop, macro or block that sets it and after an {% if %} every branch of which sets it, so a template setting a name in a loop body or in each branch of an if and reading it there is no longer refused as reading an undeclared input. A name only some branches set is still read from the input of that name. Newly refused: an input declared only so that such a set would load, which is now never read, a macro called before its {% macro %}, an optional input read unguarded in a macro argument's default, and a name a loop or a macro binds read inside a {% block %} without scoped, which Jinja reads from the input of that name.
• File inputs are checked against the models that read them (Breaking): run setup now identifies every image and document input from its first bytes, refuses an Image input holding something other than an image with PipelineInputNotAnImageError, and refuses a document certain to reach a PipeExtract or PipeLLM step whose model does not read its format with PipelineInputFormatUnsupportedError, both 422 input errors naming the input, the step, the model and the formats it reads; a step reached only through a condition refuses the file itself with ExtractInputFormatError or PromptDocumentFormatError. A PipeLLM document its model does not read now raises PromptDocumentFormatError where it raised LLMCapabilityError, so a consumer branching on error_type must follow. docling-extract-text now declares the Word, PowerPoint, Excel, HTML, Markdown, CSV, plain-text, WebVTT and email files it already extracted, which pipelex update installs.
• Markdown with unclosed emphasis is converted in memory proportional to its length: the Markdown parser behind the markdown filter, the Markdown concept's HTML and the built-in PDF engine held memory growing with the square of the text when emphasis or strikethrough markers were left unmatched, about 1.5 GB for 64,000 characters of **a; it now joins the text they leave behind in one pass, and renders the same HTML.
• Routing profiles no longer rewrite their own routes: matching a model merged the enabled optional_routes into the profile's declared routes in place, so after the first match a route declared optional had become an unconditional one in the loaded profile. Only the enablement checks each match repeats kept that from changing a routing decision.
• The logging documentation no longer promises that a server refuses the console sink: the log-sink, logging, logging-configuration and Rich-imports pages said a server installed without the cli extra stops at boot when it selects the console sink or the rich pretty-print mode. The core dependencies typer and instructor install Rich anyway, so such a server boots on the Rich surface; the pages now say a server selects json and a Rich-free mode in its own configuration, since nothing at boot makes that choice for it.
• pipelex doctor checks the backends against the configured secrets provider: the backend-file probe and the Models row resolved credentials from environment variables whatever [runtime.secrets] method selected, so a deployment on another secrets method was diagnosed against secrets it does not use. Both now use the provider the configuration selects, and say they could not run when it does not build; a provider that raises on a lookup, an unreachable vault or a missing SDK, is reported in the Models row rather than stopping the doctor.

Removed

• The API server's /v1/build/* routes (Breaking): pipelex-api no longer serves POST /v1/build/inputs, /v1/build/output, /v1/build/runner, /v1/build/concept or /v1/build/pipe-spec, which now answer 404, and the MAX_AGENT_SPEC_KIB setting that bounded the last two is gone. A client reads a pipe's I/O from POST /v1/pipe-io and projects an inputs template from its input_form with the mthds packages' projection (renderInputsTemplate, which @pipelex/sdk re-exports, or mthds.protocol.inputs_template in Python), as mthds-agent inputs does; the output representation, the runner script and the concept and pipe spec conversions have no HTTP replacement.

Security

• Every template render spends from a budget (Breaking): a render is charged for what it reads, allocates and prints, and an operation that would overdraw its budget, such as 'x' * 10 ** 9, a huge format width, lipsum(n=10 ** 9), nested empty loops or a runaway recursive macro, is refused before it allocates and raises Jinja2TemplateBudgetError. Converting Markdown to HTML, with the markdown filter or by printing a Markdown value in an HTML template, is charged for every character and table cell of its source, so one render converts at most about 65,000 characters of Markdown. Template arithmetic stops at 64-bit integers, and a template can no longer call str.encode or int.to_bytes. A filter or test registered on a template environment needs a cost in the render budget's tables, or the first compile raises a TypeError naming it, and Pipelex now requires jinja2 below 3.2.
• pipelex doctor redacts the failures its rows quote: the log-sink row printed a sink's failure as raised, so a credential an exporter or a client quoted in its error reached the terminal and the JSON of pipelex-agent doctor. That row, the new Secrets Provider row and the Models row, which quotes a secrets provider's own text when a backend's credential does not resolve, now scrub the text with the patterns the log redaction uses, the configured extra_patterns included.

[v0.71.1] - 2026-10-01

Fixed

• A symlink in a fetched package is a 422 on the API server: MethodPackageSymlinkError, raised when a package fetched by method_ref carries a symlink, is now answered as a 422 the method's author can act on, where it was a 500 server fault.

Security

• Locating a fetched package never follows a symlinked METHODS.toml: when pipelex run <address>, fetch-on-miss or the API server's method_ref scans a fetched repository for its packages, a METHODS.toml that is a symlink, or is not a regular file, is now skipped and reported without being opened. A repository could commit one linking to a file on the fetching machine and get that file's values back in the error message, even under strict error disclosure, or link it to /dev/zero and make the read run without end. The read now also stops at the manifest size ceiling whatever size the file reports, and a manifest that is not valid UTF-8, or a directory named METHODS.toml, is skipped and reported instead of failing the whole fetch.

[v0.71.0] - 2026-10-01

Highlights

The Pipelex API server and its pipelex/pipelex-api image now ship from the pipelex repository, so they take pipelex's version number. The image's last standalone release was 0.33.2, on the server's own release line, and its next tag is 0.71.0, the same version as the pipelex and pipelex-api packages published beside it.

Added

• PipeDocGen generates a document file: a new operator turns its inputs into a stored Document named by its filename expression, which pipelex run copies into the run's results folder. A pdf without a template is printed by a built-in engine on ReportLab from the auto-layout of the inputs, and a pdf with an HTML template or any xlsx, docx or pptx step is refused when the method loads, with an error naming the Pipelex document generation plugin. A template's field paths are checked against the inputs' concepts at load, and its templates and filename render strictly, so a missing value fails instead of printing as empty text.
• Document engines are models: the engine that prints a PipeDocGen step is a model of a new doc_gen family, which a step names with model = "pipelex-pdf" or leaves to the default for its format and source in the new deck file 5_doc_gen_deck.toml, and whose worker a plugin registers with add_inference_backend(family=InferenceFamily.DOC_GEN, …), declaring its model with add_internal_model and its deck defaults with add_doc_gen_default. A step whose engine is not in the deck, does not print its format from its source, or has no installed worker is refused when the method loads, so a runtime that disables the built-in reportlab plugin in [runtime.plugins] disabled refuses every PipeDocGen step. An engine receives a RenderJob of plain data, reads the files its document names through RenderResources under the run's read scope, and may check a step's template file at the dry run. pipelex update now also refreshes backends/internal.toml, backing up a locally edited copy first, so run it to get the deck file and the built-in reportlab-pdf engine.
• The markdown template filter: an HTML template turns Markdown held in a text field into HTML with {{ order.notes | markdown }}. Raw HTML in the source is shown as text, and only URLs with a scheme become links.
• The Markdown native concept: Markdown refines Text and holds a text written in Markdown, which a PipeLLM with output = "Markdown" writes as free text and a Markdown input takes as a string or as {"concept": "Markdown", "content": "…"}; Pipelex defines it ahead of the MTHDS standard. A Markdown value is accepted wherever a Text is, while a Text, or any concept refining Text, is refused where a Markdown is required. pipelex run --save-main-stuff saves it verbatim as main_stuff.md, an HTML template prints {{ report }} and $report as HTML with raw HTML escaped, and Stuff.as_markdown and PipeOutput.main_stuff_as_markdown read it from Python.
• The Pipelex API server ships with pipelex: the FastAPI runner now lives in the api/ directory, as the pipelex-api member of a uv workspace, and runs the pipelex of the same commit instead of a pinned release. Every release publishes it under pipelex's version, as the new pipelex-api package on PyPI, which pins pipelex to that same version, and as the pipelex/pipelex-api image on Docker Hub, whose tag therefore jumps from 0.33.2, the server's last release on its own, to this version. The image keeps its name, its port and its /root/.pipelex configuration mount, and Pipelex/pipelex-api keeps the server's earlier history.
• x-pipelex-metadata header on Pipelex Manifold calls: every inference request the Manifold backend makes (chat completions, responses, image generation, extraction, search, and Claude over the Anthropic SDK) carries one JSON header holding the run's extras as they are, plus the run's user_id and pipeline_run_id and the step's pipe_run_id, pipe_code and content_generation_job_id when set, so the service can attribute each call's spend and log it. On a key collision the run's own id wins over the extras entry, and no other backend receives the header.

Changed

• Markdown is a reserved native concept code (Breaking): a bundle declaring its own concept named Markdown is refused with native_concept_redeclaration; rename it, or use the native.
• A string under a concept refining Text keeps the concept's class: a bare string or a {"concept": …, "content": "…"} envelope for such a concept now holds the concept's own content class where it held a plain TextContent, as the YesNo, Date and Time envelopes already did.
• markdown-it-py replaces markdown in the dependencies: the markdown package, which pipelex no longer imported, is dropped, and markdown-it-py with its linkify extra renders the Markdown of PipeDocGen, the markdown filter and the Markdown concept.
• The API server's import package is pipelex_api (Breaking): the server's package api is renamed pipelex_api, so an application wrapping the server imports pipelex_api.main and serves pipelex_api.main:app, and the logger field of the server's log records reads pipelex_api.….
• The API server's documentation is part of docs.pipelex.com: its pages are the API Server section of the Pipelex documentation, versioned with each release, in place of the separate site at pipelex.github.io/pipelex-api, and the committed OpenAPI artifact is published beside them as api-server/openapi/pipelex-api.openapi.yaml.
• The API image is built from the pipelex repository: docker build -f api/Dockerfile . at the repository root installs pipelex and pipelex-api from that commit, with the dependency versions of the repository's lock, which moves some provider SDKs to the versions pipelex is tested with. The container starts uvicorn from its virtual environment rather than through uv run, and carries no uv.

Fixed

• The API server refuses a deeply nested body the same way on every Python: a JSON request body whose arrays and objects nest deeper than 128 levels, its own envelope included, is now refused before it is parsed, on every route that takes one, with a 422 InvalidJSON saying it is nested too deeply. On Python 3.14 whether the run routes refused such a body depended on the size of the thread's stack, so it could reach validation and fail as a ValidationError or be accepted, and the other routes answered it with a bare 400 rather than a problem document.
• A client leaving mid-upload is a 400 in the API server's logs: when a client disconnects before its request body arrived in full, the server answers a 400 BadRequest and logs it at warning level, where the run routes logged a 500 server fault with a traceback.
• The API image runs methods by address: the image carries git, which fetching a method named by method_ref needs, where the 0.33.2 image removed it with the build tools and failed every such run.
• A workflow action the organization does not allow is caught on its pull request: GitHub rejects a whole workflow at startup when one of its actions is outside the organization's Actions policy, and pull-request CI never loads the release workflows, so such an action surfaced only as a release that published nothing. make check-actions-allowlist (alias caa), which make agent-check and the Lint (actions allowlist) CI job run, now refuses any workflow action outside the policy mirrored in .github/actions-allowlist.toml; see Actions Allowlist.

[v0.70.0] - 2026-09-29

Highlights

This release hardens pipelex for running methods it did not write. Every template now renders in Jinja's sandbox, a run with a read scope reads only under that scope and never the local disk, a URL fetch refuses private and metadata addresses, and a sandbox-hosted load no longer imports a method's Python into the loading process. Validation gets stricter too: PipeCompose, PipeSearch and PipeImgGen refuse an input their templates never read, and a concept whose field names a concept nobody declares is refused at load.

Changed

• read_scope is a required run parameter (Breaking): RunMetadata, pipeline_run_setup, prepare_pipe_job, PipelexKernel.make, shape_inputs, InputShaper.shape, WorkingMemoryFactory.make_from_pipeline_inputs, StuffFactory.make_stuff_from_stuff_content_or_data, normalize_data_urls_to_storage and the runtime bridge's PipelexPipeRunInput take a read_scope with no default: a host serving several tenants passes the tenant's prefix, which must contain the run's storage_scope, and None states that the run is unscoped. PipelexMTHDSProtocol defaults it to None, which is the truth on a laptop.
• Dry-run mocks of images and documents carry readable URLs: a mocked ImageContent carries one of inference.dry_run.image_urls and a mocked DocumentContent a blank one-page PDF as a data: URL, where both carried a random string that reads as a local path; and a model nested two levels or more inside a mocked structure now gets the same field providers as a shallower one.
• A structure field naming a concept that cannot be found refuses the load (Breaking): a concept whose field names a concept that no bundle it can see declares now raises LibraryLoadingError at load, naming the concept, its bundle and the missing structure class, where it loaded and failed with pydantic's "not fully defined" error at first use. A concept declared only by a bundle loaded afterwards cannot be found either. load_from_crate does not refuse, since a crate carries no dependency package, and neither does a method package's own load, since its own dependencies are never loaded; a concept holding a method package's concept left incomplete that way is not refused either.
• PipeCompose, PipeSearch and PipeImgGen refuse an input they never read (Breaking): as PipeLLM already did, validation refuses a declared input that none of the pipe's templates reads (the template or the construct of a PipeCompose, the prompt of a PipeSearch, the prompt or negative prompt of a PipeImgGen) as extraneous_input_variable, naming the input: reference it in a template, or remove it from inputs. A variable a PipeImgGen's negative_prompt reads without declaring it is refused when the bundle is parsed, and UnusedInputError, which nothing raised, is removed.

Fixed

• Concepts holding other concepts are complete: a method package's concept holding another of the package's concepts, a field typed by a method package's concept (address->domain.Concept), a field typed by a concept that an earlier load put into the same library, a field typed by a concept backed by a Python class (structure = "ClassName"), and a field typed native.Anything, which holds any value, now resolve, where each loaded and failed with pydantic's "not fully defined" error at first use. A method package whose concepts form a cycle is refused as a bundle's own concepts are, naming the package's bundle.
• The input errors of the template operators carry their type and names: a missing or unread input of a PipeLLM, PipeCompose, PipeSearch or PipeImgGen is reported with its error_type and with variable_names holding the plain names, sorted. A PipeCompose template reading an undeclared variable was an uncategorized item, the PipeSearch and PipeImgGen items carried no names, and PipeLLM's unread names arrived quoted ('platform').
• A template read through a subscript, a call or a set counts as a read: an input a template reads only as {{ items[0].text }}, {{ (items|first).text }} or {{ record['meta'].title }}, or reassigns with {% set topic = topic|trim %}, is seen as read, where PipeLLM refused it as unread, and such a read of an undeclared variable is refused as missing. A read placed before a top-level {% set %} of the same name, and a for loop's iterable or else branch, read the input. The name a top-level {% set %}…{% endset %} block assigns, a call to one of Jinja's globals such as range(count) or namespace(), and caller, varargs and kwargs inside a macro are no longer demanded as inputs, while an input named like a global, such as range, is read wherever the template reads the name without calling it. The images and documents PipeLLM attaches, and the reference images PipeImgGen attaches, are found under the same scopes, so an image read after {% set image = image %} or as the iterable of a loop named after it is attached.
• A generated object's storage key names its own format: the extension of a key under generated/ follows the whole MIME type the object is stored under, so a fetched image/svg+xml is stored as .svg, and a type with no extension of its own gets .bin, where both used to get .jpg. The MIME type's parameters and case no longer change the extension.
• An include in a method template is a render error: {% include %}, {% extends %} and {% import %} in a template rendered without a loader raise Jinja2TemplateRenderError, where they leaked Jinja's own TemplateNotFound.
• A template reads a Composite's parts by name: {{ combo.summary }}, {{ combo['summary'] }} and combo.get('summary') resolve the named parts of a Composite output, and iter_keys lists them; they used to render empty, and only the raw _content, now refused, reached them. Like any private name, a part whose name starts with an underscore is refused when a template reads it on an input.
• A template's arithmetic error is a render error: a division by zero, or a range longer than the sandbox's cap, raises Jinja2TemplateRenderError where the raw Python exception escaped, which validation reported as an internal error rather than as the method's.
• A sandboxed PipeFunc's imports resolve to the same file in every process: the sandbox searches a method's root directory first and then its subdirectories in sorted order, where the order followed the hash of their paths, which changes from one process to the next. A module name used in two directories of a method, such as a structures.py shipped in a subdirectory beside the structures module the sandbox generates at the root, could resolve to either file. A temporary directory reached through a symlink, as on macOS, no longer lets a file's own directory jump ahead of that order or stay on sys.path after the run.
• Docling extracts HTML, Markdown and CSV: a document Docling reads without pages (HTML, Markdown, CSV, AsciiDoc) comes back as one page holding the whole document, where it came back with no pages and no text, and one given as a storage key or a data: URL reaches Docling, where its bytes were refused as an unknown file type.

Security

• Every template renders in a sandbox (Breaking): prompts, compose and construct templates, image and search prompts and condition expressions may read data and call methods of plain values (strings, numbers, dates, containers) only, so a template that reaches for a Python internal, calls a method of a Pipelex or pydantic object, or reads a name starting with an underscore other than an input's _stuff_name, _content_class, _concept_code and _stuff_code raises Jinja2TemplateSecurityError instead of rendering, and validation refuses the visible cases with the new template_private_name error. _content and the stuff property are no longer readable on an input, and bracket access and get on an input resolve only its content fields and metadata fields; a plain dict's keys stay readable with brackets, record['_id'] included, and a namespace() holds data only, refusing a callable. The jinja2 floor rises to 3.1.6, the release carrying Jinja's own sandbox fix for the attr filter.
• Dotted paths refuse underscore segments: a PipeCompose construct from path such as note.__class__.__init__.__globals__.sys.modules.os.environ walked into Python internals with plain getattr and could copy the process environment into a method's output. A from path or list_to_dict_keyed_by name with a segment starting with an underscore is now refused at validation, and every dotted path the runtime walks, batch lists and prompt image references included, refuses one.
• A scoped run reads only under its read scope, and never the local disk: on a run with a read scope, a pipelex-storage:// key is read only when it lies under that scope, compared segment by segment, and a bare path or a file:// URI is never read, whichever value carries it — an input, a PipeCompose construct that assembles a URL from text, a model's structured output. Every content-generation leaf checks the URLs it will read before the dry-run branch, and the input seam checks a CSV input and every file it would upload or sign; a refused read raises UriReadRefusedError, answered as a 422, which names where the URL sat without quoting it. A run whose read scope is None reads as before.
• A sandbox-hosted load imports no method Python, and refuses structure classes (Breaking): on a deployment whose PipeFunc execution mode is not direct, loading a library directory captures every .py file as source for the sandbox and imports none of them, where a file declaring a StructuredContent subclass was imported into the loading process and its module-level code ran. A load whose Python declares such a class, however the method arrived, now raises MethodStructuresRefusedError naming each file and class by its relative path, the error a fetched package already got: declare the types as MTHDS concepts with inline structures, which a PipeFunc imports in the sandbox from the generated structures module. The module pipelex build structures writes is accepted while it is left as generated, by this refusal and by the fetched-package one, and is not sent to the sandbox, which generates its own from the same concepts. Both refusals, and the local warnings that predict them, now give that same route. A direct load is unchanged.
• Fetching a URL refuses private destinations (Breaking): every download of a URL a value carries — a prompt image or document for a provider that does not take URLs, a document to extract or render, a generated image a provider returned as a link — now refuses a host that is localhost, a cloud metadata alias or resolves to any private, loopback, link-local or metadata address, on the first request and on every redirect hop, raising SsrfBlockedError and failing the pipe, where it followed redirects anywhere and returned the body. The guarded fetch connects directly and ignores HTTP_PROXY / HTTPS_PROXY; a self-hosted deployment that reads documents from an intranet host or reaches the internet through a proxy sets the new [runtime.network] is_fetch_ssrf_guard_enabled = false. make_base64_url_from_any_uri and make_base64_url_from_http_url move to pipelex.tools.uri.uri_base64.

[v0.69.0] - 2026-09-28

Highlights

Structured output moves to instructor 1.17, and the provider SDKs move with it. The mistralai extra takes mistralai 2.x, and the Bedrock and S3 extras take aiobotocore in place of aioboto3, which renames the bedrock_aioboto3 SDK handle to bedrock_aioboto. Structured output on the google backend now accepts enum fields and sends the system prompt, the temperature and the token limit.

Changed

• A bare string at an Anything input is an Anything value (Breaking): it becomes a native.Anything stuff holding text, where it used to become a native.Text stuff.
• A JSON input reads a JSON object literally (Breaking): a bare string at a JSON input is refused instead of becoming native.Text, the compact inputs template of a JSON input is the bare object rather than the envelope {"concept": "native.JSON", "content": {"json_obj": …}}, and a JSONContent holding a value JSON cannot encode, such as a date or a set, raises a pydantic ValidationError instead of a TypeError.
• An envelope-shaped item of a bare Anything[] or JSON[] list is refused (Breaking): an item holding concept and content keys is no longer read as data; wrap the whole list in one envelope to type it.
• A value the fallback has no reading for is a StructureValidationError (Breaking): at a Dynamic or container-native input, a bare value the bottom-up reading cannot build, such as a list of plain objects, raises StructureValidationError naming the input and its concept instead of an unnamed StuffFactoryError, and its next step names the declaration that reads the value (JSON, JSON[], Anything or Anything[]) when one does.
• An explicit single value at a fixed-count input is refused (Breaking): an envelope holding one value at a Concept[N] input raises MultiplicityCountMismatchError instead of being stored as a single value.
• NaN and the infinities are refused at Number, JSON and Anything inputs (Breaking): a TOML inputs file can spell nan and inf, which JSON cannot hold, so a Number or Anything input given one raises WrongScalarKindError, and an object holding one anywhere inside it raises StructureValidationError, where each used to store a number that JSON serialization turns into null. A JSONContent or a NumberContent holding one raises a pydantic ValidationError, which is also what an explicit envelope building one reports.
• Chaining an Anything value through --with-memory changes it (Breaking): an Anything stuff's content is dumped as its content class's fields, so a bare "hi" sent to an Anything input is dumped as {"text": "hi"}, and a method reading that memory at an Anything input receives that object rather than the string; a list is dumped as one object holding its items. It used to travel as native.Text, since a bare string at an Anything input became a native.Text stuff.
• The Anything input schema excludes array and null: the JSON Schema published for an Anything input carries "not": {"type": ["array", "null"]}, and so does each item of an Anything[] input's schema.
• aiobotocore replaces aioboto3, and the bedrock_aioboto3 SDK handle is renamed bedrock_aioboto (Breaking): the bedrock and s3 extras depend on aiobotocore 3.x instead of aioboto3, whose latest release pins boto3 below 1.40.62, so both extras now take boto3>=1.42.42. The new handle names the async Bedrock client rather than the library under it, so a later change of library will not rename it again. Migration: a backend file that still sets sdk = "bedrock_aioboto3" keeps loading but fails on every call to its models, with an error that points at pipelex migrate, which names each such file under inference-backend@3 without rewriting it, so replace the handle with bedrock_aioboto by hand.
• instructor 1.17, and the mistralai extra on mistralai 2.x (Breaking): pipelex now requires instructor>=1.17.0,<2.0.0, and the mistralai extra takes mistralai>=2.10.0, whose client lives under mistralai.client, so a project that imports mistralai 1.x beside pipelex must move to 2.x with it. instructor 1.17 dropped its strict tool mode, so the instructor/openai_structured_outputs structure method now sends the same non-strict tool schema as instructor/openai_tools, and OpenAI no longer enforces the schema on its side: pipelex still validates the response and re-asks on a mismatch.
• opentelemetry-api and opentelemetry-sdk 1.39 or later: pipelex now requires both at >=1.39.0 instead of >=1.38.0.

Fixed

• Anything inputs take any JSON value: a string, a number, a boolean, an object or a date at an Anything input becomes its natural content under the Anything concept, Anything[] takes a list of them, a prebuilt list mixing contents of different kinds included, and a typed envelope keeps its own concept; they used to be refused, a bare string aside. A sequence declaring an Anything output over a narrower last step now validates.
• JSON inputs take objects and lists of objects: a JSON object at a JSON input, and a list of them at a JSON[] input, now build, where a list of plain objects used to be refused with an error naming neither the input nor its concept.
• A single Anything value survives the transport boundary: a stuff whose concept is native.Anything keeps its content's class through dump_for_transport and hydration, which a distributed or sandboxed run relies on; hydration used to fail looking for an AnythingContent class.
• A composite nested in an Anything value or in another composite survives transport: its components, a nested composite and a list of composites included, come back through hydration as typed contents, where they came back as dicts carrying class markers.
• The result files of an Anything output render its value: a delivery whose main output is Anything renders main_stuff.json, .md and .html from the hydrated content, where it fell back to a raw dump of the transport form.
• A prebuilt list is refused where one value belongs: a ListContent given as an item of a plural input, or as the content of an Anything envelope at a single input, is refused instead of being stored nested or in a singular slot.
• bedrock_anthropic models run with AWS_BEARER_TOKEN_BEDROCK set: under bedrock_access_variant = "aws_access", the default, Anthropic models on Bedrock sign their requests with the configured AWS access keys and ignore a Bedrock bearer token in the environment, where every one of them used to fail at client construction with a raw ValueError. When the access keys are missing and the environment carries such a token, the AwsCredentialsError now says so and names bedrock_access_variant = "bedrock_token" as the way to authenticate with a bearer token.
• Structured output on the google backend accepts enum fields: under instructor/genai_tools, instructor validated Gemini's function-call arguments strictly and refused a string for any enum field, so every schema with an enum failed on every attempt; those arguments are now validated in lax mode, so a google.toml an earlier pipelex init copied keeps working unchanged. The backend file we ship now sets structure_method = "instructor/genai_structured_outputs", Gemini's native JSON output.
• Structured output on the google backend sends the system prompt, temperature and token limit: instructor ignored the Google config pipelex handed it, so every structured call ran with no system prompt, the default temperature and the model's default output token limit, whichever structure method the backend used; they now reach Gemini.
• A transport error inside a structured-output call is classified again under instructor 1.15.3 and later: those releases wrap a provider's rate limit, timeout or refused connection in their own retry exception, which pipelex classified as an unknown error, or after a re-ask as the earlier parse failure; the provider's error is now read first, so it keeps its category, its retryability and its provider metadata.
• A gateway that does not allow the model asks for another model: the inference gateway's model_not_allowed_error refusal (HTTP 412) now reads as a configuration error whose change_model action names the model handle and says who settles a model deck that lists a model the gateway refuses, where it said to review the prompt, parameters and inputs. The HTTP status stays 500.
• A structured-output call is re-asked when the model returns no tool call or no JSON: under instructor 1.16 and later such a response raises a parse error that pipelex's re-ask loop did not retry, so it failed at once; the loop now retries exactly the parse errors instructor itself re-asks.
• A model whose structure_method names a provider-specific instructor mode sets up again: instructor 1.17 refuses another provider's mode on an OpenAI-compatible client, which failed the setup of such a model, the gateway's mistral-large among them; each structure method now builds with the core mode instructor itself resolves it to.
• Mistral OCR on an image returns the figures it finds: an extract from an image, rather than a document, failed with MistralExtractResponseError whenever Mistral OCR detected a figure inside it, because the request never asked for the figures' pixels; it now sends the same image options as a document extract, so max_nb_images and image_min_size apply to images too, and a request for captions, which Mistral OCR cannot write, is refused on an image as it already was on a document instead of returning none.
• A no-op tracer no longer stamps a fake Pipelex span on log lines: from opentelemetry-api 1.40, the no-op tracer OTEL_SDK_DISABLED hands out returns its parent instead of an invalid span, so every line of a run carried pipelex.trace_id and a pipelex.span_id of 0000000000000001 naming no span; a pipe or an LLM call now starts no span under such a tracer, as with no tracer at all.

Removed

• pipelex.providers.openai.openai_func (Breaking): the module and its create_pydantic_model_from_function, create_openai_schema_from_function and list_openai_tools helpers are removed; nothing in pipelex called them.

[v0.68.0] - 2026-09-27

Highlights

Every log line can be joined to its run and to your own traces. A run driven through the kernel, each kernel step and a run dispatched to a distributed orchestrator's workers now stamp request_id, pipeline_run_id and pipe_run_id on their lines as an interpreted run does, and a host passes the inbound request id it filters its logs on. A line's standard trace fields now name your process's current OpenTelemetry span, with Pipelex's own span beside them under pipelex.*, and the gcp sink refuses to boot on credentials Google rejects instead of losing every record in silence.

Added

• PipelexKernel.log_context() and JobMetadata.log_context(): JobMetadata.log_context() binds a job's request_id, pipeline_run_id and pipe_run_id onto the log context in one call, and PipelexKernel.log_context() binds a kernel run's request_id and pipeline_run_id, which a host wraps its run in so the lines it emits between kernel calls name the run.
• PipelexKernel.make takes request_id and pipeline_run_id: a kernel-driven run can now carry the inbound request id a hosted deployment filters its logs on, and name itself with an id the host chooses. A host inside a replay-based executor passes a pipeline_run_id or a trace context, since the default uuid4 changes on every replay; a trace context and a pipeline_run_id that disagree, or an empty pipeline_run_id, raise ValueError.
• PipelexMTHDSProtocol.execute takes request_id: a host running execute passes the inbound request id, which the run's RunMetadata carries, so the log lines of a run dispatched to a distributed orchestrator's workers carry request_id as a direct run's do. A value that is not one to 128 printable ASCII characters is refused with a ValueError before the run is set up, where it used to surface as a PipeExecutionError blaming the caller's input; the constraint is stated once, as validate_request_id in pipelex.system.job_metadata, which RunMetadata applies too.

Changed

• The gcp log sink stops the boot when Google refuses its credentials (Breaking): the sink refreshes its credentials once when it is built, within five seconds, and credentials Google refuses (a revoked or expired refresh token, a deleted service-account key, a Google Cloud machine with no service account) or that cannot be loaded (no Application Default Credentials, a key file that is missing or holds no valid key) raise the new GcpLogSinkCredentialsError, a config-domain CredentialsError naming the credentials, Google's answer and what renews them, which pipelex doctor reports in its log-sink row. Such a process used to boot and lose every record in silence, since over gRPC the failed refresh is retried for a minute before anything reports it; a refresh that cannot reach the token endpoint or the metadata server, gets an answer that says to retry (a 5xx, 408 or 429), or does not answer in time, is said on stderr and the boot goes on.
• A log line's standard trace fields name OpenTelemetry's current span, and the Pipelex span rides under pipelex.* (Breaking): in the json, otlp and gcp sinks, trace_id, span_id and trace_flags (the otlp record's own trace context, the gcp entry's trace) now always name your process's current span and are absent when there is none, inside a Pipelex run too, where they used to name the pipe's or the LLM call's span; that span is written beside them as pipelex.trace_id and pipelex.span_id, keys in the json line and the gcp payload and attributes on the otlp record, reserved on every line like the sinks' other keys. The gcp entry's trace is no longer derived from pipeline_run_id and is set only under a current span, with the new spanId and traceSampled beside it, and the pipeline_run_id label still selects a run's lines. If you export Pipelex's spans to your own backend, join a line inside a run to them on pipelex.trace_id and pipelex.span_id. For a sink plugin, span_context_for_logs() and otel_context_for_logs() are replaced by current_span_context_for_logs(), pipelex_span_context_for_logs() and pipelex_trace_fields_for_logs() in pipelex.system.telemetry.current_span.

Fixed

• The gcp log sink says when its flush runs out of time, and why: a teardown whose flush reaches its five-second deadline with records still held now prints on stderr that they are lost unless the transport sends them while it closes, followed by what a fresh refresh of the credentials answers, where only the client library's "Failed to send N pending logs." used to appear. A handler that has closed no longer flushes again when the process exits, which cost a second five-second wait.
• A GcpLogSink installed a second time raises instead of sending nothing: installing the same sink object again after a reset built a handler on the transport the first teardown had closed, which queued every record and sent none; make_handler now raises RuntimeError, as the otlp sink does, and the registered gcp factory still builds a new sink at every boot.
• A kernel step's log lines name its run and its step: run_llm_text, run_llm_object, generate_object_content, run_extract, run_search and run_img_gen now bind the job_metadata they are handed for the whole call, so a program driving the kernel directly gets log records carrying request_id, pipeline_run_id and pipe_run_id, as an interpreted run's do. An interpreted run's lines are unchanged.

[v0.67.1] - 2026-09-27

Changed

• pipelex-agent --runner api run reports the runner's refusal, not its status line: when the API runner answers run pipe, run bundle or run method with a non-2xx status, the error envelope, in markdown and in JSON, now carries what its problem document says: the runner's error class as error_type (ValidateBundleError, ModelNotFoundError, StuffFactoryError), a message quoting its reason, which names the failing pipe and its path on a failed run, its next step as hint, its error_domain, error_category and retryable, its validation_errors rendered as validate renders them, pipe_code and pipe_stack when it carries them, its code as error_code, the Retry-After delay as retry_after_seconds, and http_status and request_id, where the envelope used to read only HTTPStatusError and Client error '422 Unprocessable Entity'. An answer that advises no next step gets one from its status: a 401 or 403 points at the API key, a 404 at MTHDS_BASE_URL, a 429 says to wait and retry and is retryable, a 503 warns that a retry can repeat a paid run, any other 4xx says to change the request, and any other status says to report the request_id. It requires mthds 0.17.0, whose client raises the typed ApiResponseError.

Fixed

• The API runner's credentials hint names the variables it reads: a ClientAuthenticationError now says to set MTHDS_API_KEY and MTHDS_BASE_URL or to run mthds config set, where it pointed at pipelex-agent doctor and PIPELEX_API_KEY, which the API runner does not read.

[v0.67.0] - 2026-09-27

Added

• An unknown model is a located unknown_model validation item: a pipe whose model field names a handle, alias, preset or waterfall the model deck does not define now validates to an invalid verdict with one pipe_validation item of the new closed error_type unknown_model, carrying the pipe_code, domain_code, source, field_name, the field_path of the reference (pipe.<code>.model, or pipe.<code>.model_to_structure), and the new optional item fields model_reference (the reference as written), model_type and suggestions (the deck's close matches of the same kind, also kept in the message). Every pipe type that names a model gives the same item, where PipeExtract and PipeSearch used to give an unknown_validation_error whose message was a Python repr, and with exactly one suggestion the item carries an unsafe rename-model fix, which pipelex fix bundle never applies on its own because a fuzzy match can name a different model. The MTHDS Test Corpus gains the invalid_unknown_model entry covering the new error.unknown_model tag.
• An unsafe suggested fix says so wherever it is printed: the per-error line of pipelex validate, of pipelex fix's remaining errors and of every pipelex-agent Markdown rendering, the rendered_markdown shared with /validate included, reads 💡 Suggested fix (unsafe, confirm before applying): for a fix whose safety is unsafe, while a safe fix keeps the plain 💡 Suggested fix: line, so a person or an agent can tell which fixes to check before making them by hand.
• A run graph marks a list-valued stuff as a list: every io item of a GraphSpec produced by a dry or live run now carries multiplicity, true when the stuff is a list and null otherwise, so a renderer shows an input declared Document[], a Record[] output, a batch's aggregate, a step run with nb_output or a lifted plural output as a list, on both the in-process graph and the one assembled from trace events. A trace event carrying the field cannot be read by an earlier pipelex, so the process that assembles a graph must run a pipelex at least as new as the workers that wrote its events. The Mermaid renderer labels such a stuff Record[], and its labels now keep square brackets instead of turning them into parentheses.
• Validation items carry the positions and declared concepts the parser knew: a TOML syntax error's item carries the 1-based line and column the parser stopped at, as new optional item fields, and an unresolved_concept item carries declared_concepts, the bare codes of the concepts the validated bundle declares in its domain, so an editor can anchor the diagnostic and an author sees what the reference could have named.

Changed

• Every refusal raised while loading a bundle is a validation verdict (Breaking): validation turns any refusal of the caller's input that has no arm of its own into an invalid verdict with one item, keeping the refusal's message only when it is caller-facing and otherwise its title, while a configuration or runtime fault still propagates as no verdict. A refusal raised while a pipe is built leaves the library load as the new PipeLoadRefusalError, naming the pipe, its domain and its file with the original as its cause, and gives a pipe_validation item located there; any other gives a blueprint_validation item. pipelex validate bundle no longer prints a traceback for an unknown model, pipelex-agent validate bundle answers it with is_valid: false and exit 1 instead of the no-verdict envelope and exit 2, and the in-process validator behind /validate returns it as an invalid verdict instead of raising.
• PipeOperatorModelChoiceError is the located unknown-model refusal (Breaking): it is now raised whenever a pipe naming an unknown model is built, with a message naming the pipe and the field; it is input-domained and caller-facing, carries domain_code, field_name, suggestions and source, and its model_choice is the reference as written. The agent CLI's hint for it points at check-model rather than doctor.
• A PipeParallel branch whose multiplicity differs from its field's is refused with the fix to make: when the combine of the branch results refuses a list branch fed into a single field, or a single branch fed into a list field, the refusal now names the parallel, the branch, the result and the field, and says to declare the field with the branch's multiplicity or to make the branch produce the field's, instead of reporting a Python validation error about ListContent. The dry run of pipelex validate and pipelex-agent validate carry it in their dry_run item, and a run reports it as a StuffFactoryError in the input domain, so a hosted runner under STRICT disclosure answers a 422 whose message and change_input next step name the change, where it answered An internal error occurred..
• The invalid-bundle verdict's next step points at its items: ValidateBundleError's user action, the 💡 Tip: of pipelex validate and the hint of pipelex-agent's JSON, now reads "Edit the bundle as each validation error says: apply its suggested fix where it has one, after confirming an unsafe one" instead of "Check the validation_errors array for specific issues".
• A run refuses an invalid bundle with the validation verdict (Breaking): a run loads its bundle before any pipe runs, and a bundle that load refuses now raises ValidateBundleError with the same located validation_errors validating it gives, which a hosted run route answers as an HTTP 422 that keeps them under STRICT disclosure, instead of the raw class of whichever check refused it (a 500 for a misspelled concept or a wiring mismatch, a 422 without items for a TOML fault, a runtime PipeExecutionError for a check inside a pipe's validator, a PipeOperatorModelChoiceError for an unknown model); an unknown entry pipe still raises its PipeNotFoundError. pipelex run prints the grouped panel pipelex validate prints, pipelex-agent run and any other agent error envelope caused by such a verdict carry its validation_errors, and the runner's new library_dirs_are_callers option, which both CLIs set, gives a refusal in the caller's own library directories the same verdict while a host's directories still load untranslated.
• A pipe factory's refusal is a located validation item: PipeLLMFactoryError, PipeComposeFactoryError, PipeExtractFactoryError, PipeConditionFactoryError and PipeParallelFactoryError are now input-domained and caller-facing, so a PipeExtract whose input is neither an image nor a document validates to a pipe_validation item on that pipe and its file, whose message names the input and says to redeclare it, where it used to escape every validator as no verdict; a PipeLLM whose prompt or inherited system prompt does not parse is refused with the line of that prompt it fails at and no longer quotes any of the prompt, which may be a host's; the builder's validate_ops.validate_pipe and validate_all also answer a refusal raised while they load libraries or dry-run a pipe with the ValidateBundleError verdict instead of the raw error. pipelex-agent validate pipe --all keeps the file on an item raised while its libraries load.
• pipelex validate pipe and pipelex validate --all render a refusal as an invalid bundle: a pipe whose dry run fails, and a refusal of the libraries while they load, now print the grouped invalid-bundle output and exit 1 instead of a traceback; pipelex-agent validate pipe and --all answer a load-time refusal with the invalid-verdict envelope.
• A failing dry run is one located item per failing pipe (Breaking): validation reports a dry-run failure as one dry_run item per failing pipe, with the error type DryRunError and the pipe_code, domain_code and source of the innermost pipe that failed and is not allowed to fail (when submitted content is validated beside a host's library directories, the source only for that content's own pipes, never a file of the host's own library directories), where it used to report one item holding a Python repr of the sweep's records, once more for every controller the failure passed through. The item keeps the failure's own message only when that message is caller-facing and otherwise names the failure's title, so a configuration or storage failure met during a dry run no longer reaches a hosted caller through the verdict; pipelex validate lists the items under Dry Run Errors:, pipelex-agent validate pipe and validate pipe --all answer a failing dry run with the invalid-verdict envelope and its items instead of a DryRunError envelope with none, and the agent inputs commands drop their dry_run_error key. In Python, ValidateBundleError takes dry_run_failures in place of dry_run_error_message, and DryRunError carries failures.
• A run failure reports its root fault, located at the failing pipe (Breaking): the report of a PipelineExecutionError, and of the PipeRouterError under it, now carries the error_type, title, type_uri, caller-facing flag and own message of the root fault, the innermost Pipelex error on the cause chain, with the message prefixed by the failing pipe and its path (Pipe 'summarize' failed (two_steps → summarize): …), and the exception's pipe_code and pipe_stack name that pipe instead of the entry pipe. A bridge's sentence no longer reaches the report, a report recovered from a remote worker is taken as it is, so a run reports the same failure in process, through the in-process orchestrator or on a worker, and the fallback action names the failing pipe instead of saying Check pipe_stack to identify which pipe failed. A consumer branching on error_type == "PipelineExecutionError" branches on the root fault's type instead, as the error model describes.
• The pipe router locates every failure (Breaking): PipeRouterProtocol.run() now re-raises any failure of its pipe as a PipeRouterError chained to it, where it used to let everything but a CogtError through, and a failure already located by an inner router rises untouched. An exception that is not a Pipelex error becomes a PipelexUnexpectedError whose message names its class, and a host router overrides the new _as_pipelex_failure() hook to convert its transport's failures or let a control-flow exception through. Code that caught a pipe's own error class from get_pipe_router().run() catches PipeRouterError and reads its __cause__.
• ModelNotFoundError's message states the fact only: a handle missing from the model deck reads Model handle '<handle>' was not found in the model deck., without the local-deck advice it used to carry into every surface, hosted runs included. pipelex run now renders the model panel for a run failure, naming the failing pipe, the model and the pipe stack, and the panel's tip carries that advice.
• The agent CLI's run errors name the root fault: pipelex-agent run reports a failed run's pipe_code and pipe_stack at the failing pipe, and its cause_type and cause_message are the root fault's instead of the wrapper right under the run error.

Fixed

• Every validation error reaches the reader: an error the blueprint categorizer does not know, such as a misspelled field, is its own blueprint_validation item without an error_type, carrying its source, pipe_code and field_path, where it used to vanish whenever another item existed and surface only once that one was fixed; and format_pydantic_validation_error renders every error it is given, listing the kinds without a heading of their own under "Other validation errors" whatever else is present.
• A validation verdict names no path on the host: an item located inside a package the method depends on by address, and a duplicate declaration inside that package, now name the bundle by the package's address and its path inside the package (github.com/acme/harbour-methods/tides/notices/tide_notices.mthds) instead of the directory the host installed it in, on every surface; and when submitted content is validated or run beside a host's own library directories, an item located in one of their files carries no source or field_path naming it and a message that named such a file, or the module one of their Python files was imported as, reads <host library file>, so STRICT disclosure no longer hands a hosted caller a path on the server. A bundle validated from a file keeps the full paths of its own library directories, and so does content validated against directories that are the caller's: validate_bundle and validate_bundles_in_process take library_dirs_are_callers, which PipelexMTHDSProtocol.validate now passes as its execute does.
• A run that fails on the caller's own method reads its reason under STRICT disclosure: a PipeParallel whose branch results do not fit its output, a pipe started without a required input, a PipeCondition whose expression renders nothing, whose outcome is fail or whose chosen pipe misses inputs, and a step naming in an inline setting a model the deck neither defines nor names now report the input domain, so an HTTP surface answers 422 instead of 500, a message STRICT disclosure keeps instead of An internal error occurred., and a next step: for the model, a change_model action naming the model as the method wrote it and the type of model its pipe needs, which the model panel of pipelex run follows with its local-deck advice. A PipeCondition's dry-run refusals, among them an expression rendering nothing and every outcome mapped to fail, now give a dry_run item carrying their reason, and name the missing pipes instead of printing the outcome map; a fail outcome's message names the pipe and no longer the value its expression rendered, and neither does the absence reason a continue outcome records, which the message of a step force-unwrapping the condition's output quotes under STRICT disclosure. A model that the deck itself names but does not serve stays a redacted config error. The new PipelexError.as_caller_fault() is how a raise site classifies one error of a class whose other instances are not the caller's fault, as the error model describes.
• A PipeCondition whose expression does not parse is an item of the verdict: validation refuses it as a blueprint_validation item on the condition, naming its expression or expression_template and the line of it that fails, and refuses the same way an expression that parses but that the run could not compile, such as one naming a filter or a test that does not exist outside any conditional (Jinja2 leaves a name inside an {% if %} or an inline if to be resolved when the expression renders); a run of the bundle is refused with that verdict, which a hosted run answers with HTTP 422, where the parser's error used to escape the load with no verdict and a hosted run answered 500 An internal error occurred.. The item quotes neither the expression nor the parser's diagnosis, since the condition may be a host library's.

[v0.66.1] - 2026-09-26

Added

• load_from_crate takes is_crate_prevalidated: LibraryManager.load_from_crate(library_id=…, crate=…, is_crate_prevalidated=True) skips the library validation that ends a load, for a crate built from a library that the same pipelex version already loaded and validated, such as the crate a distributed run hands its worker; everything else the load does still runs, and the default stays the validating load.

Changed

• are_classes_equivalent answers without a JSON schema when it can: a class is equivalent to itself, and two plain models with different field names are not equivalent, both now decided before any schema is generated, which removes most of the cost of validating a library whose pipes output structured concepts. A plain model is one built only from an allow-list of annotations (scalars, Any, Literal, unions, builtin containers and nested plain models), inert constraints and plain defaults, with no alias and no schema hook or schema-shaping setting, so the properties pydantic publishes for it provably equal its field names; the structure classes generated from a concept's structure table and most native content classes are plain. Verdicts are unchanged: every other pair still goes to the full schema comparison, and a schema that cannot be generated still raises.

[v0.66.0] - 2026-09-25

Highlights

Logs are structured, scrubbed and sent where you choose. Every log call can carry named fields and the run's identifiers, one configuration key selects the sink (the Rich console, JSON lines for a log agent, OpenTelemetry, Google Cloud Logging or a plugin's own), secrets are redacted before any sink sees a record, and a line logged inside a span carries its trace context. Rich moves behind the cli extra, so the runtime no longer needs it on the way to running a method.

Added

• Named fields and a run-scoped context on the log calls: the seven log.* methods take a keyword-only fields={...}, carried as attributes of the stdlib LogRecord and never rendered into the message, and with log.context(request_id=..., pipeline_run_id=..., pipe_run_id=...) stamps the run's identifiers onto every record emitted in scope, nested bindings merging and an absent identifier staying absent rather than reading None. A direct-mode run binds its request and pipeline identifiers from the job's metadata, and every pipe binds its own pipe_run_id around the whole of its run. A dict or list content is also carried as the record's data attribute, a JSON-ready snapshot of the call, and a field named like an attribute the record already owns, like a name Pipelex sets on it, data included, or like a key a sink writes itself rides under a field_ prefix instead of raising or overwriting it, as Logging describes.
• Log sinks are a plugin capability selected by [runtime.log] sink (Breaking): where the records go is a registered sink token: console (the Rich handler, the default), json (one JSON object per line carrying time, severity, logger, message, the fields, the context identifiers and the exception, with no ANSI ever, for a server behind a log agent), otlp (the OpenTelemetry logs signal, configured under [runtime.log.otlp]), or a token an installed plugin registers through add_log_sink. A token nobody provides stops the boot naming the registered ones, and pipelex doctor reports it in a row of its own. log_mode, poor_loggers, generic_poor_logger and is_console_logging_enabled are gone with the rich-or-poor mode, and set_log_mode, set_poor_log_formatter and LevelAndEmojiLogFormatter with them, so a server that wants plain output selects json and a host that wants Pipelex silent sets pipelex = "OFF" under [runtime.log.package_log_levels]. Migration: run pipelex migrate; ledger entry pipelex-config@5 deletes the four retired keys from ~/.pipelex/ and every project .pipelex/ file, after which the defaults supply sink = "console". A file that had log_mode = "poor" or is_console_logging_enabled = false chose a behaviour that no migration may write back, so it then sets sink = "json" or pipelex = "OFF" under [runtime.log.package_log_levels] by hand, as the entry's title says. Log Sink Plugins documents the seam.
• A gcp log sink writing to Google Cloud Logging: sink = "gcp" sends each record to Cloud Logging through the google-cloud-logging client library, which the new gcp-logging extra installs, and selecting it without the extra stops the boot naming the extra. Each record becomes one structured entry, with the level mapped onto Cloud Logging's severities, the fields in its JSON payload, the run's identifiers as its labels and the run's trace id in its trace field, so a line is filed with the spans of its run; the entries leave through the library's background transport, and [runtime.log.gcp] carries the log name, the project and an optional service-account credentials path. Most processes on Google Cloud want json instead: Cloud Run, GKE and any platform whose logging agent reads the container's stdout ingest what that sink writes with no client at all, as Logging Configuration spells out.
• Log lines carry the trace context of the span they were logged in: inside a valid span the json sink writes trace_id, span_id and trace_flags in lowercase hex, the keys OpenTelemetry specifies for trace context in a JSON log that is not OTLP, and the otlp sink files each record under that span. The span is the Pipelex span active at the log call, a pipe's or an LLM call's, whenever the runtime traces a run, and otherwise OpenTelemetry's current span, only read, so a line your code logs under its own span joins your trace. Pipelex never makes its own spans current in the process's OpenTelemetry context, so a host's instrumentation is never re-parented under them, as Logging describes.
• Secrets are scrubbed and field values made injection-safe before any sink sees a record: one processor, on by default and configured under [runtime.log.redaction], replaces with [REDACTED] the credential of an Authorization header, an api-key or signature header, an OAuth code parameter, every cookie crumb, a name=value secret entry and an sk_ / plx_sk_ / pk_ / bl_ key, in the message, in the rendered exception and in every string a field carries, and the whole value of any field or mapping entry, at any depth and in a structured content too, whose name is a secret's (authorization, password, api_key, access_token and the like). Control characters in a field's string values become printable escapes, so a caller-supplied string cannot forge a line or a terminal colour, and extra_patterns adds the secret shapes only a deployment knows, a pattern the re module refuses or one matching the empty string being a configuration error at load. The processor runs ahead of every sink, and of a handler the host adds after it, and fails closed: a record it cannot redact is reduced to a [REDACTION FAILED: …] notice or dropped, and a sink processor that raises is reported on stderr by its type and name, never by its text, as Logging describes.

Changed

• Rich is the cli extra (Breaking): rich is no longer a core dependency, so install pipelex[cli] for the pipelex and pipelex-agent commands, the console log sink and the rich pretty-print mode (uv tool install "pipelex[cli]"). The runtime imports Rich only inside the code that renders, so a method runs with sink = "json" and pretty_print_mode set to "poor" or "silent" without it, while a boot selecting the console sink or the rich mode without Rich stops naming the extra, and get_console(), rendered_pretty(), the model and pipe listings and the directory diff raise MissingDependencyError naming it too. PrettyPrintable, TextType and StyleType in pipelex/tools/misc/pretty.py now exist only for type checking, so importing them at runtime raises ImportError. A plain pip install pipelex still installs Rich and import pipelex still loads it, since the core dependencies typer and instructor both require it, and a poor-mode panel title no longer substitutes emoji codes; Rich Imports documents the convention and its make check-rich-imports guard.
• Loggers are named by module (Breaking): a record from pipelex/pipe_operators/pipe_llm.py is emitted on the pipelex.pipe_operators.pipe_llm logger instead of pipelex, so a handler keyed on the bare package name must key on the prefix, and a filter an integration attached to the pipelex logger must move to its handler, since Python never consults an ancestor logger's filters for a record propagating up from a module logger. A package_log_levels key now works at module depth too, pipelex-pipe_operators-pipe_llm = "DEBUG" for instance, and the caller-info templates that name the module now render instead of raising.
• include_exception carries the traceback as the record's exc_info: instead of splicing traceback.format_exc() into the message, so the console renders one Rich traceback, the json sink an exception field and the otlp sink the exception.type and exception.stacktrace attributes, and a call made outside an except block carries nothing where a NoneType: None line used to be appended.
• Teardown removes only the handlers Pipelex installed: log.reset() no longer strips every handler off the root logger nor calls logging.shutdown(), so a host's or a test's handler survives a Pipelex teardown; the sink's handler is flushed and closed, which is where a batching sink ships what it still holds. A sink installed again after the reset builds a fresh handler, except an OtlpLogSink object, whose close shuts its processor down, so installing the same one a second time raises; the registered factory builds a new one at every boot.
• The pitch names who each way of running a method is for: the README, the documentation's front page and Quick Start, and the site description now say a method runs "as an MCP for chatbots, as a webapp for people, or via API for your software", instead of "from your agent or your chatbot via MCP, as a webapp, or via API in any software".
• The quick start says the plugin also puts a method in your software: the README and the documentation's Quick Start now say the plugin's skills build methods, run them and put them in your software, name /pipelex-scaffold for a webapp and /pipelex-integrate for a typed call from TypeScript or Python code, and say that @pipelex/sdk is the TypeScript SDK and pipelex-sdk the Python one.
• The documentation's cookbook is one page that points to the cookbook: the cookbook now holds Pipelex's example methods as packages you run by their address on the hosted API, each with its own page showing every way to use it, so the documentation no longer keeps a page per example. The Pipelex Cookbook says what the cookbook is and links to it, the pages that linked an example now link its page in the cookbook or in the method library, and every old example address redirects to the new page. The two pages that documented the runtime itself move into the runtime's own sections: Writing an Inference Plugin, under Under the Hood, now carries the whole sample plugin and the configuration that routes a model to it, and CV Batch Screening, Step by Step joins Get Started. The README's cookbook line says what the cookbook now is.

Fixed

• S3 links name the bucket's own host (Breaking): the S3 storage provider now signs links, and reads and writes objects, on the bucket's regional host <bucket>.s3.<region>.amazonaws.com instead of the region's shared endpoint s3.<region>.amazonaws.com, so a content security policy can allow one bucket's links without allowing every bucket in the region. A legacy bucket name that cannot be a hostname, one with uppercase letters or an underscore, keeps the path-style form on the regional endpoint, for signed and unsigned links alike, where an unsigned link used to name a virtual host that could not serve it; the configuration still refuses a bucket name containing a dot. A self-hosted deployment whose egress rules allow S3 by hostname must allow *.s3.<region>.amazonaws.com.
• Image and document inputs carry a public_url whatever form their url takes: an input given as a pipelex-storage:// reference now gets a link signed through the storage provider, replacing any link it carried, which may have expired, and an input given as an http(s) URL gets that URL as its public_url unless it names another. This holds for an image or document passed alone, in a list or in a structured field, so a template writing {{ image.public_url }} no longer renders None for one uploaded to storage or passed by URL, and a reference the storage provider refuses as a key is reported as an input error before the run starts.
• A NUL byte in an input's path or storage reference is an input error: a local file path, or a pipelex-storage:// reference on local storage, holding a NUL byte used to escape as an internal error; it is now reported as an input error before the run starts.
• Unsigned storage links percent-encode their key: the S3 and GCS providers' unsigned links now encode a key holding a space, +, # or ? as a signed link does, instead of naming a path the URL cuts short.
• A cancelled pipe run ends its span: the pipe's span was closed only when the run raised an Exception, so a run cancelled by a timeout, a disconnected client or a cancelled orchestration task never ended its span and no exporter received it. It now ends with an error status like any other failure.
• A log call before log.configure no longer raises: it goes to the stdlib's default handling at the stdlib's default level, so a library that logs before Pipelex boots, or a boot that logs while it configures, cannot crash on the log line itself. Between log.configure and the sink's arrival, the boot's records are held and replayed through the selected sink in order, and a boot that dies before its sink arrives sends all of them to stderr.
• A log call never raises on a content JSON refuses or on a bracket Rich reads as markup: a content json refuses, a circular reference or a mapping with a non-string key, is rendered as its repr with no data instead of raising ValueError or TypeError out of log.info. On the console sink, a message carrying a tag-shaped span, list[int] in a type complaint or a bracketed path, no longer raises MarkupError out of the log call, and an error assembled from an exception is rendered verbatim rather than read as markup.

[v0.65.0] - 2026-09-25

Changed

• BundleValidatorProtocol.validate_bundles requires graph_pipe_code (Breaking): a host names the pipe the best-effort graph arm dry-runs, resolved the way a run resolves its entry pipe, with None keeping the primary blueprint's main_pipe. A host validating a fetched method package by address can now graph the pipe its manifest names, which a bundle declaring no main_pipe of its own left without a graph. Every validator implementation must accept the argument and hand it to its graph arm, and a host must pass it; DirectBundleValidator forwards it to validate_bundles_in_process.
• The quick start shows both agents' installs: the README's Codex install now starts open beside the Claude Code one instead of folded, and the documentation site links its content tabs, so choosing Codex on one page selects it on every page.
• The documentation's front page takes the README's hero: it opens on "Turn your expertise into an AI-powered App, MCP or API" and the paragraph on building a method with your coding agent and where it runs. Get Started now follows the buttons, and What a Method Looks Like, which now introduces the MTHDS language, and Why Methods? come after it. The front page's entry in the navigation is now Overview.

[v0.64.2] - 2026-09-24

Fixed

• The quick start says the Pipelex plugin needs Node.js: the README's quick start and the documentation's Quick Start and Pipelex Plugin pages said, in the Claude Code install step, that the plugin needed nothing else to install. Both agents' install steps now say that the plugin's hook and the Pipelex tools run on Node.js, so you need Node.js on your PATH; without it the hook passes silently and the tools never start.
• An unknown model name keeps its message on a hosted surface: ModelChoiceNotFoundError is now caller-facing, so under STRICT disclosure its message — the model reference the method named and the "Did you mean" suggestions — reaches the caller instead of "An internal error occurred.". A hosted dry run or run of a method naming a model the deck does not know now says which one and what to use instead.

[v0.64.1] - 2026-09-24

Changed

• The README leads with the hosted route: its quick start is the onboarding region included from Pipelex/.github — sign up at app.pipelex.com, then the Pipelex plugin in Claude Code or Codex or the Pipelex MCP in ChatGPT or Claude — and the runtime's own install, configuration and first run follow under their own heading, Run it yourself. The CV batch screening walkthrough moved from the README to the cookbook in the documentation. Its hero is the website's line, "Turn your expertise into an AI-powered App, MCP or API", with a paragraph on building a method with your coding agent and where it runs, and What a method looks like and Why methods? follow the install instead of preceding it. Configure AI Access no longer offers the Pipelex Gateway: it names your own provider keys or a local model.
• The documentation site leads with the hosted route: its getting-started opens on a new Quick Start page — sign up at app.pipelex.com, the Pipelex plugin in Claude Code or Codex, the Pipelex MCP in ChatGPT or Claude, then a webapp from the method-app template or the hosted API over HTTP, TypeScript or Python — and the runtime's own install moves to Run It Yourself. Build with Claude Code and its npm install -g mthds route are retired, and Claude Code Skills Plugin becomes Pipelex Plugin, which documents the Pipelex plugin instead of the MTHDS plugin; the old addresses redirect. The front page's buttons and the site's description lead with what Pipelex lets you do.
• mthds version: The pin moves to mthds==0.16.0, the release adding a User-Agent on every MthdsAPIClient request and the mthds.version module. Nothing in pipelex uses either, and the MTHDS standard version stays at 2.0.0, but the pin is exact, so everyone downstream inherits mthds 0.16.0 and a consumer depending on mthds directly must move in step.

Fixed

• Test runs no longer send the Pipelex Gateway telemetry stream: a runtime booted in the pytest or ci integration mode, or in a session that loads the shared pytest plugin, which sets a test run mode when pytest configures, keeps the Gateway stream off even with pipelex_gateway enabled, so a project's test suite no longer reports its runs and its fixture user ids to Pipelex. In a test run a boot no longer needs PIPELEX_GATEWAY_API_KEY for telemetry, DO_NOT_TRACK no longer conflicts with the Gateway, and the Gateway's Portkey debug and tracing flags have no effect, even where the custom stream is allowed; IntegrationMode.is_test_harness names the two modes. The plugin's session fixture set_run_mode is gone: the run mode is set in its pytest_configure, so a boot at test-module import or during collection is covered too.

[v0.64.0] - 2026-09-24

Added

• A caller can be known without a run: CallerIdentity (pipelex.system.caller_identity) holds the user_id and extras a host would state on a run, and scoped_caller_identity makes one the ambient caller for a block. An event emitted with no RunMetadata in hand reads the caller in scope before it falls back to the configured user_id, and PipelexMTHDSProtocol.caller_identity exposes the caller a protocol was built for.

Changed

• A run's analytics_groups is renamed extras (Breaking): the base library no longer names an analytics concept in its run model or its job-preparation signatures. RunMetadata.analytics_groups, PipelexPipeRunInput.analytics_groups on the runtime-bridge payload, and the analytics_groups parameter of pipeline_run_setup, prepare_pipe_job, PipelexKernel.make and the PipelexMTHDSProtocol constructor are now extras: an opaque dict[str, str] of labels the host attaches to a run, which the library never reads by name. Behaviour is unchanged: the mapping is validated where it enters under the same bounds, and telemetry still forwards it whole as the PostHog groups of each capture. Migration: rename every analytics_groups= argument and field to extras; there is no alias, and while the functions and PipelexPipeRunInput refuse the old name, RunMetadata silently ignores it, so a missed rename there drops the groups without an error. Import from pipelex.system.run_extras instead of pipelex.system.analytics_groups, calling validate_run_extras instead of validate_analytics_groups, with the bounds now named RUN_EXTRAS_KEY_PATTERN, RUN_EXTRAS_VALUE_PATTERN and RUN_EXTRAS_MAX_ENTRIES. A dashboard, query or exporter reading the span attribute pipelex.run.analytics_groups must read pipelex.run.extras (PipelexSpanAttr.RUN_EXTRAS) instead.
• Pipelex's own telemetry stream receives the run's user_id as it is: the Gateway stream sent a one-way digest of the caller taken inside the Gateway-key hash, and carried a deployment group instead of the run's own groups. It now resolves identity like the operator's identified stream — the run's user_id is the PostHog distinct_id and its extras ride the groups facet — so a host's events and the runtime's land on the same person and the same organization. The NAMESPACED identity policy and the deployment group type are removed. Anything that names no caller still reports under the Gateway-key hash.
• BundleValidatorProtocol.validate_bundles requires caller_identity (Breaking): a validator is handed who asked for the validation, None meaning nobody, so a hosted /validate attributes its telemetry to its caller. validate_bundles_in_process, validate_bundle, dry_run_pipe_in_process and the BundleValidator sweep methods gain an optional caller_identity of their own. Migration: every plugin implementing BundleValidatorProtocol must add a keyword-only caller_identity: CallerIdentity | None parameter to validate_bundles and pass it on to the sweep it runs, carrying it to the worker when the validation is dispatched. Every host calling validate_bundles must now pass it explicitly: caller_identity=self.caller_identity from a PipelexMTHDSProtocol runner, or None for a validation nobody in particular asked for.

Fixed

• A trace's first span carries its run: the trace-start $ai_span captured on both PostHog streams now includes pipeline_run_id, so the root of a trace joins its run's other events without going through a child span.
• A validation is attributed to the caller who asked for it: the sweep's pipe_dry_run event carried no run, so on a hosted plane it went out under the deployment's configured user_id whoever validated. It is now emitted with the caller in scope, and the sweep's dry runs and the graph arm's dry run state that caller in their job metadata instead of dry-run-no-user. A local validation names nobody and reports under the configured id as before.
• A crash inside a run is attributed to that run's caller: the exception autocapture resolved one runless identity when it was built, so every $exception on a hosted plane landed on the configured constant. Every pipe now runs with its run's caller in scope, an exception leaving a pipe carries that caller — read back through the __cause__ and __context__ chain, so a host's own error raised from it still resolves — and the capture resolves each error's identity when it arrives. An error raised outside every run still reports under the fallback, and mode = "anonymous" still identifies nobody.

[v0.63.0] - 2026-09-23

Added

• A run carries opaque analytics groups: RunMetadata and the runtime-bridge payload gain analytics_groups, a host-supplied mapping of group type to group key ({"organization": "org_acme"} on a multi-tenant host, nothing on a single-user one), threaded through pipeline_run_setup, prepare_pipe_job and PipelexKernel.make beside user_id and storage_scope; like storage_scope, the runtime never reads a key by name. It is validated where it enters — a lowercase snake_case group type, a group key from A-Za-z0-9_-, and a small fixed number of group types per run — so a malformed mapping is a construction error naming the field rather than a failure inside a telemetry capture.
• Telemetry is attributed to each run's caller: spans and events resolve their identity per capture through one TelemetryIdentity, so a run's user_id becomes the PostHog distinct_id, its analytics_groups ride PostHog's groups facet, and both are written onto the span as pipelex.run.user_id and pipelex.run.analytics_groups for every OpenTelemetry exporter, Langfuse's langfuse.user.id included. Everything that names no caller of its own — an event outside any run, or a run whose user_id is a shared placeholder (local, dry-run-no-user, single-tenant) — falls back to the configured user_id and the Gateway-key hash, mode = "anonymous" identifies nobody, and neither value ever becomes an event property or a span name. Pipelex's own Gateway stream receives neither the caller nor the groups, only a one-way digest of the caller taken inside the Gateway-key hash, so a host serving many callers from one process sees each caller on their own timeline without that identity leaving its own project.

Changed

• RunMetadata is frozen (Breaking): a field can no longer be reassigned once the run exists, and an attempt raises a pydantic ValidationError at runtime rather than merely failing a type check. Telemetry reads a run's identity off it while the run is in flight, so construct a new RunMetadata wherever one used to be mutated.

Fixed

• A crash no longer sends a PipelexError's message as written: the exception autocapture sent the message verbatim — which may repeat a file path or a slice of the document that would not parse — even on the shipped default, because redaction applied only to an error handed over bare. Every PipelexError PostHog would reach, across the whole __cause__ and __context__ chain and every member of an exception group, is now replaced by a same-class stand-in carrying the privacy notice, the class name and the traceback, on a copy so the exception the interpreter prints is untouched. An error of another class that copied a PipelexError's text into its own message still sends that text.
• Both telemetry streams record a crash: PostHog's once-per-error stamp made the second stream — always Pipelex's own — drop every unhandled exception on a machine that also reports to an operator's project. The stamp is cleared between the streams now, and an error the host had already captured itself is still not recorded twice.
• An unhandled exception is captured under the same identity as everything else on its stream: the autocapture sent the configured user_id and the Gateway-key hash raw, so mode = "anonymous" still named you on every crash and a run's $exception landed on a different PostHog person from its spans. Both streams now use the identity they resolve for any capture that belongs to no run.
• An anonymous capture no longer marks the Gateway capture of the same event: both streams shared one properties dictionary, so the anonymous branch's $process_person_profile = false reached the Gateway capture sent with a distinct_id. Each capture now takes its own copy.
• A malformed storage_scope is refused before the run registers itself: it was validated only in prepare_pipe_job, after the trace-start emission, so a scope carrying .. announced a trace that cannot be unsent. pipeline_run_setup now gates the caller's scope at its top and again after the local sentinel rebinds it, and prepare_pipe_job keeps its gate for callers reaching that seam directly.

[v0.62.0] - 2026-09-21

Added

• The previous multi-provider deck is parked in the package as a deck variant: pipelex/kit/deck_variants/multi_provider/ holds the four numbered deck files as they shipped before the default moved to Azure, so a project that wants the Anthropic, Google and OpenAI ladder back copies them over the kit's own deck directory instead of reconstructing it, and the directory's README says how. Nothing loads a variant — init, update and the deck manifest ignore it, and it sits outside configs/ so no installer can pick it up — and a parity test holds every variant to the shipped deck's alias, preset and waterfall vocabulary and checks that each handle only the variant names is still declared by a kit backend file, so a parked deck goes red instead of rotting quietly.

Changed

• The shipped model deck resolves only to models the Pipelex Gateway serves from Azure (Breaking): every default alias and preset keeps its name, but the whole language ladder is now the GPT-5.6 range — the premium tier and best-gpt resolve to gpt-5.6-sol, the general and large-context tiers to gpt-5.6-terra, the small tiers to gpt-5.6-luna — and image generation's general and premium tiers to gpt-image-2; $engineering-codebase-analysis reaches its model through @default-large-context-code, the alias that names its job, instead of through the premium tier. Document extraction was already azure-document-intelligence and web search stays on Linkup, which Azure has no equivalent for. pipelex update refreshes the numbered deck files and backs up any you edited; a project that wants the previous models keeps them by naming them in x_custom_llm_deck.toml, which pipelex never touches.
• The shipped deck declares temperature = 1 throughout (Breaking): every model in the GPT-5.6 range fixes its temperature at 1, so every preset states that value instead of one the worker would override while warning on every call, and [llm.choice_defaults].default_temperature is 1 for the same reason — it is the temperature paired with an alias, a waterfall or a bare handle named outside a preset, the for_text and for_object choices every pipe without an explicit model takes among them. Presets are therefore distinguished by their model tier and their reasoning effort alone: $writing-factual and $writing-creative issue the same call, and $engineering-structured runs at temperature 1. A method that needs a temperature of its own writes an inline LLM settings table — model = { model = "gpt-4o", temperature = 0.8 } — since a bare handle is paired with the deck-wide default rather than with a value of the author's.
• The shipped Gateway models reference lists the roster the Gateway actually serves: backends/pipelex_gateway_models.md and its plain twin are generated from the served remote config, and they had not been regenerated since July — so they lacked the GPT-5.6 range this deck now resolves every tier to, while still advertising the GPT-4.1, o-series and GPT-5.1 to 5.2 generations that v0.61.0 retired. Both files are refreshed, in the kit and in .pipelex/, so the reference a user opens to check what their default deck runs on agrees with the deck.
• CLI help and documentation examples name an alias the deck still defines: check-model's argument help, the model-reference and model-suggestion docstrings and the doc examples all used @best-claude, which this release removes, and now use @best-gpt. The "Configure AI Providers" guide also gains a section stating exactly what a fresh install resolves to — the GPT-5.6 ladder and GPT Image 2 for language and image generation, Azure Document Intelligence for extraction, and Linkup for search and for web-page extraction, the two places the deck leaves Azure.
• The Elastic License 2.0 boundary is named by version rather than by date: docs/license.md said the license applies to every version released after 2026-09-14, which left a reader holding a version to work out which side of that date it fell on. It now names the first Elastic version of each artifact — pipelex from v0.58.0, pipelex-api from v0.24.0, @pipelex/mcp from v0.15.0 — and spells out the last MIT version of each.

Removed

• best-claude, best-gemini and best-mistral are gone from the shipped deck (Breaking): an alias naming a provider cannot honestly resolve to a GPT model, and the image deck's best-gemini goes with them. A method referencing one fails validation with the usual alias-not-found error; define it in an x_custom_* deck file to keep it.
• GPT-6 Astra is no longer served on the Pipelex Gateway (Breaking): gpt-6-astra is out of the remote config and out of the shipped Gateway roster, so a method naming it on the Gateway now fails the boot-time membership check. It stays declared on the azure_openai and openai backends, where a project holding its own key reaches it as before.
• ModelDeck.final_validate is removed: it raised when a preset's temperature differed from its model's fixed temperature, but it had had no caller since 2025-09-17 and its except clause could never match the exception its helper raised, so it protected nothing.

[v0.61.0] - 2026-09-20

Added

• Claude Opus 5, Claude Fable 5 and Claude Fable 5.1 join the Anthropic backend, and Opus 5 the two hosted profiles: claude-5-opus, claude-5-fable and claude-5.1-fable are served on Anthropic's own model ids, and all three are reachable on Pipelex Manifold through Bedrock's global.anthropic.* endpoints, the way every other Claude already is. Only Opus 5 is served on the Pipelex Gateway: Bedrock refuses both Fables through Portkey with data retention mode 'default' is not available for this model, a mode no model spec can set, so listing them there would publish handles that fail on every request. All of them take text, images and PDF, cap output at 128k tokens, and think adaptively with the temperature parameter refused. Fable 5.1 additionally declares structure_method = "instructor/anthropic_reasoning_tools", because it rejects the forced tool_choice that the backend's default instructor/anthropic_tools sends and structured output fails without it.
• The GPT-5.6 series and GPT-6 Astra are served on OpenAI, Azure OpenAI, the Pipelex Gateway and Pipelex Manifold: gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna and gpt-6-astra are registered on the two direct backends and, through the remote config, on both hosted routing profiles. All four take text, images and PDF, produce text and structured output, and reason under thinking_mode = "manual" with a fixed temperature of 1. The Azure entries carry the dated deployment ids the hosted profiles also use as their wire model ids.

Changed

• add-model skill follows the model's nearest sibling: the skill derives which backend TOMLs, test collection and deck entries a new model belongs in from the model it succeeds, instead of a fixed provider-to-backend table, and checks each backend actually serves the model. It takes the model's facts from the provider's own documentation with OpenRouter as a cross-check, hands the live tests to /test-model with a test class per declared capability, and adds the deck and changelog steps and make ugm once the gateway catalog carries the model.

Removed

• The superseded GPT generations are retired from the rosters we ship (Breaking): the GPT-4.1 series, the o1, o3 and o4 reasoning models and the GPT-5, GPT-5.1 and GPT-5.2 generations are gone from azure_openai, from openai — which also loses gpt-3.5-turbo, gpt-4, gpt-4-turbo, the codex variants of those generations and the dated gpt-4o aliases — and from the gateway and manifold catalogs. o4-mini is retired from portkey in the same pass, since no other backend served it. None of them is unsupported: they are unlisted, and a project that still wants one keeps it by declaring it in its own backend config. What genuinely retires is their availability on the Pipelex Gateway and Pipelex Manifold, where the roster is ours. gpt-4o and gpt-4o-mini stay on both direct backends; the retired names that portkey and blackboxai still declare remain reachable through those, and openrouter's bulk third-party catalog is untouched.

Fixed

• Claude Sonnet 5 is priced at its standard rate: claude-5-sonnet carried the $3 / $15 per million tokens it was announced at, but its $2 / $10 introductory rate became the standard price and the scheduled increase was cancelled. The entry is corrected on the Anthropic backend and in both hosted catalogs, so cost reporting and budget ceilings no longer overstate a Sonnet 5 run.
• A failed publish can be recovered without damaging what already shipped: publish-pypi.yml scopes the signature upload to dist/*.sigstore.json so it no longer clobbers the wheel and sdist attached just before it, turns skip-existing on for a re-run or a manual dispatch, and refuses to touch a release whose tag names a commit other than the one being published. A retry no longer rebuilds the dists either: the build job asks PyPI what this version published and recovers those bytes from the first place that holds them — the build an earlier attempt of this run stored, an artifact an earlier run stored for the same commit, or the files PyPI itself serves — building fresh only when PyPI answers that nothing was published under this version. Whatever it holds is then checked to be one wheel and one source tarball of the version being released and, when PyPI serves that version, byte-for-byte what PyPI publishes, so the release assets are the bytes PyPI serves rather than a rebuild that probably matches them. The release is now tagged at the commit it ships, named explicitly with --target, rather than at the default branch's head.
• A generated image is stored under its own media type, so a store no longer serves it as binary/octet-stream: GeneratedContentFactory.make_image_content resolves the effective mime type once and already used it to mint the storage key's extension, but passed no content_type to StorageProviderAbstract.store on either the direct-bytes path or the fetched-remote one. The S3 provider only sets ContentType when it is given one, so every generated image landed untyped and S3 answered binary/octet-stream on the way back out — which reached any consumer that trusts the stored type, a same-origin assets route serving the object to a browser among them. Both calls now pass the resolved mime type, so the key's extension, the object's stored type and the reported mime_type cannot diverge.
• A generated image fetched from a remote URL is stored under the media type that URL served: GeneratedImageRawDetails admits a bare URL with no mime type and no image format on the promise that the type is settled when the bytes are downloaded, and nothing kept that promise — the fetch discarded the response's Content-Type and the resolution fell through to the requested image format or to a hardcoded image/jpeg. The new fetch_file_and_content_type_from_url_httpx reports the declared type alongside the bytes, normalized and with its parameters stripped, and the factory stores under any image/<subtype> it names — not merely the formats ImageFormat can itself produce, since what this runtime generates is a different question from what a remote URL may serve, and a GIF or an AVIF stored as image/jpeg is the very error being removed. The storage key's extension follows that subtype so it keeps agreeing with the stored type. A type the caller declared still wins, and a served type that is not an image at all — the text/html of an error page dressed as a 200 — is dropped.
• A remote image that fails to download degrades to its URL instead of failing the pipe: make_image_content guarded its fetch with except (httpx.HTTPStatusError, httpx.RequestError), but fetch_file_from_url_httpx converts every httpx failure into RemoteFileFetchError, so that clause caught nothing and a 404 or a timeout on a remote image propagated out and failed the whole run. The guard now names the exception the fetch actually raises, and the fallback it was written for — log the warning, keep the remote URL — runs.
• A remote fetch honours a timeout again: fetch_file_from_url_httpx passed its request_timeout straight to httpx, and httpx reads an explicit timeout=None — the parameter's own default — as no timeout at all rather than as its client default. Every caller that did not name one therefore had no timeout, so a hanging server blocked the caller indefinitely and the TimeoutException branch that raises a caller-facing RemoteFileFetchError was unreachable. The helper now passes httpx's USE_CLIENT_DEFAULT sentinel where no timeout was asked for.

• A manifold error on the native routes keeps its request id under the gateway's pipelex-spelled trace header: extract_manifold_metadata reads the gateway's trace id from x-pipelex-trace-id before the inherited x-portkey-trace-id, still preferring a provider's own x-request-id over both. The gateway emits the two spellings with the same value today, so nothing changes yet; once it drops the vendor one, such an error whose provider sent no x-request-id keeps a request id instead of reporting none. extract_gateway_metadata is unchanged and still reads the vendor spelling alone — it serves the Portkey cloud and the manifold image path, which travels on portkey_ai and keeps that spelling until it is ported off the SDK.

• The License page names the versions the Elastic License 2.0 starts at: the page said ELv2 applies "for every version released after 2026-09-14", which left the first ELv2 releases outside the boundary it drew, since all three were released on that very day. It now names them instead of dating them — pipelex from v0.58.0 onward, pipelex-api from v0.24.0 onward and @pipelex/mcp from v0.15.0 onward — and spells out the last MIT version of each.

[v0.60.0] - 2026-09-19

Changed

• A dump of a working memory names each stuff's concept by ref (Breaking): every path that serializes a Stuff — model_dump, smart_dump, dump_for_transport, the working_memory.json a run saves, the agent CLI's --with-memory envelope and the runner's PipeOutput response — now emits "concept": "<domain>.<Code>" beside stuff_code, stuff_name and content instead of the full Concept object. A dump is one-way: a Stuff, a WorkingMemory or a PipeOutput cannot be validated back from its own dump, because the definition no longer travels with the data. Every consumer that read concept.code, concept.domain_code or concept.structure_class_name off a dumped stuff must read the ref string and resolve it instead.
• A transported stuff's concept is resolved through the loaded library (Breaking): one shared rule matches the ref against every entry the library holds for that spelling — the host or native concept keyed by the ref itself, plus each concept a dependency package contributed, which the library keys under that package's address. One match resolves, none refuses naming the ref, and a spelling that a host bundle and a dependency both declare refuses naming every key that matched, rather than binding one package's definition to the other's data. Outside any library scope the readers answer from the pinned native set alone, so a delivery worker that never loaded the crate now renders a bundle-declared concept as a raw dict where it previously got a typed render from the definition on the wire.
• ConceptProviderAbstract and ConceptLibraryAbstract gained abstract methods (Breaking): a provider must now implement list_concept_keys_for_ref, and a concept library must implement add_dependency_concept. An out-of-tree implementation of either fails to instantiate until it does.
• The agent CLI's stdin resolver passes the concept ref through with its domain intact (Breaking): it used to reduce the concept object to a bare code, which let a bare code match any domain's concept of that spelling. A --with-memory envelope therefore pipes into a receiving method only where that method declares the same <domain>.<Code>; the looser behaviour silently bound one domain's definition to another domain's data. A concept the resolver cannot accept is reported under the new error_type StdinEnvelopeShapeError — the envelope parsed, so labelling it JSONDecodeError sent readers hunting for syntax errors in valid JSON.

Note the limit: the MTHDS standard also defines <package_address>::<domain>.<Code> for a concept a dependency contributes, and this runtime neither emits nor resolves that form.

Fixed

• PINNED_NATIVES_MTHDS_VERSION names the set it labels: the constant read 1.0.0 while the standard pins the native set at 2.0.0, so anything taking it as the answer to "which pinned set is this engine's" — a downstream port gating its own native goldens, for one — read a version the standard now describes as predating the pinning regime. It now reads 2.0.0, and it is no longer a value nothing reads: the standard-conformance suite holds it to the page's own "Pinned at MTHDS" statement, and a check that needs no sibling checkout refuses a label later than the standard version this engine implements.

[v0.59.0] - 2026-09-16

Added

• pretty_print_mode in [runtime.log] (Breaking): rich (the default), poor or silent, applied at boot beside log_mode, so a host with no console turns the "Output of pipe" panels off in configuration rather than in code; a silent printer builds no Rich renderable at all. Boot now replaces a PrettyPrinter.mode assigned in code before it, so set the key instead, and teardown restores whatever mode the process held before that boot. pipelex doctor applies the key too.

Changed

• Remote inputs are checked the way the web checks them (Breaking): an http(s) URL on a Document or Image input is only checked for syntax when the inputs are shaped, and refused with PipelineInputUrlInvalidError when it does not parse. Whether the resource exists is decided by the operator that fetches it, which raises a caller-facing RemoteFileFetchError naming the URL and the answer it got, instead of a raw httpx error. The pre-flight HEAD probe is gone: on the hosted runner a host that stalled it could end a run TIMED_OUT with no error. A local file path must still exist before the run starts.
• The User-Agent is Pipelex/<version>: the (https://pipelex.com) suffix is gone, because the crawler-style URL in parentheses is what bot walls key on, and sites that stalled the old string serve the new one promptly.

Fixed

• Poor pretty-print mode: a panel whose title is wider than the terminal no longer hangs the run in an endless wrapping loop, which every "Output of pipe" panel did on an 80-column headless console; an over-wide title is elided instead. Titles print without their Rich markup, a title in square brackets no longer raises, and an output prints as its plain rendering rather than a Rich object's repr.
• A trace event log the current models refuse is no longer read as an empty one: an event written by a version whose event shape this one no longer accepts now makes the read refuse with a count and a reason, instead of being skipped and the remainder reported as a success; such a run reports neither its graph nor its usage and cost total, each with its assembly error set. A line that is not JSON, left by a crash mid-write, is still skipped with a warning. pipelex graph render gives the same diagnosis for a graph spec saved by an earlier version instead of a raw traceback.

Removed

• The text and HTML renderings of traced data (Breaking): stuff_text_content and stuff_html_content under [interpreter.pipeline_execution.graph.data_inclusion] are gone, along with a graph IOSpec's data_text and data_html and the unused PrettyPrinter.pretty_html and PrettyRenderable.rendered_pretty_html. Runs no longer pay for rendering every traced input and output on the execution path, and the Mermaid graph page now shows a data node's JSON, with a preview for image and PDF content. A graph spec saved by an earlier version is refused when read back; run the pipeline again to get one in the current shape. Migration: run pipelex migrate — ledger entry pipelex-config@4 deletes both keys from ~/.pipelex/ and from every project .pipelex/ file, keeping one timestamped backup per file.

Security

• escape_script_tag escapes every <: the filter only matched the literal </script>, so </script > and </script/> closed an embedded JSON block and let the rest of the value parse as live HTML. Every < is now escaped as \u003c, which guards the graph and stuff viewer pages that embed model-generated traced content.

[v0.58.0] - 2026-09-14

Changed

• License (Breaking): pipelex is now licensed under the Elastic License 2.0 (ELv2) instead of MIT, and the package metadata declares the SPDX expression Elastic-2.0 in place of the MIT license classifier, which makes hatchling 1.27 or later a requirement for building from source; every earlier version, up to and including v0.57.0, stays under MIT. ELv2 is source-available: you may embed pipelex in your own products, including services you offer to others whose features run your methods, and in your internal tools, while its main limitation rules out hosting a service that runs methods for others, whether they send the methods or pick them from a catalog. LICENSE carries the full terms, including its conditions on notices and redistribution, and the License page on docs.pipelex.com explains how Pipelex reads them.

Security

• Docs site built on mkdocs-material 9.7.7: the docs extra now requires mkdocs-material>=9.7.7, which closes a DOM XSS in the theme's search suggestions (GHSA-xvg9-69gf-fjrf) that the published site shipped. The pull-request documentation check now builds from uv.lock like the deploy does, instead of from its own hand-pinned theme versions.

[v0.57.0] - 2026-09-07

Added

• A run's results carry the I/O artifacts that describe its data: beside graphspec.json, and gated by the same graphspec_json inclusion flag, a run now writes pipe_io_contracts.json, input_form.json and output_form.json — the validation report's own artifacts under the standard's names, keyed by namespaced pipe_ref for every pipe of the library the run executed against. Until now only /validate produced them, so a consumer of a run's graph either took the no-data floor or paired the graph with a validation of some other bundle text, and a graph viewer shows a data node's value only when it holds the contracts and the output form. They ride on PipeOutput.pipe_io_artifacts beside graph_spec, with a build failure of any kind landing on pipe_io_artifacts_error rather than failing the run or skipping its delivery, and the SPI payload carries them as pipe_io_artifacts_dump. pipelex run, pipelex-agent run and the direct-mode delivery executor all write them, while a run hosted on our Temporal plugin still writes graphspec.json without its siblings. See Execution Graph Tracing.
• The --version handshake reports three numbers (Breaking): pipelex --version and pipelex-agent --version now print the runtime version, the MTHDS Protocol version and the MTHDS standard version, one <label> <version> line each, instead of the runtime version alone. The three move on independent cadences under the standard's own versioning rule, so none can be inferred from another, and the two MTHDS numbers are read from the mthds package rather than restated here. The first line keeps its historical <program> <version> form, so a consumer that matches a version out of the text is unaffected — but one that treats the whole of stdout as a single version string now holds three lines, so match on the label rather than on the shape of the output. See CLI Reference.

Changed

• The MTHDS standard version this runtime implements is now 2.0.0 (Breaking): mthds moves to ==0.14.0, whose MTHDS_STANDARD_VERSION was cut from 1.0.0 to 2.0.0 — the standard's first cut under its own versioning rule, accounting for breaking changes to the native set and to the manifest, lock and resolution rules that had already shipped unversioned. Two things follow for users, and no pipelex line caused either: every normalized crate this engine emits is stamped 2.0.0 instead of 1.0.0 (crate fingerprints are unaffected, because mthds_version is excluded from the hashed payload by design), and a METHODS.toml whose mthds_version pinned the old major, such as ^1.0.0, now warns where it did not before, while a plain floor like >=1.0.0 is still satisfied. The protocol version is unchanged at 0.6.0, and the pin stays exact, so a consumer depending on mthds directly must move in step.
• The Commands section of the shipped agent rules is a compact list: pipelex/kit/agent_rules/commands.md drops its long-form headings and code blocks for one bullet per gate — the target, its alias, when to run it and where the full rationale lives — so the CLAUDE.md that make rules generates from it costs a session a third of what it did. It also now records the one thing a session could not learn from the file itself: that CLAUDE.md and AGENTS.md are generated, that make rules is how they move, and that make check-rules is a CI gate make agent-check does not run.

Fixed

• The codegen stamp reference no longer understates what moves a fingerprint: Codegen Projections said a stamp moves only when a method's effective type surface changes, which would have a reader mistake an ordinary restamp for drift and expect a prompt edit to leave the generated tree alone. The crate fingerprint is computed over the whole normalized crate — concepts, pipes and domains — so an edited system_prompt or a swapped model restamps every generated file exactly as a renamed concept field does, with the body below the fence byte-identical. content_hash, in the stamp header and in the lock's artifacts[] entries, is what distinguishes that harmless restamp from a real change to the generated code.
• Compound version constraints written the documented way now parse: parse_constraint stripped no whitespace around the comma that ANDs a compound constraint's clauses, so >=1.0.0, <2.0.0 — the exact spelling of the MTHDS standard's own example — was rejected while the identical >=1.0.0,<2.0.0 parsed. A manifest's mthds_version written that way therefore got no compatibility check at all, since the load path degrades an unparseable constraint to a log line. A malformed compound such as >=1.0.0,,<2.0.0 still fails, because normalizing whitespace must not repair a broken constraint.

[v0.56.0] - 2026-09-03

Added

• Pipelex Manifold (private beta): pipelex_manifold joins pipelex_gateway in backends.toml as a second Pipelex-operated inference backend, with a matching all_pipelex_manifold routing profile. It ships disabled; since both services share model handles, switching the profile is the whole change. A new provider package supplies the manifold sdk set (manifold_completions, manifold_responses, manifold_img_gen, manifold_extract, manifold_search), the backend declares the service origin with no /v1, and the service token travels on the x-pipelex-api-key header on every protocol. Per-model local overrides work through backends/pipelex_manifold.toml exactly as they do for the gateway.
• Personal configuration overrides: backends_override.toml and routing_profiles_override.toml sit beside their base files under .pipelex/inference/, are git-ignored, and deep-merge over the base — the global ~/.pipelex/inference/ one first, the project's one last — so a developer switches backends locally without touching a tracked file. Every reader sees the merged document: the boot, pipelex show backends, and the doctor's rows. The .pipelex/.gitignore that pipelex init writes now lists every personal override file. See Personal overrides.
• Fetch-on-miss for methods: a bundle referencing a method by address (github.com/...->domain.pipe) that misses the installed methods now fetches the package, honoring an @<tag> pin, installs it into ~/.mthds/methods/ with provenance recorded beside the manifest, and loads it. A miss that cannot be bridged raises an error naming the address and the remedy instead of passing silently. Disable it with [interpreter.methods] fetch_on_miss = false or PIPELEX_METHODS_FETCH_ON_MISS. See Include by Address.
• TypeScript emission gates: make test-ts-gates (alias ttg) provisions a pinned prettier and zod into .ts-toolchain/ and runs the codegen suite with PIPELEX_REQUIRE_TS_GATES=1, under which the two tests that read the emitted TypeScript as TypeScript fail instead of skipping. The same target runs as a required CI job. See TypeScript Emission Gates.
• Output-form descriptor: the validate report carries an output_form beside pipe_io_contracts and input_form, and the output contract carries a json_schema, closing the asymmetry between a pipe's two halves. build_output_form projects the same concept derivation the inputs use, wraps a plural output as a list node, and publishes the payload's schema (ListContent[...] on the plural arm, with minItems/maxItems on a fixed count). See Pipe IO Contracts.
• Projection fixture corpus: pipelex-dev generate-projection-corpus writes the shared fixture corpus that pins the TypeScript and Python inputs-template projections byte-for-byte against each other, records every declared divergence from the engine's own renderer, and round-trips every template it pins through the input shaper so a template the runtime would refuse cannot be captured unnoticed (EXPECTED_UNSHAPEABLE declares the known gaps). The corpus covers the open-shaped natives, an outputs bundle, and nested and plural file slots. See Projection Fixture Corpus.
• bump-kajson skill: a Claude skill and helper scripts that move the kajson pin, re-lock, adapt the engine and write the changelog entry.
• .worktreeinclude: the gitignored files a fresh worktree of this repo needs (.env, the personal .pipelex/ overrides, .pipelex-dev/test_profiles_override.toml) are declared in a tracked file, read by Claude Code and by the workspace's wt tool.

Changed

• Inference error domains (Breaking): InferenceErrorCategory gains an error_domain property and the whole CogtError family derives its domain from it, where it declared none. A content-classified failure — a provider policy refusal, a malformed prompt image, a bad prompt parameter, every provider HTTP 400 — now answers HTTP 422 instead of 500 on any surface reading ErrorReport.http_status. ModelChoiceNotFoundError declares input on the class itself. See Error Model.
• Gateway refusals classified: the Pipelex inference gateway's own refusals no longer fall through to the generic provider-error ladder. Three families carry their own classification, keyed on the gateway's error code rather than the reporting provider, and none is retried: request limits (a body or storage object over its cap, nesting past the depth limit), unresolved references (a storage key or URL the gateway cannot turn into bytes, a host the SSRF guard refuses), and routing refusals (a model the deployment does not serve, an integration switched off). Routing refusals are CONFIGURATION throughout, so they answer 500 rather than 422, and a model the gateway does not serve raises the same availability error a deck miss does. ClassificationResult gains gateway_request_limit, gateway_unresolved_reference and gateway_routing_refusal. See Error Model.
• Managed gateways by declaration (Breaking): a backend is Pipelex-managed when it declares a model_specs_section, not because it is named pipelex_gateway; more than one can be live, and the published configuration is fetched once and sliced per backend. A managed backend whose ${…} variables do not resolve is disabled with a warning naming it, while bring-your-own-key backends keep failing the boot loudly. Service-terms acceptance is asked for any enabled managed backend, and declining disables all of them. is_gateway_backend is gone, the backend loader takes managed_gateway_configs, and GatewayUnknownModelError names its backend.
• Inference loaders take a path sequence (Breaking): InferenceBackendLibrary.load, load_active_routing_profile and ModelManager.setup take a sequence whose first path is the base file and whose rest are the overrides in merge order, built by ConfigLoader.backends_file_paths() / routing_profiles_file_paths(); is_pipelex_gateway_enabled takes a config_dir. The routing loader now raises RoutingProfileLibraryNotFoundError and RoutingProfileDisabledBackendError, the classes the boot already caught, and a file that does not parse or a backend that is not a table fails as InferenceBackendLibraryValidationError naming the file.
• Remote config pin: the default moves to pipelex_remote_config_13.json, the first artifact carrying manifold_model_specs. Its backend_model_specs are identical to version 12's, so the Portkey-cloud path reads what it read before.
• Dependencies: mthds moves to ==0.13.0, which carries the output-form descriptor, and kajson to ==0.7.1, whose register_classes_dict({}) no longer raises on an empty snapshot.

Removed

• InferenceBackendLibrary.check_backend_credentials and CredentialsValidationReport: the method had no caller and read the base backends.toml alone, blind to the new override files. The doctor's credentials row does the same job over the merged document.
• DocumentFormat: the enum and pipelex/tools/misc/document_utils.py are gone; nothing in the engine imported them, and filetype_utils.py already carries the MIME and extension knowledge (Breaking for anyone importing the symbol).

Fixed

• Class registry isolation: structure classes generated for one library could leak into another load in the same process — a later bundle silently reused an earlier bundle's structured concept of the same name, and two interleaved loads overwrote each other's registration. Every Library opened through LibraryManager.open_library now gets its own ClassRegistry, seeded from the global one, so a load's classes live and die with it. A structure class every load must see has to be registered before any library is opened. See Per-call scoping.
• Pre-boot registry starvation: a class-registry read before boot instantiated the kajson singleton around an empty registry, and the boot then handed that manager back and discarded its own, so the core models landed where nothing resolved. Any pre-boot manager is now dropped before the boot constructs its own.
• CLI error reporting: an unknown or ambiguous entry pipe_code and a typo'd --pipe / pipe_ref slice selector now raise EntryPipeNotFoundError / EntryPipeAmbiguousError, which carry the INPUT domain and answer 422 instead of 500; both subclass the classes they replace, so every existing catcher still matches. --help works again on every method subcommand, where the address example's brackets reached rich's markup parser unescaped.
• TypeScript codegen stability: a dict-valued default, a key or string carrying a double quote, and an exploded choice list containing a comma or a bracket each produced a types.ts that prettier rewrote or that did not parse, so pipelex codegen check reported an untouched file as hand-edited. Defaults render as TypeScript literals, every target emits the quote style its formatter keeps, and every line-break split walks string literals. An always-on invariant asserts no emitted line ends inside an unterminated literal.
• Zod wire agreement (Breaking for generated TypeScript — regenerate): a non-required field was projected as .optional(), which rejects the explicit null the runtime serializes for an unset field. It is now .nullish(), or .nullable().default(…) where it carries a default, and parsed optional fields type as T | null | undefined. The emitter's line-breaking now models prettier's member-chain rule. See Codegen Projections.
• Native concept handling: a native.Anything input no longer crashes the pipe-IO contract builder — it publishes a permissive schema and renders {} in a template; a native.JSON input renders {"json_obj": {}} from its pinned structure instead of an empty object the runtime refused; and a native.Dynamic input referenced in a PipeLLM or PipeImgGen prompt no longer fails dry-run validation demanding ImageContent, since a dynamic concept gets no static image or document classification and renders as text. See PipeLLM.
• Input-form descriptor for class-backed concepts: a concept declaring structure = "SomeClass" collapsed to unknown the moment one field annotation could not be mapped, hiding every document and image position beneath it. Reflection is now field by field: an unmappable annotation is unknown at that field alone, a nested model is walked into, and a RootModel reports its root annotation. See Input-Form Descriptor.
• Projection corpus divergence gate: the gate that declares every engine/projection difference missed fields the projection stopped rendering, absorbed a regressed file placeholder into an existing class, and could not tell an honoured Concept[N] from a wrong count. All three now refuse, and a pipe declaring no inputs is captured from the projection alone instead of aborting the run.
• Doctor: pipelex doctor reported a false backend-configuration error for pipelex_gateway on a stock install, because the Backend Files row loaded the library strictly with no gateway config, and that first failure hid real errors in later files. The row now loads leniently, the loader stamps backend_name on every error it raises about one backend, and both rows charge a failure to the backend it declares rather than to any backend whose name appears in the message.
• Strict disclosure leak: PipelineInputContentError declared its caller-facing flag under the wrong name, so the message a caller needs on a missing url was redacted under STRICT disclosure while the unreadable-local-path message would have leaked. The family is split: PipelineInputUrlMissingError is caller-facing, and PipelineInputContentError stays redacted.
• HtmlContent JSON rendering: rendered_json emitted html where the standard's pinned concept requires inner_html. The override is deleted and the rendering is the model's own dump.
• Generated-image storage keys: the key's extension followed the requested image format while mime_type followed the provider's actual answer, so the two could disagree. Both now derive from one resolved mime type.
• Agent-rules templates: the generate-projection-corpus entry was written into the generated repo-root CLAUDE.md instead of its template, leaving make check-rules red on dev. It now lives in pipelex/kit/agent_rules/commands.md and its Codex twin, and the check runs in CI as lint-agent-rules.

[v0.55.0] - 2026-08-29

Added

• Run a method by address: every command that resolves a method target (pipelex run method, pipelex validate method, the pipelex build method commands, and their agent-CLI twins) now accepts a method reference <address>[@<tag>] — github.com/<owner>/<repo>[/<selector>], optionally pinned at a git tag (a @<name> that names a branch rather than a tag is refused, so only tags pin a revision) — alongside installed names, local paths, and full GitHub URLs. The new pipelex/methods/ package is the single implementation the CLI, the API, and tests all share: the MethodRef grammar parser, fetch-at-tag (wiring the mthds clone_at_version machinery beside clone_default_branch, with the fetched commit SHA always resolved and reported as provenance), package location inside the clone by manifest identity (scan for METHODS.toml, match the full address, case-insensitively; a miss or ambiguity is a loud error listing the packages the clone contains), env-tunable fetched-package ceilings (file count and total bytes, plus a bounded manifest scan — a size cap per METHODS.toml read and a cap on manifests considered per repository), and the reusable structures-refusal check — an alias-aware AST scan for StructuredContent subclasses (bases reached through import ... as aliases and attribute access are caught alongside the literal name) producing the rule-naming error (hosted execution accepts MTHDS concepts and sandboxed PipeFuncs, not in-process Python), which the CLI surfaces as a hosted-parity warning and a hosted runner can apply as a hard refusal. A fetched target's default outputs (run results, graphs, generated files) anchor in the caller's working directory — the fetched clone itself is ephemeral and deleted at process exit — build runner additionally copies the fetched package beside the generated script so the runner stays self-contained, and a method-reference failure reaches the agent CLI as its structured error envelope, like every other agent-CLI error. See Run a Method by Address. (Breaking: bare github.com/... targets no longer resolve as local paths, and packages inside a fetched repository are located by manifest identity rather than directory path — /tree/<branch>/<dir> deep links now resolve through the manifest's address/name.)

Changed

• Structure-class-not-found diagnostics teach the missing-module case: when a concept's declared structure class does not resolve (ConceptStructureClassNotFoundError, and the corresponding PipeFunc output validation error), the message now states that the class may live in a Python module that was not part of the request, and suggests including the module or expressing the type as MTHDS concepts.

Fixed

• Blueprint serialization schemas: ConceptBlueprint, ConceptStructureBlueprint, InputSlotBlueprint and ConstructBlueprint publish their real shape again in serialization mode. Each carries a @model_serializer(mode="wrap") annotated -> dict[str, Any], and pydantic turns a serializer's return annotation into the model's serialization JSON Schema in preference to the one it would generate — so all four came back as an opaque {"type": "object", "additionalProperties": true} with no properties, no required and no closed shape. This is the same annotation mthds 0.11.1 dropped for the input-form field descriptors. Nothing here noticed, because validation-mode schemas and model_dump() were both correct throughout; the damage landed in consumers that generate response-model schemas, which FastAPI always does, so a downstream OpenAPI artifact regains its field-level detail on its next pipelex bump. A new sweep test holds every Pipelex model to the rule, and the agent rules now scope "every function return must be typed" so a serializer's return stays unannotated.

[v0.54.0] - 2026-08-28

Added

• MTHDS standard conformance CI: A new test holds the pinned native-concept set (pinned_blueprints.py) to the standard's own native-concepts.md, read from a sibling mthds checkout — definition for definition, field for field, order included. The mthds-standard-check.yml workflow checks the standard out at its default branch and runs it on every pull request, so the day the standard moves a definition this repo goes red instead of a downstream port.
• bump-mthds Claude skill: A skill (with its upstream_notes.py helper) that automates moving the mthds dependency: it finds the latest release, re-locks, adapts the engine source to what the release broke, runs the checks and drafts the changelog entry.

Changed

• mthds is pinned exactly to ==0.11.1 (previously >=0.8.2). Everyone downstream of Pipelex inherits that exact version, so a consumer that also depends on mthds must now move in step with Pipelex rather than resolving its own. (Breaking)
• Multiplicity [1] is strictly singular: a count of one (e.g. Concept[1]) is universally the single form, not a one-item list. A [1] input takes the value itself and refuses a list, a [1] output produces one object rather than a ListContent of one, a re-rendered ref canonicalizes back to Concept, and a presence marker beside a count of one (Concept[1]?) is accepted on inputs as it already was on outputs. A sequence declaring a plural output whose last step yields one no longer validates, and Concept[0] is rejected at parse time with a validation error instead of surfacing later. See Understanding multiplicity. (Breaking)
• native.Html.css_class is now optional (str | None), matching MTHDS v0.9.0. An Html value is its markup, and the class is presentation a producer states when it has one — composed HTML and JSON rendering no longer fabricate an empty css_class, and structured output no longer forces a generating LLM to invent it. (Breaking)
• Input-form descriptors and pipe I/O contracts are typed by the standard now: both artifacts' wire models are imported from mthds.protocol instead of being restated here, and re-exported from pipelex/pipeline/input_form.py and pipelex/pipeline/pipe_io_contracts.py. The wire is unchanged; what moved is which package declares the shape. Importers are affected three ways: a field descriptor is one model per kind (TextField, ObjectField, …) under an InputFormField union discriminated on kind, narrowed with isinstance or match rather than read off a flat model, so FieldKind.is_list and FieldKind.is_object are gone; the date kind's Python attribute is now datetime, the name it always had on the wire, rather than datetime_flag; and the item layer is a distinct InputFormItem union (TextItem, ObjectItem, …) that structurally forbids the name a list item never had, renaming InputFormFieldBase to InputFormItemBase and TextValuedFieldBase to TextValuedItemBase. See Input-form descriptor and Pipe I/O contracts. (Breaking)
• native.Date and native.Html are object nodes in the input-form descriptor, with fields derived from their pinned definitions, rather than the former date and prose scalars — which reported shapes the slots' own schemas rejected. (Breaking)
• PresenceMarker is imported from the standard, so the three helpers that are this engine's .mthds suffix grammar rather than wire vocabulary became module-level functions in pipelex/core/pipes/variable_multiplicity.py: presence_from_symbol, presence_symbol and is_force_presence, all keyword-only. is_optional and is_plain stay properties on the enum. (Breaking)
• Input-form descriptor conformance: a description-only concept's refines now carries only the authored chain and no longer fabricates the native.Text link the spec forbids reconstructing — text-valuedness still reaches the wire as kind: "prose".
• TypeAdapter agent rule refined (pipelex/kit/agent_rules/python_standards.md): the flat ban becomes a scoped one. Don't design shapes that need a TypeAdapter, but validating into a top-level union or container owned by an external contract — a standard's wire model, a log stream of one-of-many event types — is its sanctioned use, as a module-level singleton.
• Bumped pyright to 1.1.411. The release narrows hasattr() on an Any or type[Any] operand to type[object] instead of leaving it wide, which turned two duck-typed guards into type errors; both now test what they mean — issubclass(..., BaseModel) before calling model_validate, and typing.get_origin instead of reaching for __origin__.

Fixed

• Input-form field serialization: mthds 0.11.1 drops the -> dict[str, Any] return annotation from the wrap serializer every field descriptor shares. Pydantic preferred that annotation over the schema it would generate, so TextField.model_json_schema(mode="serialization") and each of its siblings came back as an opaque {"type": "object", "additionalProperties": true} — the mode a server generating response-model schemas asks for, so a FastAPI consumer embedding PipeInputFormDescriptor published a kind-discriminated union whose arms described nothing. The per-kind shapes are back.
• Sequence output enrichment: a sequence step with nb_output = 1 on an optional boundary no longer drops the optional marker (?) during fix planning.
• Parallel pipe output validation: a plural branch with nb_output = 1 no longer bypasses type checking, which previously let an incompatible singular result through to crash at run time.
• Image generation multiplicity: PipeImgGen honors an output_multiplicity=1 run-time override, generating a single image instead of refusing it as unresolved.

[v0.53.0] - 2026-08-25

Added

• Vacuous-presence lint (input_presence_vacuous): New advisory warning that fires when a required method input (declared without ?) points to a concept with no required fields, since an empty object {} already satisfies it. Scoped strictly to entry pipes (the bundle's declared main_pipe), the message suggests either marking the input optional (?) or adding a required field to the concept. See Understanding optionality and Inline structures.
• Unified advisory-warnings module (pipelex/pipeline/advisory_warnings.py): A single composition point that assembles all advisory warnings (optionality, vacuous-presence, and intent-hints) in a fixed, deterministic order.
• Corpus vocabulary exclusion: Added the input_presence_vacuous exclusion to the corpus vocabulary generator (generate_corpus_vocabulary_cmd.py).
• Documentation: Updated the user guides (Inline structures, Understanding optionality, validate) to cover the new lint, its remedies, and the unified warning channels.

Changed

• Consistent warnings across all channels: Every whole-bundle validate channel (protocol report, agent CLI, builder operations, and the bare CLI's validate bundle and validate --all) now carries the exact same set of advisory warnings. Previously, channels showed different subsets — intent-hints were missing from the CLI, for instance. To keep output manageable, intent-hint findings are capped per site (five before collapsing into an "...and N more" message) and long authored tokens are elided at sixty characters.
• Library manager interface (Breaking): LibraryManagerAbstract gained a new abstract method get_accumulated_blueprints(), which the collector reads to find the entry pipes. Any custom library manager injected via Pipelex.setup(library_manager=...) must implement it or fail loudly at construction.

Fixed

• Bare CLI warning visibility: The bare CLI's validate bundle command now prints its advisory warnings before the strict pending-signature gate exits. Previously, a bundle with an unimplemented placeholder would exit non-zero and swallow the warnings — which is exactly the state an author is in while building a method.
• Empty structure table parsing: An authored but empty [concept.X.structure] table is now correctly parsed as an object with an empty fields list, instead of falling through a truthiness check and being described as prose refining native.Text.
• Field-less structure class reflection: A registered Python class declaring no fields is now reflected as an empty object rather than unknown. Genuinely unmappable annotations still correctly report as unknown.
• Domain splitting in locators: Hierarchical domains such as legal.contracts are now split at the last dot rather than the first when building advisory-warning locators.
• Release workflow no longer loses the tag when signing fails: The GitHub Release is created, and the dists attached, before the Sigstore step, which is now allowed to fail without failing the job. The tag exists only as a side effect of creating the release, so a refreshed Sigstore trust root previously cost the tag and the release page while PyPI published normally — as happened to v0.52.0. The action is also bumped to a version carrying a current trust root, and release creation is idempotent so the manual retry path works.

[v0.52.0] - 2026-08-24

Highlights

A pipe's inputs now describe themselves well enough to render a form. The validation report carries a per-pipe input_form descriptor built from the loaded pipes and the authored blueprints rather than from the emitted JSON Schema, so a renderer keeps the concept chain, the presence marker, gating, fixed counts, defaults and choices. pipe_io_contracts drops its boolean flags for a three-valued presence and a real multiplicity, and emitted schemas gained the concept ref as title, the authored description as description, and minItems/maxItems on fixed counts. Alongside them a non-normative hints table lets an author state presentation intent without touching semantics, and authoring got louder: an unknown structure-field key, or a required = true paired with a default_value, is now rejected at parse time instead of silently discarded. Breaking: the contract reshape, those two new rejections, and build_validation_report's new required input_form argument.

Added

• MTHDS intent hints: A non-normative hints table can now be authored on a concept, on a structure field, and on a pipe input slot, with one defined key — intent, over the closed vocabulary prose / label / rating / quantity. Hints travel through the library crate (a concept's effective hints merge along its refinement chain, the nearer declaration winning) and surface on the input-form descriptor, while execution, validation verdicts and pipe contracts never read them. Validation emits advisory warnings (hint_unknown_key, hint_unknown_intent, hint_inapplicable_intent) rather than failing, and unknown-but-well-formed content is preserved. See Intent hints.
• Input-form descriptors on the validation report (Breaking): PipelexValidationReport.input_form maps every pipe_ref to an ordered list of field descriptors, derived by build_input_form from the loaded pipes and blueprints — never from the emitted JSON Schema — so a UI renderer gets the namespaced concept_ref and its refines chain, the three-valued presence, a stated gating fact, fixed counts, authored defaults beside required, and one-member choices lists, with unknown as the honest escape hatch. Class-backed concepts are reflected through the new reflect_structure_class. Breaking: build_validation_report now requires input_form, so every backend assembles it or fails loudly. See Input-form descriptor.
• Richer emitted JSON Schemas: A schema now carries the concept ref as its top-level title — replacing the mangled generated-class name — and the concept's authored description as its top-level description, uniformly for generated, class-backed and native concepts. A fixed-count slot (Concept[N]) emits minItems/maxItems on its array wrap while a variable-length one (Concept[]) stays unbounded, and the native content classes (TextContent, ImageContent, DocumentContent, PageContent, NumberContent, HtmlContent, YesNoContent) gained docstrings matching their pinned native descriptions, so provider-side schemas built straight from the classes carry them too.
• pipelex-dev trace-input-semantics: A capture harness for the chain that turns authored structure syntax into the json_schema on pipe_io_contracts. Given one or more .mthds bundles it dumps per-hop captures — parse blueprint, generated class source, raw pydantic schema, SCHEMA render, wire contract — plus a manifest of each input's wire framing, so a lost or mangled authored fact is localized to exactly one hop. A committed probe bundle exercises every construct the language accepts. See Trace input semantics.

Changed

• pipe_io_contracts learns presence and real multiplicity (Breaking): An input contract now carries presence (plain / optional / force) — the declared marker verbatim — replacing the two-valued optional, so lint and graph surfaces can see where ! assertions live without a presentation view. Input and output contracts both carry multiplicity (single / variable / fixed), with item_count present exactly when fixed, retiring the old ruling that reported a fixed count as variable; the output contract keeps its two-valued optional, since ! is rejected on outputs. See Pipe I/O contracts and Understanding multiplicity.
• Unknown keys in a structure-field table are rejected (Breaking): A typo'd or hopeful key on a concept structure field (minimum, unit, a misspelled hint) used to be dropped at parse while the bundle validated green, silently discarding authored intent. ConceptStructureBlueprint now forbids unknown keys, making the field table strict exactly like an input slot table; hint content stays lenient, since an unknown hint key warns and is preserved. The MTHDS JSON Schema regenerates accordingly, structure-field objects carrying additionalProperties: false. See Inline structures.
• required = true and default_value can no longer be declared together (Breaking): The two are contradictory instructions — a default is applied when the caller omits the field, which makes absence legal — and the generator used to resolve the conflict silently by dropping the required-ness. The pair is now rejected at blueprint validation and at the builder's spec layer, so an authoring agent fails before emitting TOML the parser would reject, with a message naming both remedies. Relatedly, a pydantic default on a hand-written structure class now counts as an authored fact: the input-form descriptor reports such a field as required: false carrying its default, instead of claiming it required and hiding the default.
• Ruff moves to 0.16.4, matching the version the VS Code extension bundles, so a rule can never fire in the editor and not on the command line — an older binary parses pyproject.toml as Python source and paints phantom syntax diagnostics across it. Two mechanical conversions ride along, both applied by ruff check --fix: selector lists in pyproject.toml name rules rather than code them, and # noqa: CODE suppressions became # ruff: ignore[rule-name] with their explanations preserved. The new formatter also reformats Python code blocks inside Markdown, so the docs picked up trailing-comment and blank-line normalization, and rules newly reported under preview are ignored deliberately rather than in bulk, each with its reason recorded beside it. This is a dev-dependency change: nothing shipped changes.

Fixed

• Builder-authored defaults no longer evaporate on re-load: The builder's TOML writer emitted the key default where the language reads default_value, so a default authored through the builder — or through the agent-CLI concept command — validated green and then reached nothing when the file was re-loaded. The writer now emits default_value, a write-then-validate round-trip test pins the survival, and the new unknown-key rejection turns any recurrence of this bug class into a hard failure instead of silent loss.
• pipelex.providers.bedrock no longer imports a type-stub package at runtime: ConverseResponseTypeDef was imported at module level as well as inside the module's if TYPE_CHECKING: block. It resolves only through types-aioboto3, which is a development dependency, so the module-level copy raised ModuleNotFoundError on any install of pipelex[bedrock] without the dev extras. The duplicate is gone and the surviving import is the type-checking one, whose annotation is a local variable annotation and is never evaluated at runtime.
• A usage example in pipelex.test_extras.shared_pytest_plugins had lost its yield: The example fixture in needs_inference_in_pipelex's docstring showed a teardown call with nothing handing control to the test first, its yield line having drifted into a literal Yield: docstring section on a function that only ever returns a bool. The example is a working fixture again.

[v0.51.0] - 2026-08-21

Added

• fails_at on every error.* tag in the MTHDS Test Corpus vocabulary. A non-excluded tag now declares the earliest layer of checking that catches its fault: "schema" when a pass over the raw document's shape already rejects a bundle carrying it (a pipe section with no type key, a type outside the closed set of pipe kinds), "runtime" when the document has to be interpreted to notice. The consumer rule is one sentence: a structural sweep expects a diagnostic on an entry exactly when its tag says schema, and silence on every other entry. generate-corpus-vocabulary computes and injects the field from an internally maintained set of schema faults, so it is never hand-written.

The signal lives on the vocabulary tag rather than on each entry.toml because the layer is a property of the error type: per-entry restatement would let two entries covering one fault disagree, with nothing to catch it. Excluded tags carry no value at all — an excluded tag has no entry, so nothing was measured. Previously every consumer had to hardcode which faults it believed were structural, a downstream re-reading of this repo's validation-error registry guaranteed to drift from it; the corpus now ships the answer in the wheel.

• schema_fault_tags property on CorpusVocabulary. Structural consumers — JSON-Schema sweeps, editor diagnostics, linters — read which faults they are expected to catch instead of maintaining their own list.

• Gates keeping the signal honest. The exhaustivity gate now requires every error.* tag that is owed an entry to declare a fails_at, so a new validation error type cannot land carrying a fault a structural consumer has no way to sweep for. A new test_mthds_corpus_plxt_exclusions.py gates .pipelex/plxt.toml's corpus exclusions against the vocabulary, so the linter config and the vocabulary cannot drift apart.

Changed

• The corpus's deliberately invalid entries are linted again — all but the two whose fault the schema is supposed to reject. .pipelex/plxt.toml excluded the whole invalid_* population behind one blanket glob, because some of those entries carry a structural fault and the config had no way to say which. The exclusion now names exactly the schema-fault entries (invalid_missing_pipe_type and invalid_unknown_pipe_type), and every runtime entry is covered by make lint and make format like any ordinary .mthds file.

That makes this repo the first consumer of its own signal, and it is what keeps the signal measured rather than merely asserted: declare a fault runtime when the schema in fact rejects it and its entry stays linted, so make plxt-lint goes red naming it.

• Documentation. docs/contribute/mthds-test-corpus.md gains a fails_at section covering the consumer rule, why the field sits on the tag, and how the linter config closes the measurement loop. Its invalid-entry authoring warning is corrected to match the narrowed exclusion: only a schema-fault bundle has to be laid out by hand now.

[v0.50.0] - 2026-08-20

Changed

• Breaking: JobMetadata splits its run-constant half into a new RunMetadata. user_id, pipeline_run_id, storage_scope and request_id are constant for a whole run; pipe_code, pipe_run_id, otel_context and content_generation_job_id change at every step. They sat side by side with nothing saying which was which, so a copy made for a nested pipe had to know, field by field, what to carry through. They are now job_metadata.run_metadata.*, and the copy carries one object.

There is deliberately no read-through accessor on JobMetadata: one spelling for one fact. Every call site reads the nested path.

• A pipe's result now carries the job it was produced under. PipeOutput.job_metadata and TracingAssembly.run_metadata are set once at the run boundary, so a transport that offloads an oversized result to storage can key it inside the run's own namespace. Both are private attributes behind properties, not model fields: PipeOutput is on the wire — pipelex-api returns it and publishes its schema — so as a field this would have put user_id, request_id and otel_context into a public API's response body and its documented OpenAPI artifact. A transport reads the value by attribute on the live object before serializing, so it never needed to be on the wire at all.

The gap was one-directional and easy to miss: every payload a run sends in carries a job_metadata to resolve a scope through, and nothing it sent back did. Under a hosted orchestrator that meant the two largest payloads an ordinary run produces — the pipe output and the tracing assembly, both around 350 KB — were stored outside every prefix the host's erasure cascade deletes, and survived deletion of the run that produced them. The same bytes were also stored a second time, correctly scoped, inside the delivery argument that carries them.

Set at the run boundary and not at the ~17 PipeOutput(...) construction sites: only the top-level output crosses a transport boundary, and stamping every constructor to serve one of them is the same "remember to add it everywhere" fragility that caused the original bug. Optional throughout — dry runs, signature stubs and tests build outputs with no job in hand — and invisible on the wire, since serialize_completed_output names the fields it returns explicitly.

[v0.49.0] - 2026-08-20

Added

• The error_type values a validation verdict can carry are now an enumerable, closed registry: a .mthds bundle that fails validation reports each fault under an error_type, and until now there was no way to ask the runtime which faults exist. The values were reachable only by reading raise sites, and the only curated list of them lived outside this repo, in a hand-maintained conformance suite that could silently fall behind. pipelex/validation_error_types.py now holds the vocabulary in full and enumerates it as VALIDATION_ERROR_TYPES, so a consumer building coverage over the language surface — a test corpus, a client mapping faults onto its own UI — reads the registry instead of collecting strings from whichever diagnostics it happened to have seen. It is a union of the enums the runtime already raises, never a second list beside them: the two stage vocabularies plus a new ValidationResidualErrorType naming the one residual channel that had no enum of its own and rode an inline string. A member added to any of them is in the registry the moment it is declared. ValidationErrorItem.error_type is typed against their union, which is what makes the registry closed rather than merely documented — an unregistered string can no longer be constructed or parsed onto an item — and which publishes the vocabulary into the OpenAPI schema served for /validate, where the field was previously an open string. No wire value changed, including the dry-run residual's DryRunError: it keeps the exception-class spelling it has always had, because normalizing it would break every consumer that pins the string and would buy nothing an enumeration does not already give. Membership means a value is reachable on the wire, not that it is worth exercising — the advisory-only warning type and the two unknown_* fallbacks are in the registry and a coverage consumer excludes them on its own side, with a reason, rather than pruning the runtime's truth.
• Closed registry for validation error types: VALIDATION_ERROR_TYPES, in the new pipelex/validation_error_types.py, is an enumerable, closed registry of every error_type a validation verdict can carry. It is a union of the enums the runtime already raises — PipeValidationErrorType, PipeFactoryErrorType, and a new ValidationResidualErrorType naming the one residual channel that had no enum of its own — so a member added to any of them is in the registry the moment it is declared. A consumer building coverage over the language surface now reads the registry instead of collecting strings from whichever diagnostics it happened to have seen. No wire value changed.
• The corpus's invalid axis: the MTHDS Test Corpus now carries an error.* tag namespace generated from VALIDATION_ERROR_TYPES, plus a focused invalid entry for every tag in it that a .mthds bundle can actually produce — each authored to trigger exactly one error, and gated on doing so. Five codes are excluded, each with the measurement behind it: circular_dependency_error and unknown_concept are unreachable through bundle validation, optional_force_redundant is advisory-only and rides the warnings array, and the two unknown_* fallbacks name the absence of a diagnosis rather than a language fault.
• The exhaustivity gate now requires an invalid entry to agree with itself: such an entry states its fault twice — as expected_error, the wire string, and as an error.* tag in covers, the normalized form — and nothing checked that the two matched. The check joins through the vocabulary's own code field rather than re-normalizing, so it carries no second copy of the normalization rule. A valid entry may no longer carry an error.* tag, since its bundle produces no diagnostic for the exhaustivity arm to count.
• Validation parity test: test_validate_bundle_entry_shape_parity.py validates the same bundle through both entry shapes — in-memory contents and a library directory — and requires the two to produce identical structured diagnostics.

Fixed

• The same bundle produced different diagnostics depending on how it reached the validator, and the library-directory route — the one the CLI and every local tool take — was the lossy one. Two arms in LibraryManager._load_mthds_files_into_library destroyed the structured data on the way out: a pydantic ValidationError was rewrapped as a bare LibraryError, which routes to the error cascade's structured-forwarding arm rather than its categorizing arm; and a ConceptLibraryError was re-raised message-only, dropping the per-reference items it now carries. In practice unresolved_concept, optional_input_unguarded and optional_output_required were simply unreachable from a file on disk. Both arms now preserve what they were discarding.

Changed

• ValidationErrorItem.error_type is typed against the closed registry union instead of an open string (breaking). This is what makes the registry closed rather than merely documented — an unregistered string can no longer be constructed or parsed onto an item — and it publishes the exact vocabulary into the OpenAPI schema served for /validate, where the field was previously an open string. As part of this, PipeValidationErrorType and PipeFactoryErrorType moved from pipelex/core/pipes/exceptions.py to pipelex/validation_error_types.py: the vocabulary is a wire contract rather than pipe machinery, and it has to sit below base_exceptions for the wire item to be typed against it at all.
• Two test fixtures were naming faults that do not exist, and typing error_type against the registry is what surfaced them: one claimed MISSING_CONCEPT, a code no enum has ever defined, and others used member names (INADEQUATE_OUTPUT_CONCEPT) where the wire carries values (inadequate_output_concept). Each was accepted silently while the field was an open string. They now name registry members.
• The corpus's invalid_* entries are excluded from plxt linting and formatting in .pipelex/plxt.toml: their structural faults are deliberate, and what guards them instead is strictly stronger — the corpus's entry-validation gate runs the real validation engine over every entry in CI, and is red both when an invalid entry fails differently and when it accidentally validates.
• Documentation: docs/under-the-hood/error-model.md now describes the closed error_type registry, and docs/contribute/mthds-test-corpus.md explains the rules for authoring an invalid corpus entry.

[v0.48.0] - 2026-08-20

Added

• MTHDS Test Corpus: Introduced a canonical, tagged set of .mthds methods at pipelex/test_extras/mthds_corpus/, replacing scattered per-repo fixtures with a single source of truth that ships in the wheel for synchronized cross-repo consumption. Each entry is a directory holding the method, an optional inputs.json, and an entry.toml declaring what it exercises — covers, tier, granularity, validity, and for a deliberately invalid entry the exact wire error_type it must produce. The MTHDS test corpus page of the contributor docs states the cross-repo contract.
• Corpus Loader API: Added iter_entries() and get_entry() in pipelex.test_extras.mthds_corpus.loader to fetch fixtures programmatically by tag, execution tier, validity, and granularity instead of by file path.
• Tag Vocabulary Generation: Added the pipelex-dev generate-corpus-vocabulary CLI command and Makefile targets to generate the corpus tag vocabulary (native.*, operator.*, controller.*) directly from runtime registries (NativeConceptCode, PipeType). The two pipe namespaces come from one registry walk, split by PipeType.category, so a pipe kind added later lands in the right namespace with nothing to update. PipeFunc is the corpus's first recorded exclusion: it names a Python function the runtime resolves against its function registry at validation time, so no portable entry can declare one.
• Feature Tag Axis: Added a hand-maintained feature.* tag namespace for language features spanning multiple blueprint fields or lacking a registry (e.g. feature.multi_file_library, feature.optionals, feature.smart_inputs, feature.structured_output). Each feature tag is declared in the same change that lands its first covering entry, so the vocabulary never advertises coverage the corpus does not have.
• Strict Corpus CI Gates: Added test suites enforcing corpus integrity: exhaustivity (every registry code has a focused entry), vocabulary drift (committed vocabulary.toml matches registries), manifest validation (strict Pydantic model per entry.toml), entry validation (valid entries compile, invalid entries fail with their declared error_type), and packaging (builds a real wheel to confirm corpus files ship while excluding the generator script).
• New Corpus Entries: Added inference-tier image payload entries (image_from_planting_brief, image_round_trip_room_photo), a nested structured-output entry (feature_structured_output_delivery_round) for lists of structured objects with optional fields, and focused entries covering batching, conditions, sequences, parallel execution, composition, extraction, and search. No entry names a model: presets are resolved by the validation engine, so an entry pinning one would fail validation on any consumer whose deck does not define it.
• Documentation: Added a contributor guide for the corpus at docs/contribute/mthds-test-corpus.md.

Changed

• Centralized Test Fixtures: Migrated end-to-end and integration tests (Date, YesNo, Smart Inputs, Optionals, Multi-file libraries, Image round-trips) to source their .mthds bundles dynamically from the new corpus via get_entry(), removing all local duplicated copies previously scattered across tests/e2e/ and tests/integration/. Nothing in this repo holds a second copy of a language-level .mthds method any more.
• Makefile Targets: Added generate-corpus-vocabulary-quiet to the cc (check) and up (update) targets to keep the vocabulary current during local development.
• VS Code Launch Config: Updated the integration test target in .vscode/launch.json from test_image_out_in.mthds to test_image_inputs.mthds to match the refactored test structure.

[v0.47.0] - 2026-08-19

Added

• codegen.lock now declares its format version, so the format can grow without breaking every reader: the lock is a cross-language interchange format — this CLI writes it, other implementations of the offline check read it — and it validated strictly with no version field at all, so the day it gained any key every consumer pinned to an older reader would have failed CI with an opaque "unknown key" error instead of a drift verdict. Each lock now opens with lock_version = 1; a reader refuses a version it does not know and names which side to upgrade, and it reads the version before the key set, so a future lock is diagnosed by its version rather than by whichever new key it happens to carry first. A lock written before the field existed is version 1 by definition and needs no migration, but every regeneration rewrites the lock once to add the key — that one-line diff is the change consumers will see. The stamp header stays deliberately unversioned, since it already ignores commented fields it does not recognise.
• Line endings are pinned to LF in the git index and on checkout, on every platform: this repo carries a lot of generated-but-committed text — CLAUDE.md and AGENTS.md, subject_grants.toml, the drift acks, .test_durations, the error-identity snapshot, the generated error pages, the migration goldens, the gateway model references — and each is produced by a writer that passes no explicit newline, so on Windows Python translated every \n to CRLF and the whole set churned in version control with no change of content. No gate would have caught it: they all compare with universal-newline reads, which fold CRLF back to LF before the comparison. A .gitattributes carrying * text=auto eol=lf closes that class for tracked files whichever writer produced them. text=auto leaves git to tell text from binary, so images and other binaries are untouched, and no tracked file held CRLF when this landed — it introduces no renormalisation diff, it pins the invariant. The complementary writer-by-writer fix is the structural half and is tracked separately.

• Documentation: docs/under-the-hood/codegen-projections.md now covers the strict stamp-header rules, the JSON conformance the options payload must meet, the policy for evolving the lock format under lock_version, and the cross-platform line-ending guarantee.

• A configuration that will not load now says whether it is wrong or merely old: A validation error is raised against the merged configuration and carries no provenance — it names a key, not which file put it there, and certainly not whether that key was correct last month. When a configuration surface's model refuses, the error now also carries a dry-run scan of that surface over the same directories pipelex migrate walks: a structured migration block naming the remedy, whether that remedy would actually rewrite anything, whether anything there is a person's to resolve rather than the tool's, and the plan per file — the same shape pipelex-agent migrate --dry-run --format json emits, so an agent that parses one has already parsed the other. error_domain deliberately stays config: it is a closed cross-repo enum and the agent-hook specification routes anything else to BLOCK, so a stale configuration reported under a new domain would stop an agent instead of telling it what to run. Consumers branch on the block's presence — absent means the failure is not staleness — and then on would_write, because presence means the migration history has something to say about these files and not that a command repairs them: a block whose only finding is a path no entry explains, or an entry blocked before anything applied, has nothing to run, and naming the remedy there would send a reader to a run that writes nothing and leaves the same error standing. Every surface points that reader at pipelex migrate --dry-run instead, where the diagnosis is. The message gains a paragraph naming the files and the next move. No value read from a user's file appears in the block, which is the third of the three channels that rule covers. A caller validating something that is not a configuration surface — a .mthds bundle, a model deck, a routing profile — names no surface and pays for no walk.

• Inference backend definitions are a migration surface, and the key the templating change deleted is repaired on every machine that has one: #1104 removed prompting_target from the model-spec blueprint and from every backend file we ship — but pipelex init never overwrites, so the key survives in inference/backends/*.toml on every installation that predates it, where it is fatal twice over: in [defaults] it is copied wholesale into every model of the file, and on a single model it is rejected by name since unknown per-model keys must be header-shaped. Those files were reachable by no surface, no walk and no gate. They are now the inference-backend surface, which required the walk to learn about subdirectories — a file is claimed by the pair (directory, name), one level deep, and only into a directory some configuration family owns — and required the fingerprint to record a document whose root is the open node, since a backend file's root keys are model names rather than a field we could name. Boot tolerance joins at the backend loader too: a stale directory is replayed in memory, boots on the models the current files would produce, and warns once naming every file it carried. Migration: run pipelex migrate after upgrading — ledger entry inference-backend@2 deletes prompting_target from every root table of every backend file, in ~/.pipelex/ and in each project .pipelex/, keeping one timestamped backup per file. Until you run it, each boot repeats the warning; nothing is ever written by a boot. A key you added that we have never heard of is still an error rather than something the entry silently drops, and the served Pipelex Gateway specs are untouched. The one key class the report stays silent about is a per-model request header, legal by shape rather than by name — and only on a model table: [defaults] is copied into every model of a file unsplit, so a header put there breaks all of them, and the report names it like any other key the schema cannot explain.

• A configuration file the ledger can explain no longer stops the boot: A schema change used to leave every machine in the field with a boot that died on extra="forbid", naming a key the user never chose to have. When a configuration surface fails to validate, its ledger is now replayed over the same files in memory and the result validated again; a boot that succeeds says so in a warning naming the files and, for each of them the command would actually reach, the pipelex migrate remedy. The retry replays whatever the loader merged, so a file loaded through Pipelex.make(config_dir=…) from outside the two directories migrate walks is named instead as the caller's to update where it lives, rather than pointed at a command that would then report nothing to do. Nothing is written either way — a tolerated boot leaves the file and its directory exactly as it found them, which is why the warning keeps coming back until the command is run. Tolerance widens what starts and never what is accepted: the re-validation is what decides, so material an unsafe entry is about still fails the boot because the model still refuses it. Anything that goes wrong inside the retry makes it decline rather than replace the error the user already has — theirs names the key to fix. A healthy configuration pays nothing: it reads no ledger, re-parses no document, and does not even import the migration engine, which is deferred for a second reason too, since the applier lives in the interpreter layer and the configuration loaders sit in the kernel layer that must not load it. This release is where it matters most: the configuration reshape gives pipelex.toml its first ledger entry, so the file every boot reads is the one tolerance carries forward on every machine that upgrades.

• pipelex migrate and pipelex-agent migrate: The migration engine now has commands, so a configuration that predates the installed pipelex can be repaired instead of re-initialized. Both walk the global ~/.pipelex/ and the project .pipelex/ — those two directories only, one level deep, and into a subdirectory only when a configuration family owns it: inference/backends/ is such a directory, inference/deck/ is not and is never entered. A file is claimed by the pair (directory, name), which is what keeps inference/backends/pipelex_gateway.toml — a pipelex_*.toml match by name — from being rewritten under the main configuration's ledger. Neither command boots: a broken configuration is the reason to reach for them, so they use the ledger, the applier and the filesystem and nothing else, and a test hands them a configuration that cannot load to keep it that way. The human command plans, shows the plan and asks; the machine one writes only with --yes, since it cannot ask, and passing --dry-run and --yes together is refused rather than resolved. Its answer is structured, and needs_attention is the verdict — this run left something a person has to decide, deliberately not did anything get written — with the exit code and the Markdown rendering as presentation. Every file rewritten is backed up beside itself first, and no value read from a user's file appears in either command's output or in the structured plan.
• A migration now names what it cannot explain about a file: A file newer than the running pipelex — an override migrated on one branch, then an older branch checked out — breaks the boot while a replay finds nothing to do, because every operation's source is absent. That silence beside a dead boot is the failure the migration project exists to remove, so every plan now carries an unexplained[] listing the paths of the migrated document that the current schema does not know and no ledger entry accounts for, each with the two readings the tool cannot tell apart: a typo, or a file written by a newer pipelex. This is the one part of a migration that needs the configuration model — the question goes to the surface's fingerprint, the same projection the coverage gate diffs, so the replay engine stays model-free. The document it reads is the one the run leaves behind rather than the one it found, which is what keeps every key the ledger is about to repair out of the list, and a path a blocked entry is about is left to that entry, which reports it by name with its own guidance. A key the user chose is never rendered: beneath an open mapping a typo is reported at queues.*.retries, naming only the segment the schema does not know.

• A configuration file may now be refused for declaring a schema version its ledger no longer reaches: min_supported_schema_version had no reader, which left the floor a comment. A migration now reads the reserved [meta] schema_version — exactly as tolerantly as the configuration loader strips it, so a malformed declaration is no declaration — and refuses a file below the floor by name (unsupported_schema_version), writing nothing. Without it, a ledger whose oldest entries had been squashed away would run over a file older than them, change nothing, and report it clean, because the applier skips an operation whose target is absent.

• An unsafe migration entry now says what it is about, and keeps saying it: unsafe is the ledger's form for a change only a human can make, and the coverage gate's only remedy for a tightened numeric bound — but the engine decided whether to report one by rehearsing its operations, so an entry with none was accepted by the accounting and then guaranteed to reach nobody, and any entry went silent the moment a later safe entry renamed the table its material sat in (reported on the first run, clean on the second, boot still failing). An entry now declares the paths whose value domain narrowed, in declared_narrowed_paths; an entry with no operations must carry one, a safe entry may not, make check-ledger refuses a path the entry's own version does not record, and the coverage gate no longer takes the bare word unsafe as accounting for a narrowing or a lost enumerated spelling — it demands the path be named. The material of an unsafe entry is traced through the ledger before a document is questioned: back through the entry's own operations, since it never applied them, and forward through every later safe entry, so the same file is reported on every run for as long as it carries it. A file that merely sets a narrowed path is reported under a new, weaker value_domain_narrowed reason listing the keys to check by hand — the engine is model-free by design and cannot tell a value the new domain refuses from one it accepts — and those keys are named at the spelling the migrated file carries rather than the one that matched, since the entry is questioned where the replay reaches it and the later safe entries rename the material before the file is written — and that report, alone among blocked entries, does not fail convergence, since a healthy reference document sets those paths like everyone else's file does. Forward tracing is deliberately confined to unsafe entries: a rehearsal may guess, an application may not.

• A migration operation can now remap every value beneath an open mapping: remap_value accepts key = "*", meaning "each key of the addressed table" — the same "each of these" reading the wildcard already had in a table_path, applied to keys. A mapping from the user's own keys to an enumerated value (dict[str, LogLevel]) keeps its spellings under keys only the document can enumerate, so no fixed key reaches them and this is the only shape in which a member renamed beneath one can be repaired at all. On every other kind a * key is now refused when the operation is parsed: deleting every key of a table is delete_table, and renaming or moving every key onto one fixed name is the many-to-one that already rules a wildcard out of a move_key. Refused rather than tolerated, because an unrefused one is a dead operation that skips forever while looking like an accounting.

• A schema change that narrows what a value may be is now caught, not waved through as additive: A change can keep every path and every enumerated spelling and still break a user's file — int becomes str, a free string becomes an enum, a bound moves from ge=1 to ge=5. Read as a path diff those look like additions, so the coverage gate used to ask for a golden regeneration, demand no version bump and no entry, and let the next boot reject a valid file with a green gate behind it. It now splits its verdict by direction: a widened type or a relaxed bound still costs only a regeneration, while a narrowing demands a bump and an entry carrying a remap_value for each narrowed path — or marked unsafe, which is the only remedy a tightened numeric bound has, since no structural operation can repair a value. The same rule applies to a stored entry, compared by origin so a narrowing hidden behind a rename is still caught, and to a pre_history entry, so the flag is not a way past it. To see a bound at all the fingerprint now records one: a closed whitelist over gt, ge, lt, le, min_length, max_length and multiple_of, read from annotated_types (now a declared dependency) and from the field metadata pydantic folds a top-level Field(ge=1) into, with anything unrecognized dropped rather than serialized — pattern excluded permanently, because regex containment is not decidable and every pattern edit would read as a tightening. One correction rides along: an enumerated type relaxed into a free string no longer reads as the loss of every spelling it had, and that is read structurally, so list[enum] becoming list[str] is the same benign loosening one container down — while a list[enum] flattened to a bare str, which is no loosening at all, still loses every spelling it had. The contract states in the same change what the gate structurally cannot see — narrowing expressed in a validator, which no projection of the annotations can reach.

• The telemetry configuration can now be migrated instead of thrown away, and the escape hatch that would have let it ship unverified is closed: telemetry.toml carries the package's first migration entry, telemetry-config@2, which lifts a flat first-generation file — telemetry_mode, host, project_api_key and the rest at the document root — into today's [custom_posthog] section, keeping every value the user chose; four settings the current shape has no home for are dropped, and the entry says which and why. Because that change predates the first fingerprint, no diff describes it, and such an entry is marked pre_history and exempted from the coverage gate's accounting — so the verification that replaces it lands in the same change and neither ships without the other. A pre-history entry must declare the paths it removes (an empty declaration is refused when the ledger is parsed), none of those paths may appear in any fingerprint at or below its own version, the fingerprint pair it sits between must show no removal at all, and every operation must act inside the declaration. It also ships a hand-authored before@N.toml beside the golden chain, which the transform check migrates and holds against the current shape and the current model — the same three claims every other entry answers. One comparator refinement came with it: a created path is now checked against defaults@N or fingerprint@N, because an optional key defaulting to None is a legal destination that no TOML document can carry.
• Configuration surfaces now have a migration ledger and a gate that forces one to be written: Every configuration surface — pipelex.toml and its tiers, telemetry.toml, pipelex_service.toml, and the inference backend definitions — carries a checked-in ledger at pipelex/migration/ledgers/<surface-id>.toml recording, as data, every shape change it has ever undergone, plus a golden chain (fingerprint@N, defaults@N) that pins what the schema looked like at each version. Each is cut at schema version 1 with no entries; the entries this release then ships on top of that baseline are the bullets below. The new make check-migration-schemas (alias cmig, in make check) recomputes each surface's fingerprint and refuses a change that would break a user's file without recording how to repair it — a removed path or a lost enumerated spelling demands a version bump and an operation accounting for it, a destination the new schema does not know is refused by name, and an entry that removes a path the schema still has is refused as over-deletion. Its counterpart make up-migration-schemas (alias umig, in make up) regenerates the goldens; the regeneration diff is the review artifact. One standing invariant is checked whether or not anything changed: every required path must have a value in its surface's defaults layer, because that is what makes an added key absorbable rather than breaking. The contract the whole thing implements is docs/migration-ledger.md.
• The migration operation vocabulary: Fix operations became a discriminated union on kind, published as two subsets — every kind for the .mthds fix path, and the structural kinds only for ledgers, so an operation that would write a value into a user's file fails when the ledger is parsed rather than at review time. Two new kinds land with it: move_key, which relocates a key across tables (the whole subtree travels when the key is table-valued, and a missing destination parent is created), and remap_value, which rewrites a value against an explicit old-to-new mapping. A * segment addresses every entry of an open mapping, expanded over the keys the file actually holds. A new CONFLICT outcome separates "this cannot be done without choosing on your behalf" — a rename or move onto an occupied destination, or an ensure_table over a key holding something that is not a table — from the benign SKIPPED it used to hide inside; a conflicting operation writes nothing at all.
• [meta] schema_version is reserved in configuration files: Every configuration-surface reader now tolerates and strips it. Nothing writes it — the key exists so a later release can stamp a version into a file without that being a breaking change today.
• make check-ledger (alias cl): The second migration gate, and the first one that joins make agent-check as well as make check. It asks what a ledger entry is allowed to say and whether replaying it is harmless, where check-migration-schemas asks whether a schema change was accounted for. An operation may only act on material some schema version removed — one addressing a path the schema still has would rewrite a perfectly valid file on every run — and it may never name a concrete key beneath an open mapping, whose keys are the user's and unbounded, while the * segment that addresses every entry of one is legal exactly there and nowhere else. A safe value remap whose old spelling is still legal, or whose target is a free string where staleness cannot be proven, is refused because it would rewrite a deliberate choice; a remap to a spelling the new schema rejects is refused because every migrated file would then fail to load with the tool reporting success. A retired path, or a remapped-away spelling, may never come back. Finally, replaying the whole ledger over each of the surface's two reference documents — the complete packaged configuration and the sparse kit starter template, deliberately different shapes — must apply nothing, report nothing, and hand back the very bytes it was given. It reads checked-in files only and fingerprints no live model, which is what makes it safe to run in the loop agents run constantly: every failure names a file the author wrote.
• The migration engine: A surface's ledger can now be replayed over a real file. The engine takes a document's text and returns the text it should now have, plus a per-file plan naming the entries that applied, the entries it would not apply, and why. Two reporting rules keep a plan from being more optimistic than the file: an entry is reported once — a conflicting operation routes the whole entry into the blocked list, carrying whichever of its operations did land — and an unsafe entry is rehearsed against the document first, so it stays silent on a file that does not need it rather than warning at every boot forever. Writing is transactional per file and always takes a backup: exactly one per file, named <file>.bak.<UTC stamp>, inheriting the source file's mode rather than the umask, written before the replacement and pruned only after it commits. A file that is unparseable, unwritable or changed during the run is reported as blocked while every sibling is migrated normally — unlike the .mthds fix loop, whose files only make sense together and which still commits a round all-or-nothing; both now share one set of transaction primitives. Nothing calls this from the command line yet.
• The transform goldens: make check-migration-schemas now also performs each migration it is asked to believe in. For every ledger entry it applies the entry's operations to the frozen reference document of the version before it and compares the result with the frozen document of the version after: every path the migration creates must be one the new document has, every path the two documents share must survive, and the last link's output — read the way a user's file is really read, beneath the current defaults layer — must be accepted by the current model. That closes the one defect the other two checks pass in silence: a rename whose destination is misspelled is accounted for by coverage and skipped by convergence, and then migrates every file to a key the schema rejects while the tool reports success. The comparison is deliberately one-directional in each claim, so a bump that also adds keys, edits comments, flips defaults or ships one more entry in a packaged deck stays green.
• Replay neutrality is now a property rather than an assertion: The guarantee a user's machine depends on — replaying a surface's whole ledger over a file already valid at the current schema changes not one byte — is checked over generated documents, not only over the two reference documents. A reference document carries exactly one value per key, so it cannot see an operation that misbehaves on the other legal spelling of an enumerated field; a sampler that reaches those spellings can. The sampler proposes each mutation from the surface's fingerprint and lets the models decide whether it lands, because schema membership is settled by validators no type projection can see: a legal enum member can still be rejected for what it requires elsewhere in the document, and a mapping typed with arbitrary string keys can still refuse a key outside a fixed set. Idempotence — replaying twice equals replaying once — and prefix coherence — a file caught halfway lands where a replay from zero lands — are checked alongside it, and each generator carries its own vacuity check, since every one of these properties is trivially true over documents nothing acts on. hypothesis joins the development dependencies.
• pipelex doctor reports pending configuration migrations, and --fix runs them: A configuration the migration history explains now boots with a warning rather than an error — and pipelex-agent silences logging process-wide as its first act, so a machine consumer never learns from a boot that its configuration is stale. Asking was the only channel left and there was nothing to ask. The health report gains a Configuration Migrations row that is pipelex migrate's own dry run: a structured finding (up_to_date, pending, needs_attention, unavailable), the files a migration would rewrite, and separately the files it will not repair on its own — both sets, because a drifted machine usually has some of each and a reader who heard only the first would stop with a broken file still in place. pipelex doctor --fix then offers to run the migration, reaching the command's own write pass rather than a second implementation of it. The row is deliberately not scoped by --global: it answers for a command that walks both configuration directories, and a row naming fewer files than the command touches would be a surprise write. A failure inside the scan is reported as a failure to check rather than as health, and never as an exception — an exception there would replace every row of the report with a single line.

Changed

• Breaking: where a run's bytes go is now told to the runtime, not derived from who is running (JobMetadata.storage_scope): Storage keys were built from user_id — {user_id}/results/{run_id}/ for delivery, {primary_id}/{secondary_id}/… (always {user_id}/{pipeline_run_id}/…) for generated content, a flat top-level normalized/ for inputs pulled off a data: URL. That ties where the bytes live to who uploaded them, which is fine until two people share the work: the second one asks for a file the first one attached and is refused, because the only thing standing between them is a string comparison on the first path segment. A host that serves teams cannot express "these two people may read the same file" in that layout at all.

JobMetadata gains a required storage_scope: one opaque, host-supplied prefix that the runtime composes assets/, results/ and payloads/ onto and never parses. The runtime does not learn what a tenant, an organization or a method is, and that is deliberate — those are host concepts with no meaning in an MIT-licensed runtime, so threading them through the transport was rejected in favour of one string the host fills however its own tenancy works. PipelexPipeRunInput carries it across the boundary alongside a now-required user_id.

It is validated at construction, on the type. The value becomes a storage key prefix, so a .. or a leading slash in it is a traversal out of the tenant's namespace; a JobMetadata that exists is one whose scope is safe, which makes every key derived downstream safe by construction rather than by each call site remembering. This replaces a per-segment sanitizer that ran over user_id and pipeline_run_id separately — collapsing them into one slash-bearing string would otherwise have deleted that control silently.

uri_format loses both {primary_id} and {secondary_id}, replaced by one {storage_scope}. Supported placeholders are now {storage_scope}, {hash} and {extension}, and the shipped default becomes {storage_scope}/{hash}.{extension}. This is not a rename of {primary_id}: keeping that name would have left the configuration saying "primary" with no "secondary" for it to be primary to, and given an operator no way to tell that the placeholder means the whole tenant prefix rather than some id. {hash} is unchanged — the first 16 hex chars of the SHA-256 of the file's own bytes, so identical output keeps one name instead of accumulating duplicates.

A configuration naming either retired placeholder is refused at boot, by name, with the supported set listed. The free-string value domain is not something the migration ledger can prove stale — per docs/migration-ledger.md a remap_value there could only be unsafe, i.e. reported and never applied — so this is a loud failure rather than a repair. Edit uri_format in your .pipelex/pipelex.toml if you customized it.

• Breaking: "anonymous" no longer appears anywhere on the identity or storage path, and a test keeps it that way: The dry-run paths still passed OTelConstants.DEFAULT_USER_ID as a user_id, which is the last place the telemetry placeholder was still being bound as an identity. They now pass DRY_RUN_USER_ID — a dry run has no caller in the identity sense either, so it says so in its own word rather than borrowing tracing's. The constant survives for telemetry, where "a span with no known caller" is a real concept.

test_storage_scope.py now scans every module under pipelex/ and fails if DEFAULT_USER_ID is ever bound to a user_id or a storage_scope again. The pattern deliberately matches an annotated parameter default (user_id: str = OTelConstants.DEFAULT_USER_ID) as well as a plain assignment — the first version of the guard did not, and passed a real injected regression while looking like it worked.

• Breaking: identity is required, and "anonymous" goes back to being a tracing label: pipeline_run_setup coalesced a missing user_id to OTelConstants.DEFAULT_USER_ID — the string "anonymous", a tracing placeholder for a span with no known caller. It leaked into the identity path and became a storage key prefix, so every run without an authenticated caller wrote into one shared anonymous/ namespace where each tenant could read the others' outputs. The fallback is what made it silent: a missing identity looked exactly like a present one.

user_id and storage_scope are now required parameters of pipeline_run_setup and prepare_pipe_job, so the same omission is a TypeError at the call site instead of a shared prefix in production. The constant survives for telemetry only.

Two callers pass explicit, greppable values rather than inheriting a default: a dry run — which provably stores nothing — passes DRY_RUN_STORAGE_SCOPE, and PipelexMTHDSProtocol defaults to LOCAL_USER_ID / LOCAL_STORAGE_SCOPE, because a run on somebody's own machine genuinely has one user and no tenancy. A constructor default stating a true fact at the boundary where it is true is a different thing from an or fallback deep in the call stack, and a multi-tenant host cannot reach these by omission — the seam it calls requires both explicitly.

Fixed

• The codegen stamp header is now read strictly: pipelex codegen check verified a generated file as pristine even when a line had been injected between the stamp's fence markers, because the content hash covers only the body below the fence — so an executable statement could sit inside a header that says DO NOT EDIT and the tree would still report as current. Any line inside the header that does not carry the file's comment prefix now makes the stamp unparseable, which the check already reports as hand-edited. The options value must also be conformant JSON: Python's non-standard NaN / Infinity / -Infinity literals are refused, so a stamp cannot hold something only a Python reader accepts — the header is a cross-language interchange format, and the second implementation of the offline check (in @pipelex/sdk) already rejected them. Commented key: value lines a reader does not recognise are still ignored, so the header can gain fields without breaking older readers. One consequence to know: a file whose header was tampered with is no longer one pipelex codegen types will overwrite — it now refuses a destination it cannot prove it owns rather than clobbering work, so such a file has to be removed before regenerating, which is what the check's advice already tells you to do.
• pipelex codegen check now reports drift in one order, whichever half of the report it comes from: locked artifacts were listed by their full path compared as a string, while stale orphans came out in the order a directory walk found them — a component-by-component order. For a tree holding a models/ directory beside a models.py, the two halves of a single report therefore sorted paths by different rules, and a second implementation could not mirror both with one comparator. Both halves now use the plain full-string sort, and the ordering is written down as a contract: every locked-artifact drift first, then every orphan, each group by path.

• Generated files are written with LF line endings on every platform: save_text_to_path let Python translate each newline to os.linesep, so a file emitted on Windows landed as CRLF on disk while its recorded content hash had been taken over the LF text it was built from. The verdict survived, because reads translate back, but the promise that regenerating produces byte-identical output held only within one platform — a team mixing Windows and Linux saw generated trees churn in version control with no change of content. Every artifact this writes (generated code, the codegen lock, JSON outputs, input templates) is now the string verbatim.

• The scope was validated after the first thing that wrote with it. prepare_pipe_job ran the data-url normalizer — which stores bytes at {storage_scope}/assets/… — and only then constructed the JobMetadata whose validator is supposed to make that key safe. A scope carrying .. therefore escaped the tenant's namespace, and the guard meant to stop it ran afterwards, on damage already done. The defect was ordering, not absence: this file's own "safe by construction" claim did not hold on the one path that mattered. The scope is now validated at the top of the seam, before anything composes a key from it. Pinned by a test that asserts the normalizer was never called, with real inputs — the empty-inputs harness skips the normalizer on its own, so the same test written that way passes with the guard deleted.

• Generated content had no leaf: it landed loose at the root of the scope. Three things write during a run and each built its key separately — the data-url normalizer under assets/, storage delivery under results/, and generated bytes (an image a pipe produced) directly at {storage_scope}/<hash>.<ext>, because uri_format rendered the whole key and shipped without one. A file under no leaf is invisible to anything listing a run's content by category, cannot be retained or dropped separately from the rest, and shares the root with every leaf added later. Generated bytes now land under generated/.

It is its own leaf, not assets/ or results/. assets/ is what the caller supplied and this is what the run produced — a provenance split an operator can act on ("drop what we generated, keep what the user gave us"). results/ is the delivery envelope: written once at the end, under fixed names, only when storage delivery is configured — whereas generated content is written during the run, content-addressed, and usually intermediate, since a generated image is more often an input to a later step than an output of the pipeline.

Breaking: uri_format renders the FILENAME only, and {storage_scope} is no longer a supported placeholder ({hash} and {extension} remain; a leading / is now refused). The prefix moved into code because a placeholder an operator may omit is an invariant that does not hold — a config dropping it put every run's generated bytes in one namespace. What the format still decides is the filename, including any subdirectory beneath the leaf.

• Every local run with storage delivery overwrote the previous one. The run id used to be part of the storage key ({user_id}/{key_prefix}{pipeline_run_id}); collapsing the key onto the scope removed it, which is correct for a host — a hosted scope already identifies the run, <org>/<method>/<run> — but left the local default naming a tenant and no run. So every local run wrote local/results/<filename>, the same key each time, each one silently destroying the last. A local run's scope is now its run id, composed in pipeline_run_setup because that is where the run id is minted and the constructor default cannot name a run that does not exist yet. LOCAL_STORAGE_SCOPE is a sentinel meaning "no host supplied a scope" and never reaches a storage key: a tenancy segment on a laptop separates nothing, since there is exactly one tenant, while the run id is the only part that has to be distinct. Keyed on the sentinel exactly, never a prefix test, so a host-supplied scope is never rewritten.

• A scope ending in a newline passed validation. validate_storage_scope used re.match with a $ anchor, which admits one trailing newline, so "org/mt/run\n" was accepted and the newline travelled into every storage key and log line built from the scope — an unaddressable key and a log-forging primitive. Now fullmatch.

• The bridge payload required the scope but never validated it. PipelexPipeRunInput.storage_scope was a bare str, so a payload arriving from another process could carry a traversal that was only refused frames later, wherever a key was first composed. It is validated at construction now, making a malformed payload a decoding error that names the field.

[v0.46.4] - 2026-08-18

Changed

• This repo now dogfoods its own migration .gitignore convention: the project-local .pipelex/ directory picked up the .gitignore that pipelex migrate/pipelex init write to keep timestamped backup copies (*.bak.<timestamp>) out of git status — the same file every consumer project has received automatically since v0.46.2.

Fixed

• The config-sync gate no longer goes red on what the migrator leaves behind: make check compares the repository's own .pipelex/ against the pipelex/kit/configs/ templates by contents, and it had never been taught about the two things pipelex itself writes into a configuration directory — the .gitignore added in v0.46.2 (which has no kit counterpart by design) and the timestamped *.bak.<stamp> copies a real pipelex migrate leaves beside every file it rewrites. Dogfooding the .gitignore in v0.46.4 broke make check outright, and any developer who ran pipelex migrate in a checkout broke it again — putting the dirtied-repository problem that .gitignore exists to solve straight back, one gate over. Both the check and make up-kit-configs now look past those artifacts, matching backups and .rescue. copies by a glob built from the same infixes and stamp shape the backup namer writes, so a rename there cannot orphan the rule. This also closes a latent hole in make up-kit-configs, which would have mirrored a developer's backup copy into the shipped kit.

[v0.46.3] - 2026-08-18

Fixed

• The configuration-directory .gitignore now reaches machines with nothing to migrate: v0.46.2 added a .gitignore inside .pipelex/ to keep migration backups out of git status, but pipelex migrate only wrote it on a run that actually had a file to carry forward. A machine already at the current schema was reported clean and returned before the write pass, so it never got the rule — and that is the state every user is in between schema changes, which meant in practice almost nobody received it. Any real (non---dry-run) pipelex migrate now writes it whether or not there is anything to migrate; a run whose migration you decline still writes nothing at all.

[v0.46.2] - 2026-08-18

Fixed

• Migration backups no longer dirty your repository: pipelex migrate copies every file it rewrites to <file>.bak.<timestamp> beside the original, and inside a project's .pipelex/ those copies showed up as untracked files in git status — a dozen of them after a single run. Pipelex now keeps a .gitignore inside the configuration directory itself, ignoring exactly the timestamped copies it makes; it is written by pipelex init and by any real pipelex migrate, so a machine whose .pipelex/ predates this gets the rule from the run that would otherwise have made the mess. An existing .gitignore there is never modified, and a .rescue. copy is deliberately left visible because it is the one the report asks you to go and collect.

[v0.46.1] - 2026-08-18

Changed

• Test-duration map refresh is now incremental (developer tooling): make store-test-durations (std) no longer re-runs the whole suite. It collects the tests, measures only the ones missing from .test_durations, and leaves recorded values alone — which takes seconds when little has been added, instead of several minutes. This is driven by what actually unbalances the CI shards: measured against the real eight-way split, a map with stale values but complete coverage costs about 7% of balance, while one with current values and missing entries costs over 50%, because pytest-split imputes an unknown test at the suite mean (~0.25s) when the median test is ~0.002s. Added make store-test-durations-force (stdf) for the occasional full re-measurement. The refresh now also prunes entries whose test file no longer exists, making the test_test_durations_paths gate self-healing, and keeps any recorded value that has not meaningfully moved, which cuts the release diff for that file by about 95% — it had grown large enough that automated PR reviewers declined to read the branch at all. New page: docs/contribute/test-duration-map.md.

Fixed

• Migrator comment fidelity: Fixed pipelex migrate so structural operations no longer leave comment banners behind or attach them to the wrong sections. Moved keys and tables now carry their introducing comment block with them; deleted keys and tables now drop their introducing comment block; items appended under an existing table now land before that table's trailing banner; and the .mthds fix path now drops comments above stripped native-concept redeclarations. Note: files already migrated by v0.46.0 are not rewritten automatically—tidy the comments by hand or restore the .bak files and re-run pipelex migrate.

[v0.46.0] - 2026-08-17

Added

• Configuration migration engine & commands: Introduced pipelex migrate and pipelex-agent migrate to bring user configuration files up to the current schema. Migrations rewrite files in-place (preserving user values), create timestamped .bak backups, and run without booting Pipelex, so no credentials or network access are required. Both walk the global ~/.pipelex/ and the project .pipelex/ only, one level deep, and enter a subdirectory only when a configuration family owns it. Configuration validation errors now include a structured migration block so machine consumers can distinguish a stale config from an invalid one.
• Boot tolerance for stale configs: A config that is out-of-date but explainable by the migration ledger no longer hard-crashes the boot. Pipelex replays the migration ledger in-memory, boots successfully, and warns the user to run pipelex migrate. Nothing is ever written by a boot, so the warning returns until the command is run, and a file the in-memory re-validation still refuses fails the boot as before — tolerance widens what starts, never what is accepted.
• pipelex doctor migration integration: Added a "Configuration Migrations" row that dry-runs pending migrations; pipelex doctor --fix now offers to apply them. The row reports the files a migration would rewrite and, separately, the files it will not repair on its own, because a drifted machine usually has some of each and a reader who heard only the first would stop with a broken file still in place.
• Migration ledgers & gates (developer tooling): Every configuration surface — pipelex.toml and its tiers, telemetry.toml, pipelex_service.toml, and the inference backend definitions — now carries a checked-in ledger recording each shape change as data, plus a golden chain pinning what the schema looked like at each version. Added make check-ledger (cl) to verify ledger legality and convergence, make check-migration-schemas (cmig) to ensure all schema changes are accounted for in the ledger, and make up-migration-schemas (umig, with umigf to force past a refusal) to regenerate the goldens. umig deliberately left make up: rewriting a head golden after deleting a field would erase the very removal the coverage gate exists to catch.
• Migration operation vocabulary: Fix operations became a discriminated union on kind, published as two subsets — every kind for the .mthds fix path, and the structural kinds only for ledgers, so an operation that would write a value into a user's file is refused when the ledger is parsed rather than at review time. move_key relocates a key across tables and remap_value rewrites a value against an explicit old-to-new mapping, with a * segment addressing every entry of an open mapping. A new CONFLICT outcome separates "this cannot be done without choosing on your behalf" from the benign SKIPPED it used to hide inside; a conflicting operation writes nothing at all.
• A migration names what it cannot explain, and refuses a file it cannot reach: Every plan now carries an unexplained[] listing paths of the migrated document that the current schema does not know and no ledger entry accounts for — a typo, or a file written by a newer Pipelex, two readings the tool cannot tell apart. Separately, a file declaring a [meta] schema_version below its ledger's floor is refused by name (unsupported_schema_version) instead of being run over, left unchanged, and reported clean. No value read from a user's file is ever rendered in either report.
• [meta] schema_version is reserved in configuration files: Every configuration-surface reader now tolerates and strips it. Nothing writes it — the key exists so a later release can stamp a version into a file without that being a breaking change today.
• Value domain narrowing detection: The migration engine now detects schema changes that narrow allowed values (e.g., int to str, or tightening a ge=1 bound to ge=5) and forces the author to provide a migration path or an unsafe manual warning. Read as a path diff those look like additions, so they used to cost only a golden regeneration and let the next boot reject a valid file with a green gate behind it. An unsafe entry must now name the narrowed paths in declared_narrowed_paths, and that material is traced through later entries so the same file keeps being reported for as long as it carries it. To see a bound at all the fingerprint records one, over a closed whitelist (gt, ge, lt, le, min_length, max_length, multiple_of); pattern is excluded permanently, because regex containment is not decidable and every pattern edit would read as a tightening.
• Replay neutrality is checked as a property, not asserted: The guarantee a user's machine depends on — replaying a surface's whole ledger over a file already valid at the current schema changes not one byte — is now checked over generated documents rather than only the two reference documents, which carry one value per key and so cannot reach the other legal spelling of an enumerated field. Idempotence and prefix coherence are checked alongside it, each generator carrying its own vacuity check. The coverage gate also performs every migration it is asked to believe in, applying each entry to the frozen document of the version before it and holding the result against the version after, which catches a rename whose destination is misspelled — accounted for by coverage, skipped by convergence, and otherwise shipped. hypothesis joins the development dependencies.
• Claude skills: Added the add-migration skill to automate ledger entry creation from coverage gate refusals, and updated the release skill to enforce ledger completeness before cutting a release.

Changed

• Configuration root reshaped (Breaking): The pipelex.toml root structure has been reorganized to mirror the runtime layers, and the redundant _config suffix has been dropped from keys: [runtime] (process-scoped infrastructure), [inference] (the model-calling seam, formerly [cogt]), [interpreter] (library-scoped method machinery), and [kit] (dev tooling). So [pipelex.log_config.rich_log_config] is now [runtime.log.rich_log], and code reading the config tree moves with the keys: get_config().pipelex.storage_config is get_config().runtime.storage. Class names keep their suffix — the redundancy was in the key, not the type. Migration: run pipelex migrate after upgrading — ledger entry pipelex-config@3 rewrites ~/.pipelex/ and every project .pipelex/ file in place, keeping every value you chose.
• Templating style is now an authoring decision (Breaking): How a pipe's inputs are tagged into a prompt is declared on the pipe itself (templating_style on PipeLLM) rather than inferred from the model, with one runtime default for everything that declares nothing ([inference.templating].default_templating_style, shipped as xml). The global default is now XML tags (<tag>...</tag>) instead of back-ticks, so every prompt rendered for an OpenAI-family model will change shape. Compose, image-generation, search, and structuring prompts follow this same runtime default, so any template of yours using | tag changes shape whichever model family you run on. Migration: run pipelex migrate — ledger entry pipelex-config@2 carries a tuned [pipelex.prompting_config] forward, the default style travelling to default_templating_style while the per-target prompting_styles map is dropped, since a style is no longer chosen per model; the backup beside the file is where the old map remains readable.
• Inference backend files are a migration surface (Breaking): prompting_target was removed from every backend file we ship, but pipelex init never overwrites, so the key survives in inference/backends/*.toml on every installation that predates this release — where it is fatal twice over: in [defaults] it is copied wholesale into every model of the file, and on a single model it is rejected by name as an unknown, non-header key. Those files were previously reachable by no surface, no walk and no gate; they now are, and the backend loader replays a stale directory in memory so the boot survives with a warning naming every file it carried. Migration: run pipelex migrate — ledger entry inference-backend@2 deletes prompting_target from every root table of every backend file, in ~/.pipelex/ and each project .pipelex/, keeping one timestamped backup per file.
• Strict Jinja2 templating filters (Breaking): The tag, format, and with_images filters no longer fall back to a built-in style when the rendering context lacks one; a missing style now raises Jinja2ContextError. Every prompt-rendering entry point now supplies a resolved style, so a missing one is a bug rather than a shape nobody chose. An explicit filter argument (| format("markdown")) is unaffected, and an unknown format name is reported as a template error instead of a bare ValueError.
• templating_style tables reject unknown keys (Breaking): TemplatingStyle and the rich template table of PipeCompose are now extra="forbid" like every other blueprint. A misspelled optional key — { tag_style = "xml", text_formt = "markdown" }, or templating_stile on a template table — used to be dropped silently, yielding a prompt rendered under a shape the author never asked for; it is a validation error now. The MTHDS JSON Schema gains additionalProperties: false on both definitions.
• Unknown per-model backend keys must be header-shaped (Breaking): Any unrecognized key in a per-model table inside inference/backends/*.toml is sent to the provider as an HTTP header. To prevent typos from silently becoming headers, these keys must now contain a hyphen (e.g., x-portkey-provider); keys without hyphens fail the boot, in strict and lenient boots alike, naming the key, the model and the file. The key must also be usable on the wire — RFC 7230 token characters only, with a printable single-line string value — and a hyphenated spelling of a real field (max-tokens) is rejected by name. In the remotely served Pipelex Gateway config the same rule prunes such keys instead of failing, as version skew.
• Telemetry config is migratable: telemetry.toml is now a migration surface. Upgrading from the legacy flat format to the [custom_posthog] format is handled by pipelex migrate, preserving user API keys and exporters instead of forcing a destructive pipelex init telemetry reset. The loader now raises through the same reporting path as every other configuration surface, so the human CLI, the agent envelope and pipelex doctor all say whether the file is old, wrong, or reported on by a migration that would not repair it, rather than each holding a hardcoded remedy. Migration: run pipelex migrate — ledger entry telemetry-config@2 lifts a flat first-generation file into [custom_posthog], keeping every value that has a home in the current shape and saying which settings it drops and why.
• The migration ledger contract is published, and a config-model change owes it a review: docs/migration-ledger.md joins the documentation navigation beside the other contributor contracts. The config-docs drift contract's review list gains the migration ledgers and the two modules holding the validators that narrow a configuration value domain — a narrowing expressed in a validator is invisible to the fingerprint projection the coverage gate reads, so no derived check can demand the ledger entry it owes, and a review obligation is the only place that can catch it.
• Keyless dry runs: pipelex run --dry-run no longer requires inference credentials, bringing it to parity with pipelex-agent run --dry-run. It boots keyless with real model specs, every run forced to DRY. Anyone who relied on pipelex run --dry-run as a credentials check should use a live run for that.
• Reasoning budgets: Thinking budgets are now worker-owned (keyed by family constants like "anthropic" or "gemini") rather than read from the removed prompting_target. Behavior is unchanged; the budget maps keep their anthropic and gemini keys.
• Remote gateway config: Bumped the remote inference config to pipelex_remote_config_12.json, whose defaults no longer declare the removed field; earlier releases stay pinned to _11, which is frozen. Unknown keys in remote defaults are now pruned rather than rejected, to tolerate version skew — local backend files stay strict.

Fixed

• pipelex doctor bracket escaping: Fixed a crash where pipelex doctor failed with a MarkupError when a file path or error message contained brackets (e.g., [dev]) that Rich interpreted as formatting tags — worst exactly when the report is what the user came for. Every value the report interpolates is now escaped, including configuration paths, backend names, deck filenames and the text of every exception the --fix pass reports.
• pipelex doctor --fix no longer offers to overwrite a telemetry config it could migrate: The fix machinery decided what it could repair by searching the row's message for "format has changed", and on a match offered to write a fresh telemetry.toml, discarding every setting in it. It now branches on a structured finding, so an out-of-date file is answered with pipelex migrate and an invalid one is left to a person. The doctor's telemetry check also strips the reserved [meta] table the way boot does, instead of reporting a perfectly bootable file as invalid.
• Agent CLI double envelopes: Fixed pipelex-agent models and check-model printing two JSON error envelopes on a single stream, resulting in invalid JSON output. agent_error leaves through typer.Exit, which is a RuntimeError and not a SystemExit, so a command boundary re-raising only SystemExit caught the error it had just reported and reported it again.
• Dotted-key renaming: Fixed a bug in the TOML fix applier where renaming a dotted key (e.g., a.b = 1) accidentally converted it into a block header ([a.b]), swallowing subsequent scalar values into the wrong table. The applier now also refreshes every chunk of a table written in several places, so renaming a in a [a.b] … [a.c] … [a.b.d] layout no longer leaves the later chunks rendering under the old name. Both reach every caller of the applier, the .mthds fix loop included.
• Symlink migration: Migrating a symlinked configuration file now correctly replaces the file at the target of the symlink rather than replacing the symlink itself with a regular file.
• Backup rotation race conditions: Fixed backup file rotation so a failed migration run deletes its own temporary backup but never deletes a backup created by a concurrent run. A copy kept because a write could not be confirmed is renamed out of the .bak. rotation into .rescue., so a later run cannot prune away the very file the report told the user to go and get. The backup's directory entry is now fsync-ed before the target is replaced, so "back up first, replace second" holds across a power loss and not only a process exit.
• Boot failure reporting: Fixed a failure to load pipelex.toml producing a bare Python traceback instead of the intended user-friendly, field-level error message. RuntimeBoot and the doctor both caught pydantic.ValidationError around setup_config, and the main configuration raises ConfigValidationError instead, so the arm never fired for the one configuration everything depends on. Both sites now catch either shape a refusal takes and share one helper.
• Backend errors name the model, the backend and the file: A refusal cut down to max_tokens: Input should be a valid integer sent the reader to grep a directory of files that all have a max_tokens; the loader now says which model, which backend and which file before it quotes the pydantic analysis, and the model deck's message keeps its paths the same way. A backend table whose own fields fail the blueprint (endpoint = 42) is raised as the library's own validation error rather than escaping as a bare pydantic ValidationError that no clause in the boot named. A message carrying a migration block no longer also suggests pipelex init config, which would have reset every value the block had just promised to keep.
• Gateway enabled truthiness: Fixed enabled = 1 in backends.toml being evaluated differently by the loader and the boot process, which silently dropped the gateway. Both readers now read the value the same way.
• A blocked configuration file says which state it is in: FileBlockedReason gained unreadable and state_uncertain, so an unreadable file is no longer reported as unwritable and a write whose outcome the transaction could not describe is no longer reported as one that never happened.

Removed

• prompting_target (Breaking): Removed from LLMSetting, InferenceModelSpec, InferenceModelSpecBlueprint, and all shipped backend TOML files, along with the PromptingTarget enum and the per-target style map. Delete prompting_target from your local .pipelex/inference/backends/*.toml files, or the strict boot loader will reject them — or run pipelex migrate, which does it for you. Check portkey.toml in particular: the key appears in [defaults] and on individual model entries, and a surviving per-model one is rejected by name as an unknown, non-header key.
• Legacy prompt templates: Removed LLMPromptTemplate, LLMPromptFactoryAbstract, LLMPromptTemplateInputs and LLMPromptTemplateInputsError, which relied on hardcoded XML+Markdown styles predating the new configurable templating system and had no production consumer.
• Deprecated config keys: Removed [migration.migration_maps], session_id, and plugins.boot_orchestrator from the root configuration. Renames are ledger entries now, so the old-to-new name hints in validation errors go away, .mthds hints included; boot_orchestrator is strictly a boot argument — pass --orchestrator or Pipelex.setup(boot_orchestrator=...) and read it back at run time from the runtime_hub accessor rather than off the config.

[v0.45.0] - 2026-08-14

Added

• Per-node token usage and cost on the run graph (Breaking): GraphSpec nodes gained a usage object and the graph gained a run-level usage rollup, so a consumer can finally answer "which pipe spent the money". The link already existed in the event stream — every UsageReportEvent names its graph node — and the assembler was dropping it; it now folds those events into per-node totals (own inference calls, tokens by category, cost) plus a subtree_* rollup up the parentage chain, so a controller reports what its whole branch spent. Cost is deliberately three-valued and never overloaded: null means unrated (no rate table — own-GPU models, dry and mock runs, so every dry-run graph is unrated), a rated_inference_calls count marks a mixed rated/unrated node's cost as a lower bound rather than a total, and total_tokens is input_joined + output — never the sum of nb_tokens_by_category, where input_cached is a subset of input. Usage whose node cannot be resolved lands in a typed unattributed bucket instead of being dropped, so the graph's total cannot silently disagree with the cost report's. Every dollar comes from compute_tokens_usage_cost, the same engine the cost table and the API wire records use. Breaking: NodeSpec and GraphSpec are extra="forbid", so an older pipelex rejects the new JSON. See Per-node Usage Attribution.

• The run graph now records which model actually ran, per node. NodeUsageSpec gained by_model (and subtree_by_model): the inference_model_name, inference_model_id, call count and cost of every model a node actually used, ordered most-used first. Until now a GraphSpec named a model in two places and neither was the outcome — the pipe blueprint holds the authored choice ($writing-factual), and execution_data.resolved_model holds the handle LLMSetting.model carried, which is frequently still an unresolved alias (@default-premium) because aliases resolve later, at inference time. by_model reads from the usage records instead, so it survives alias resolution, deck defaults, and any fallback or retry that landed somewhere other than what was asked for. It is a list rather than a single value because a node routinely uses more than one model: a PipeLLM's text pass and its object-structuring pass resolve separately. Per-model cost follows the same rule as the node's — None iff no call to that model carried a rate table.

Fixed

• A dry run of a PipeCondition is now reproducible. pipe_dependencies() returns a set[str], and the dry-run arm walks every branch into the same working memory under the same output_name — so the branch iterated last is the one whose stuff the enclosing pipe reports as the condition's output. Iterating the raw set made "last" a function of string-hash order, which varies per process, so the same bundle dry-run twice produced two different graphs: in a sequence routing to two branches that each name their own tail result, the sequence's output name flipped between them run to run. Nothing about a dry run should depend on PYTHONHASHSEED, and anything diffing graph specs across runs — a fixture corpus, a static-vs-dry parity check — saw phantom changes. The loop sorts now, which is what the two other order-sensitive readers of this set (signature_walk, the output_option_N renderer) already did. Live runs were never affected: they take exactly one branch.

• A {concept, content} envelope carrying an empty list is now a value, not an error: a plural slot is never absent — when nothing is found it is the empty list — and the top-down shaper has always honoured that for a bare [] (D2). The bottom-up factory did not: it infers a list's item type from the first item, so an empty list raised "Cannot create Stuff from empty list in content". The two spellings of one input therefore disagreed — a caller with no pictures could send [] and run, or send {"concept": "native.Image", "content": []} and fail — which made a plural input with nothing in it unrunnable for every caller that wraps its inputs. The envelope names the concept, so there was never anything to infer; it now builds an empty ListContent. Case 1.5 (a bare empty ListContent, no concept anywhere) still raises, and must: nothing there says what the items would have been.

• Kernel step identity: PipelexKernel.make_step_metadata now accepts pipe_code to name the pipe a step is running, mirroring what the interpreter stamps on its live and dry paths — so log correlation, usage accounting, and per-step labelling see a named step for kernel-driven runs. The key is omitted from the metadata update when not supplied, so a run-level pipe_code is never silently erased; the direct-call façade (llm_text/llm_object) stays deliberately anonymous. PipelexKernel.make also accepts an injectable step_id_source for per-step ids, defaulting to uuid4, so a kernel hosted inside a replay-based executor can supply a replay-safe source.

[v0.44.0] - 2026-08-13

Added

• Entry-point resolution affordances: Added get_required_entry_pipe, get_optional_entry_pipe, get_required_entry_concept and get_optional_entry_concept to the interpreter_hub and library APIs. These are designed for human-supplied codes (CLI arguments, API payloads) and safely search across domains, unlike strict in-body references. Installed dependency packages are excluded from that search, so adding a dependency cannot make one of your own codes ambiguous.
• Build-time crate qualification: Introduced a standalone crate_qualification pass that fully qualifies in-body references to their owner domain at library build time, ensuring the normalizer and the live library strictly agree on reference resolution. This supersedes v0.43.0's Cross-domain pipe refs in normalized crates: the two readers still agree, but on owner-domain qualification rather than on a crate-wide search.

Changed

• Strict in-body pipe reference resolution (Breaking): Bare in-body pipe references (sequence steps, parallel branches, condition outcomes, batch_over targets) now resolve only within their own domain. To reference a pipe in another domain, use the fully qualified form (e.g. sales.generate_tagline). This enforces [exports] visibility rules that were previously bypassable, and lets multiple domains safely reuse the same pipe code without library load failures.
• Automatic search scope for concepts (Breaking): Replaced the search_domain_codes list parameter across the public API (PipelexMTHDSProtocol, pipeline_run_setup, prepare_pipe_job, InputShaper, WorkingMemoryFactory, etc.) with a single search_scope string derived automatically from the entry pipe. Every entry-lookup refusal — invalid string, miss, ambiguity — is now raised as ConceptLibraryConceptNotFoundError, a class the input-shaping handlers catch.
• Fully qualified validation error payloads (Breaking): The missing_pipe_code field on unresolved-dependency validation items now returns the fully qualified reference the compiler attempted to resolve (e.g. marketing.render_html) rather than the bare spelling the author wrote.
• Ambiguity handling for bare code lookups: Bare pipe codes typed by users (via pipelex run, show, which, or API requests) still search across all domains, but when two domains declare the same code the system now raises a clean ambiguity error listing the candidates instead of failing with a traceback.
• Per-domain scoping in pipelex fix: Rename collisions in the fix loop are now scoped per-domain rather than crate-wide, so two same-named pipes in different domains rename independently without bailing.
• PipeFunc transports qualified references: PipeFunc now transports the fully qualified pipe_ref to the executor instead of the bare code, preventing resolution failures in strict remote environments.
• Expanded agent quality gate: make agent-check now includes drift-check and check-hub-layering, so open code↔docs drift contracts fail the local quality gate before reaching CI. The digest reads the git index, so stage changes for the gate to see them.

Fixed

• Verdict-neutral CLI lookup errors: The build and codegen CLI commands no longer prepend a misleading "not found" verdict to stderr when a bare code is ambiguous; the prefix is now verdict-neutral.
• Time native conversion in PipeCompose: Time and Time[] native concepts are now correctly converted to datetime.time and list[datetime.time] when copied into native-typed fields via PipeCompose.
• Batch sub-pipe code derivation: Fixed batch_over synthesized pipes deriving their code from the qualified reference rather than the local code, which caused false-positive "namespace prefix" warnings on every batched run.

Removed

• ConceptProviderAbstract.get_required_concept_from_concept_ref_or_code: Removed in favor of the new get_required_entry_concept method to standardize entry-point concept resolution.

[v0.43.1] - 2026-08-12

Changed

• PipeRunParams.batch_max_concurrency is now required (Breaking): The field no longer defaults to None, which previously made an omitted value indistinguishable from an explicitly authored unbounded concurrency (max_concurrency = "unbounded"). Omitting it now raises a ValidationError early—on both direct construction and payload decoding—to prevent accidental unbounded fan-outs.
• Migration: Construct PipeRunParams via PipeRunParamsFactory.make_run_params(), the single writer for run-scoped invariants (run_mode, pipe_stack_limit, batch_max_concurrency). Integration test fixtures now route through the factory via a new make_mode_guarded_run_params helper.
• Docs: Added a warning to docs/under-the-hood/pipe-routing-and-execution.md on using the factory method.

Fixed

• Empty lists in concept envelopes are now parsed as values, not errors: The bottom-up factory previously raised "Cannot create Stuff from empty list in content" when given an empty list inside a concept envelope (e.g., {"concept": "native.Image", "content": []}). Since the envelope names the concept, item-type inference is unnecessary, so it now correctly yields an empty ListContent. This aligns the bottom-up factory with the top-down shaper; callers can pass [] or {"concept": "...", "content": []} to represent an empty plural slot. A bare empty list with no concept still raises an error, as its type cannot be inferred.
• Docs: Added a note to docs/building-methods/pipes/provide-inputs.md clarifying that an empty list represents an empty plural slot, whereas omitting the key fails with a "missing required inputs" error.

Security

• uv.lock refreshed onto patched dependency versions: A targeted lock refresh clears the open Dependabot alerts, with no pyproject.toml constraint changes — every declared range already permitted the patched version, so this was stale-lock drift rather than a constraint problem. Bumps aiohttp, cryptography, datamodel-code-generator, pillow, pyasn1, pymdown-extensions and soupsieve. The alerts left open are held by torch, reachable only through the optional docling extra, whose upgrade would drag torchvision, triton and the NVIDIA CUDA stack along with it.

[v0.43.0] - 2026-08-12

Highlights

Every operator's execution semantics is now importable without the interpreter. The new public pipelex.kernel subpackage extracts what a step does — deck resolution, prompt assembly, generation, memory write-back — into plain functions covering every operator, all servable on a kernel-only boot with zero .mthds loaded. The layer below the interpreter takes the kernel's name, and plugins now declare which side they belong to through their entry-point group, so an interpreter-side plugin is never imported into a kernel-only process. Distributed execution sharpens alongside — a run_batch_branch router hook lets a backend isolate each batch branch, and the fan-out bound is frozen onto the run to close a replay hazard. Breaking changes are import-path moves, an error-class unification, a new required build_registrar parameter, a retired plugin entry-point group, and stricter ISO 8601 and failure classification.

Added

• Pipelex kernel (pipelex.kernel): New public subpackage holding operator-execution semantics as importable functions — deck resolution, prompt assembly, generation, memory write-back — no longer reachable only through a fully booted interpreter with a loaded library. Every operator is covered (LLM and structuring, extraction, image generation, search, template composition, Python function calls), every call is servable on a kernel-only boot with zero .mthds loaded, and a boot-contract test pins it. Two arms stay with the interpreter because their inputs are language or deployment artifacts rather than execution semantics: PipeCompose's construct mode and PipeFunc's pluggable executor. See Pipelex Kernel.
• PipelexKernel facade with typed result envelopes: A facade class managing per-run state (JobMetadata, CogtRunParams) with ergonomic entry points such as llm_text and llm_object. Every kernel operation returns a strongly-typed envelope (LlmTextResult, LlmObjectResult, ExtractResult, ImgGenResult, SearchResult, ComposeResult, FuncResult) carrying the produced content, the updated memory, and tracer intermediates. pipelex.kernel.memory_ops standardizes the memory boundary with shape_inputs, store_result and typed extraction helpers.
• run_batch_branch router hook: PipeRouterProtocol gained a second dispatch entry point, used by PipeBatch for each per-item fan-out branch — the only signal a router gets that a dispatch is a batch branch rather than an ordinary step. The default body delegates to run, so in-process execution is unchanged and every existing router keeps working untouched (routers subclass PipeRouterProtocol, so they inherit it); a distributed backend can override it to give each branch its own isolation. Documented on the "Pipe Routing and Execution" page and listed in the Orchestrator SPI.
• Exceptions-aggregate layering gate: A new AST test bans kernel-layer packages from importing the all-errors aggregate pipelex.exceptions, whose re-exports pull in the interpreter. It matches module-level, function-local and string-named imports alike, closing the blind spot neither check-hub-layering nor the import-closure test can see. The fix for a violation is always to import the error class from the module that defines it.
• Plugin validation errors: PluginDeclaredInMultipleGroupsError, PluginLayerViolationError and RetiredPluginEntryPointGroupError give loud, actionable startup failures for a misdeclared plugin, each with its own error reference page.