Standard Library

The Standard Library is the normative collection of connector and filter-package artifacts published with this specification. The Standard Library assigns portable contracts to canonical namespaces; an implementation resolving canonical artifacts MUST NOT use a deployment catalog to redefine those contracts.

Each library artifact consists of its manifest, referenced fixtures and samples, immutable data files, and any semantic description or conformance cases identified by the Library edition. These components are normative together.

A manifest declares the machine-checkable surface, fixtures establish portable examples, and prose or conformance cases specify behavior that the manifest format cannot express. A disagreement among them is a defect in the Standard, not permission for an implementation to choose among them.

The library defines integration contracts, not vendor services, endpoints, accounts, credentials, transport implementations, or deployment policy. An implementation can realize a library connector directly or adapt another service, provided it satisfies the canonical contract.

Versioning and Artifact Identity

Library publication and compatibility follow Obligations of the Standard. An artifact’s version identifies its edition; its document and file-set digests establish content identity.

Each artifact has an independent identity formed from its kind and canonical namespace, but every artifact in an edition carries the exact Standard revision.

Library artifacts are selected as members of that edition and MUST NOT be independently upgraded across Library editions. An artifact can remain byte-for-byte unchanged between editions.

Resolution fixes the exact Library edition plus the manifest digest and file-set digest of every referenced library artifact.

Validation and execution MUST use that same edition and content. An implementation MUST NOT combine a manifest from one edition with fixtures, data, or semantics from another, even when their namespaces and signatures appear compatible.

Built-in Filters and Standard Filter Packages

Built-in filters and Standard Library filter packages are distinct surfaces. The Core Executor obligation for the complete bare filter set is defined under Core Executor Conformance.

The resolution and namespace restrictions for bare filters are defined under Built-in Filters. The portable escaping, encoding, and hashing primitives listed under Built-in Filters remain part of that surface.

This edition includes html_escape, json_escape, url_encode, base64, and sha256. Their bare names and exact algorithms are part of Workfile Core rather than optional library packages.

A Standard Library filter package contains specialized behavior under a canonical dotted namespace.

Note. This specification defines no generic shell-quoting filter because quoting semantics require a named target dialect, and it defines no MD5 filter.

This edition defines the following package identities. Their selected manifests supply filter and signature declarations, including additional entries, subject to this edition’s prose-authority rule under Normative and Informative Content.

Namespace	Purpose
text	Text normalization and presentation operations outside the base requirements.
html	Structured HTML inspection.
money	Currency parsing, minor-unit conversion, and display.
rank	Operations over declared ordinal scales.
workweek	Calendar-aware workweek operations.
human	Locale-specific human-readable formatting.
url	Structured URL operations beyond percent encoding.
markup	Markup conversion and manipulation.
match	Deterministic similarity and edit-distance operations.
phone	Telephone-number parsing and formatting.

This edition assigns the following presentation filters to Standard Library packages.

They are referenced by dotted name and are not built-in filters:

Filter	Signature and behavior
text.capitalize	string -> string; uppercases the first Unicode Cased character and lowercases later Cased characters.
text.title	string -> string; applies text.capitalize to maximal runs of characters without the Unicode White_Space property.
text.format(fmt: string)	list[any] -> string; each {} consumes one member and converts it with the built-in string filter, while {{ and }} emit braces. A member outside that filter’s domain or an arity mismatch faults.
text.truncate(n: int)	string -> string; at most nonnegative n code points, without a marker.
text.indent(n: int)	string -> string; prefixes every line with nonnegative n spaces.
text.wordwrap(n: int)	string -> string; wraps at Unicode White_Space to positive n code points without breaking longer words.
text.pluralize(one: string, many: string)	int -> string; one for 1, otherwise many.
human.human_size	int -> string; decimal byte units as defined below.
html.strip_html	string -> string; removes markup as defined below.
markup.md_to_html	string -> safe_html; converts the package’s declared Markdown dialect to HTML, escaping or removing raw HTML and other unsafe constructs as required by that package’s normative contract.

human.human_size uses powers of 1000 and B, kB, MB, GB, TB, and PB. It selects the largest unit whose magnitude is at least one and prints one decimal place, except that bytes have none.

A single space precedes the unit. An implementation of the optional html package parses html.strip_html input with the HTML fragment-parsing algorithm in a body context under HTML Snapshot.

html.strip_html removes every script and style element with its descendants, then concatenates the remaining text-node contents in tree order. It replaces each run of characters having the Unicode White_Space property with one U+0020 SPACE and removes leading and trailing White_Space characters.

HTML parsing performs named and numeric character-reference decoding under the same snapshot. Each package MUST conform to Filter Package Manifests.

Locale, calendar, currency, numbering-plan, or similar tables used by a filter are immutable package files covered by its file-set digest; a filter MUST NOT fetch current data during evaluation. An implementation is not required to provide every Standard Library filter package merely because it conforms to Workfile Core.

An implementation MUST provide and correctly identify a package when a Workfile references it and the deployment claims support for that resolved workflow, or when a conformance claim expressly includes that package; otherwise the valid Workfile is unsupported for that target. A package implementation MUST NOT add undeclared filters or give canonical names implementation-specific behavior.

Standard Connector Definitions

This edition defines the following canonical connector identities. Their manifests are the authoritative lists of actions, triggers, fields, errors, and operational promises; accompanying semantic descriptions and conformance cases complete their contracts.

Namespace	Contract
time	Current-time observation and scheduled initiation.
store	Atomic cross-run state over individual keys.
blob	External byte storage represented by file values.
sync	Cross-run identity and change-tracking records.
http	Generic HTTP interaction and external HTTP event ingestion.
data	Deterministic inspection and parsing of file content.
llm	Provider-neutral model operations.

Every canonical connector manifest MUST conform to Connector Manifests, use its registered canonical namespace, and carry the current Standard revision. A library trigger uses the capability-activation rule defined under Inferred Capability Requirements.

The canonical time.now action returns in observed_at the current instant observed when that action invocation executes. It is nondeterministic and its result is governed by the ordinary action-result recording and replay rules.

A library action receives no exception from ordinary connection, effects, idempotency, validation, failure, ambiguity, or dry-run rules. The credential-free canonical time, data, and store manifests declare auth: { type: none }.

A deployment connection for one of them supplies no authentication credential, though other declared connection fields and deployment policy still apply. The boundary between Core Executor conformance and optional canonical connectors is defined under Core Executor Conformance.

When a referenced connector is unavailable, lacks a compatible connection, or requires an unclaimed capability, Static Validation classifies the Workfile as unsupported and prohibits execution. The validator boundary for credentials and executable connections is defined under Core Validator Conformance.

An implementation MUST NOT publish a different connector under a canonical namespace, add private operations to a canonical manifest, strengthen or weaken its declared types or classifications, or substitute provider-specific semantics. A materially different integration requires a vendor namespace.

Deployment policy can restrict a canonical connector or decline to configure it, but MUST NOT present restricted or changed behavior as the canonical contract.