Skip to content

WEFT: Full Specification

Woven Ecosystem for Federated Trust

How a governed artifact travels across a federation, stays coherent under governance, and remains attributable.

Author: Dr. Jack Hong

Version: 0.5 | Candidate Standard | 2026

License: CC BY 4.0


Requirements language (RFC 2119 / BCP 14). The keywords MUST, MUST NOT, REQUIRED, SHALL, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted per RFC 2119 and RFC 8174 when written in capitals.

What “trust” means here. WEFT uses “trust” in a precise sense: the federation staying coherent and attributable under governance. This is deliberately not agent trust-verification, which is EATP’s concern. WEFT’s provenance stops at attribution. It records that a change happened and by which identity reference; it does not sign, and it does not resolve identity. Signing, identity, and anchoring cross a defined seam to EATP; authorization is deferred to PACT.


If you are not a specialist, read this first.

Organisations increasingly steer AI systems with governed artifacts: written rules, policies, and configurations that say what an AI may and may not do. When many teams or organisations share these rules, a problem appears. How does a rule written in one place reach everywhere it should, stay consistent, and stay traceable to a responsible person, without a central system silently pushing changes onto everyone?

WEFT is a proposed open standard for that movement. Three properties define it:

  • A change starts in one place (the “canon”) and reaches others only when they choose to pull it. Nothing is pushed automatically.
  • Every change is recorded and attributable to a responsible party, so you can trace who changed a rule.
  • A human must approve a change before it spreads. Machines do not rewrite the rules on their own.

Two candid caveats follow from the design:

  1. Whoever runs “canon” holds real power. WEFT limits how changes move (pull, not push) but is deliberately silent about what the rules say. That neutrality aids adoption, and it is a limitation: WEFT alone does not judge whether a rule is good, lawful, or fair. The safeguards for that live in the human gate, the threat model, and the transparency controls, not in content inspection.
  2. Recording every change against a person is powerful and double-edged. It supports accountability and it can become surveillance. The Data Protection section makes pseudonymity (on by default for federations that touch workers or the public), retention limits, and erasure first-class requirements.

The rest of this page is written for implementers and reviewers.


WEFT specifies how a single governed artifact, once it exists in one repository of a federation, is distributed to other members with its provenance intact, kept convergent on a canonical source under governance, and fed through a human-gated refinement loop. WEFT does not say what a good artifact contains. It says how any governed artifact travels, stays convergent, and is refined while remaining attributable.

WEFT is a distribution-and-reconciliation standard. It is not a methodology, not a code-generation standard, and not a trust-verification protocol. Its provenance facet stops at attribution. Identity, signing, and anchoring sit across a seam with EATP; authorization is deferred to PACT (a ratified standard, cited rather than co-designed). The unit WEFT defines, the Managed Governed Artifact (MGA), is set out in the Definitions section below.

The same unit serves two scales. A community profile is specified with an open reference implementation and stands on its own today. An enterprise profile (multi-tenant, cross-ecosystem) is under implementation across three organisations. The remaining evidence gaps, a public conformance suite and an independent interoperating implementation, are exit criteria for Published status and are named openly.

A note on “interoperability”: WEFT primarily specifies distribution and replication among repositories running WEFT. True interoperability, meaning two independent implementations exchanging artifacts, is what the conformance suite establishes, and it is not yet demonstrated. This document uses “distribution cascade” and reserves “interoperability” for the independent-implementation case.


CARE (Philosophy) What is the human for?
EATP (Protocol) How do we verify trust in an agent's actions?
CO (Methodology) How does the human structure the work?
PACT (Architecture) How is autonomy constrained through accountability?
WEFT (Distribution) How does a governed artifact propagate and stay
coherent across a federation, under governance,
with attribution intact?

The artifacts WEFT cascades may be CARE, CO, or PACT artifacts, but WEFT is content-agnostic. Its provenance is attribution-only and adjacent to EATP and PACT: it records that a mutation occurred and by which opaque identity reference. It defers who is authorized (PACT’s Operating Envelope), identity verification and signing (EATP), and anchoring (EATP’s Audit Anchor) across the seam. Where earlier drafts placed identity, trust, and authority semantics inside WEFT’s envelope, this version removes them: they belong to EATP and PACT.


  • Governed artifact. A file placed under managed distribution because it steers behaviour (a rule, policy, classification, skill, agent, command, hook, validator, or extract). By stipulation in this standard, a governed artifact’s mutations carry an attribution event and pass a human classification gate. This is a scope boundary, not a claim to decide “governed versus not” for arbitrary files.
  • Federation. A declared set of repositories (“members”) sharing one canonical source and agreeing to the WEFT distribution model. Membership is explicit: a member appears in the canonical manifest’s target set.
  • Member / consumer. A repository that pulls from canon.
  • Canon (base and effective). Base canon is the pre-overlay canonical artifact. Effective canon for a member is base canon composed with that member’s declared variant overlays and any changes the member has formally declined. A consumer runs effective canon. “Single source of truth” therefore means base plus a bounded, declared set of overlays and declines, not one byte-identical file everywhere.
  • Divergence. A member’s on-disk artifact differing from its effective canon. It is intentional if it corresponds to a declared overlay or a declared decline, and accidental drift if it is an undeclared delta. The discriminator is the declaration: an undeclared local edit is drift, and the maintenance primitive MUST classify it as such and surface it for human disposition, never silently reconcile or ignore it.
  • Tier and reach (distinct from clearance). A WEFT tier is a coarse classification of how far an artifact is distributed. What binds who must approve a change is the artifact’s reach: the tier composed with the declared member-count it reaches. Higher reach binds a stricter human gate. Tier alone is a proxy; reach is the binding datum, so a low-tier but high-reach change still triggers the strict gate. A WEFT tier or reach is orthogonal to PACT’s Knowledge Clearance, which governs read access; the two share no ordering and MUST NOT be conflated.
  • Public-facing federation. A federation is public-facing if its cascaded artifacts govern systems that affect the public, or if its recorded parties include workers who did not individually consent to attribution. This predicate arms the pseudonymity-default and public-transparency requirements. Because it gates those protections, the determination MUST be recorded, MUST pass the human gate, and MUST be externally visible. A federation MUST NOT self-classify as non-public-facing to escape those protections without that gated, visible determination. When in doubt, the federation is public-facing.
  • Managed Governed Artifact (MGA). The unit WEFT defines: a governed artifact considered together with its classification (where it goes; who approves it) and its provenance (attribution). The three facets sit at different scopes (content per-artifact, classification federation-wide in the manifest, provenance per-mutation) and are not one physical object. No minimality or “atom” claim is made.

WEFT recapitulates mechanisms with mature, deployed antecedents. Honesty about them is a precondition for any novelty claim.

Prior artWhat it already doesWEFT’s delta
Pull-based GitOps (Flux, ArgoCD, auto-sync off)Detect drift; reconcile only on operator-initiated sync; no write across the pull boundaryA governance-typed classification whose reach binds who must approve a change, plus a per-mutation attribution requirement, on the same pull model, standardised rather than tooled
Kustomize overlays / Puppet HieraHierarchical or variant merge (replacement or addition)The same at whole-file granularity, tied to the governance classification; the reach-binding of the approval gate is the delta over a plain hierarchy
in-toto / SLSA / DSSESeparate a statement format from its signing envelope; attested provenanceThe format-and-signing split is owned across the seam by EATP, not by WEFT; WEFT does not mint or mandate a signing envelope
git fork plus upstream; Android repo plus manifestFork sees upstream, cherry-picks per change; manifest binds reposCross-ecosystem gated pull with a declared decline recorded as first-class provenance
CRDT tombstones; state: absentConvergent replication; deletion via tombstoneObsoletion as a declarative tombstone restricted to an enumerated structural set
Certificate TransparencyPublic, externally verifiable append-only log of concentrated-authority actionsApplied to canon-level actions as an optional or required public transparency projection

The honest, narrow delta: a governance-typed classification whose reach binds the human approval gate (who must approve scales with how many members a change reaches, not just where a file goes), plus per-mutation attribution, welded onto pull-based distribution and specified as a domain-neutral standard. WEFT does not claim to invent pull reconciliation, overlay merge, hash chaining, forks, or signing. The demonstration that the model is domain-neutral is in production: regulatory and standards content (EU AI Act, ISO/IEC 27001, ISO/IEC 42001, and sectoral frameworks) is cascaded as MGAs alongside code artifacts.


WEFT is the governed-artifact distribution machine: the governance-typed classification that decides where an artifact travels and who approves it; whole-file overlay selection; per-mutation attribution; the governed-convergence property; the governed-refinement non-bypass invariant.

WEFT is not a methodology (that is CO’s concern), a code-generation standard, or an agent-runtime or trust-verification protocol. Its provenance stops at attribution; identity, signing, and authorization are EATP’s and PACT’s.

Content-blindness is a deliberate limitation, not an unqualified virtue. WEFT treats content as opaque at file granularity so it can serve any domain. The cost is that WEFT alone offers no judgment of legitimacy, quality, or public-interest impact. The safeguards against that cost are the human gate, the threat model, and the transparency controls, not content inspection.


Three facets at three scopes. WEFT claims only that a conformant distributor must handle all three.

  1. Content (per-artifact). One governed artifact file, opaque bytes at file granularity.

  2. Classification (federation-wide, manifest-declared). The artifact’s governance-typed tier and its reach (the member-count it distributes to), plus variant-overlay membership, declared in one manifest. This determines where it is distributed and, through reach, who must approve it. Overlay is whole-file: a variant provides a whole file that replaces or is added alongside the global file. There is no intra-file merge, which would contradict content-blindness. The overlay axis is fixed at stack and language; multi-organisation and multi-tenant variation is expressed by tenant forks, each carrying its own declared overlay set along that axis, not by a new inline overlay dimension. A future inline client axis remains a backward-compatible extension point.

  3. Provenance (per-mutation). An attribution-only structural envelope recording that a mutation occurred and binding it to an opaque identity reference:

    { schema_version, kind, ts, session, identity_ref, payload, prev_link }
    • kind is drawn from distribution-mechanical kinds only: Mint, Distribute, Decline, Obsolete, HumanGate. Each lifecycle step emits its named kind. The human classification decision is the human gate and is recorded as HumanGate. WEFT deliberately does not define trust-lineage kinds; a delegation or decision taxonomy would collide with EATP’s Delegation Record and PACT’s accountability grammar, so any such kind, if needed, is defined by EATP or PACT and only referenced by WEFT.
    • identity_ref is an opaque reference resolved by an EATP-class plane to an attributable identity. WEFT does not define identity verification and does not carry verified-identity fields as normative. It is attribution, not authority: it records who acted, never who was authorized. Authorization is PACT’s Operating Envelope, deferred across the seam.
    • prev_link is the prior event’s content hash, a per-emitter chain that proves ordering only.
    • payload MUST carry only distribution-mechanical data appropriate to its kind (the classification and routing decision, the target set, a content hash). It MUST NOT carry identity, authority, trust, or delegation semantics; those live on EATP’s and PACT’s side of the seam.
    • ts and session are distribution-mechanical metadata (a timestamp and an opaque session correlator). Like payload, they MUST NOT encode identity or authority semantics.

    Two profiles, three distinct guarantees. The base envelope is unsigned: the prev_link chain proves internal ordering, not authenticity. So the community profile delivers traceability and ordering only, not an audit record, and MUST NOT be represented as one. The enterprise profile anchors each event in an EATP Audit Anchor: the WEFT event becomes the subject that the Audit Anchor signs and anchors, yielding non-repudiation (who did what, when, signed) and tamper-evidence (an immutable log). Equivocation-resistance (Certificate-Transparency grade) is a third, separate guarantee that requires EATP’s Complete-tier external witness binding; signing alone does not provide it. WEFT does not itself sign. The guarantees are EATP’s, invoked by WEFT. The signed enterprise profile depends on EATP v3, which is drafted but not yet released, so it is not yet constructible by adopters.

    Event-format versioning. schema_version is evolvable. A verifier that encounters an unknown kind MUST ignore it for interpretation but MUST preserve it for chain continuity (must-ignore, not must-reject). A chain MUST remain verifiable across a schema_version boundary, and a conformance vector MUST exercise a cross-version chain.

    Durability by class. Low-stakes observations MAY be best-effort. Provenance for the mint, human-gated classification, and distribution of a compliance-class artifact MUST be durably persisted before the next dependent action, and a verifier MUST be able to detect and report a chain gap.

Why classification and provenance, and not content alone: content with no classification cannot be routed; content with no attribution cascades untraceably. This is a sufficiency argument for a distributor’s responsibilities, not a minimality proof.


MINT -> CLASSIFY -> DISTRIBUTE -> PULL -> OBSERVE -> CONVERGE / REFINE

Normative statements are observable properties; reference mechanisms are informative.

  • MINT. A governed artifact enters distribution only through an origination path that produces a Mint attribution event. A bare edit at the distributor with no Mint event MUST NOT enter the cascade.
  • CLASSIFY (human gate). Each change MUST be classified (global, variant, or skip) by a human, recorded as an event of kind: HumanGate distinct from any observation or automated-suggestion source. Automated suggestion is permitted; automated placement is not. WEFT’s human gate reuses PACT constructs by reference: the “approver is not the proposer” rule follows PACT’s self-approval-prevention discipline, and the held human decision follows EATP’s verification gradient as applied by PACT. For any change whose reach meets a federation-declared threshold, classification and approval MUST satisfy three conditions: an approver independent of the proposing authority (for a PACT-adopting federation, independence is positional, so a subordinate of the proposer is not independent either, not merely a different individual); recusal of conflicted parties, not mere disclosure; and a contestation path whose reviewing body MUST NOT sit within the proposing authority’s chain. The declared reach threshold MUST NOT exceed a federation-published ceiling, and the threshold declaration MUST itself pass the human gate and be externally visible: a federation MUST NOT set an unreachably high threshold to escape the strict gate. WEFT records who approved, not who was entitled to.
  • DISTRIBUTE. Distribution MUST NOT mutate a consumer’s working tree directly. The landed change MUST arrive as a reviewable proposal that the consumer approves, recorded as a Distribute event.
  • PULL. Consumers pull on their own cadence, except for compliance-class canon, which is subject to the reach window described under Governed Convergence. Distribution is reach-all-by-classify-then-pull, never an autonomous push. “Consumer-initiated” is organisation-controlled, not individual-consented; individuals are addressed by the Data Protection section, and reach past the organisation boundary is addressed by Public Transparency.
  • OBSERVE, CONVERGE, REFINE. Covered in the next two sections.

A property with a stated precondition, not merely a mechanism.

Property. If every member pulls at least once after canon quiesces, then each member’s on-disk artifacts equal its effective canon (base composed with that member’s declared overlays and declared declines). Because effective canon includes a member’s declared declines, a member that has formally declined a change and then pulls does satisfy the equality: a decline is part of that member’s effective canon, not a divergence. Absent the liveness precondition there is no bounded-time guarantee. A member that never pulls never converges, and WEFT states this openly.

  • S-CONVERGE-1 (detect without mutating). A conformant distributor MUST detect divergence from effective canon without mutating the consumer. The maintenance primitive MUST be read-only at the source and MUST NOT emit an auto-apply action across the pull boundary.
  • S-CONVERGE-2a (consumer-initiated only). Reconciliation MUST occur only through a consumer-initiated pull. No autonomous push.
  • S-CONVERGE-2b (declared decline is first-class). A member MAY record a declared decline (a Decline event tied to an attributable identity). A declined change becomes part of that member’s effective canon and MUST NOT be re-flagged as accidental drift.
  • S-CONVERGE-3 (scoped obsoletion). Declarative federation-wide obsoletion is the sole exception to additive, target-preserving merge, and it is restricted to a closed, enumerated set of structural artifact classes: directory-layout paths of a superseded layout; relocated artifact paths whose content moved under a declared migration; and deprecated manifest keys. Obsoletion of any governance-content artifact is out of this set and MUST require heightened, independently-reviewed, provenance-logged, and contestable authorisation, signalled separately from a routine pull. Re-classifying a content artifact as “structural” to bypass this MUST itself pass the human gate and be externally visible.
  • S-CONVERGE-4 (reach attestation; no silent non-convergence). For a compliance-class canonical change, each member MUST pull or explicitly decline within a declared window, and the source MUST be able to measure and attest fleet-wide reach. This preserves no-autonomous-push while adding a no-silent-non-convergence invariant. Reach attestation counts repositories, not individuals, and is distinct from the person-level concerns of the Data Protection section.

Observed operation becomes improved artifacts only through a human gate. The root of this discipline is CO’s learning layer: human review before captured patterns formalise, and no auto-promotion. PACT’s observation-sink discipline is a sibling instantiation of the same root at the agent-runtime layer, and WEFT’s refinement requirements are a third sibling at the distribution layer. WEFT cites the CO learning layer as the root and the PACT discipline as a peer, not as a dependency.

  • S-REFINE-1 (attributable mutation). Every artifact mutation MUST emit an attribution event, subject to durability-by-class.
  • S-REFINE-2 (separate observation channel). Observations MUST be emitted to a channel distinct from the provenance chain.
  • S-REFINE-3 (non-bypass human gate). No minted artifact’s provenance chain may originate from the observation channel without an intervening HumanGate event. An observed pattern cannot become a cascaded artifact by any path that bypasses a recorded human decision.
  • S-REFINE-4 (fail-closed). A distributor MUST refuse to operate if no human-gate mechanism is configured, and MUST refuse to operate if no observation channel is configured. Either omission alone is disqualifying. There is no “no gate” mode and no “no observation” mode.

Whatever an identity_ref resolves to, where it identifies a person, is personal data. A standard that mandates per-mutation attribution MUST treat its resolved identities as a personal-data pipeline.

  • DP-1 (pseudonymity, default-on where people are touched). An implementation MUST support a pseudonymous or role-identity mode in which identity_ref resolves to a role or pseudonym rather than a directly-identifying person, with re-identification available only to authorised parties under recorded authority. For any public-facing federation, or one whose recorded parties are workers, pseudonymity mode MUST be the default, overridable only under a recorded lawful basis, not merely “offered”.
  • DP-2 (retention and erasure). A federation MUST declare a retention policy for identity-resolving provenance and MUST define how it reconciles erasure rights with the append-only chain (crypto-erasure or pseudonym revocation that preserves chain integrity while removing the identifying datum). “Permanent, append-only” is not an acceptable default for identity-resolving records.
  • DP-3 (cross-border). Cascade of identity-resolving provenance across an ecosystem or jurisdictional boundary MUST be explicit opt-in with a recorded lawful basis, respecting each jurisdiction’s residency rules. Path-relativization protects paths, not persons, and is not sufficient.
  • DP-4 (purpose limitation, auditable). Provenance is a governance-integrity mechanism. An implementation MUST NOT repurpose it as a performance-monitoring or disciplinary instrument, MUST log access to identity-resolving provenance and scope it to declared purposes so a breach is detectable, and SHOULD declare permissible uses to the recorded parties.

Content-blind, federation-wide distribution is a blast-radius multiplier. “Consumer-initiated pull” bounds timing, not blast radius.

  • TM-1 (canon compromise). A compromised or erroneous canon reaches every member that pulls. An implementation MUST make content integrity verifiable by the consumer before convergence; for regulated use this depends on the attestation plane across the seam.
  • TM-2 (malicious or erroneous obsoletion). Beyond the scoping of S-CONVERGE-3, an implementation SHOULD provide rollback or quarantine, so a consumer can hold and reverse an obsoletion before it takes effect.
  • TM-3 (poisoned origination). Compliance-class origination MUST carry the reach-scoped human gate and SHOULD carry signed provenance across the seam.
  • TM-4 (gate bypass). For reach-scoped and compliance-class artifacts, the software gate MUST be non-bypassable by construction: no code path mints without a HumanGate event. This is a software-observable property. It does not, and cannot, bind an operator with full host access; that residual risk is a deployment and governance concern, named here, not a software-conformance claim.

Public transparency and external inspection

Section titled “Public transparency and external inspection”

Provenance that only the operator can read is accountability pointed down at individuals with none pointed up at canon.

  • PT-1 (public transparency log). A public-facing federation MUST operate a publicly readable, append-only transparency log recording canon-level actions (mint, obsoletion, high-tier classification, structural re-classification) so any external party can see what canon does. Before anchoring, this log provides public visibility and structural reviewability, not audit-grade cryptographic verifiability: the underlying provenance is unsigned and ordering-only. Certificate-Transparency-style externally-verifiable guarantees (signed, equivocation-resistant log heads) are a post-seam property, not claimed here, and an operator MUST NOT represent the pre-anchor log as audit-grade. Public visibility of canon actions is real accountability even while unsigned: because per-mutation attribution of individuals is a MUST, canon-level visibility must be too.
  • PT-2 (external auditability). For compliance-class artifacts, an implementation MUST support external inspection of the relevant provenance by a party other than the operating organisation, subject to the Data Protection section. Before anchoring, this establishes visibility and ordering, not cryptographic non-repudiation; audit-grade external verification depends on the seam.
  • PT-3 (log is a projection, not a fourth record). The public transparency log MUST be a projection of already-authoritative records (WEFT provenance and, after the seam, EATP’s Audit Anchor), not an independent fourth log.

The conformance suite is in progress. The target (what conforms) is defined here so “conformant” has a referent. There are two conformance classes, split by who is bound.

(A) Software-conformance (a WEFT distributor implementation) MUST satisfy the audience-verifiable, software-observable statements: the convergence and refinement requirements; the classify human-gate-event and non-bypass requirements; distribute no-mutate and reviewable; the data-protection mechanisms that are software features (pseudonymity-mode support, access-logging, chain-gap detection); canon-integrity verifiability; and the software mechanism of the public transparency log. A WEFT provenance event MUST satisfy the envelope shape, the versioning contract, and durability-by-class.

(B) Deployment-conformance (the operating organisation) MUST satisfy the obligations that cannot be verified by inspecting software: pseudonymity actually enabled by default for public-facing or worker federations; retention; cross-border lawful basis; purpose limitation; the classify independence, recusal, and contestation governance; the constraint that an operator MUST NOT represent the pre-anchor log as audit-grade; and the residual host-access risk. A “WEFT-conformant deployment” claim requires both (A) and (B).

Each software MUST is an observable property: an event of a given kind exists or is absent; a chain verifies across a version boundary; a distribution arrived as a reviewable proposal; a chain gap is detectable. Requirements that are irreducibly process-attested (a human exercised judgment) are satisfied by the presence of the required HumanGate event distinct from the observation source. The event is the testable artifact; the judgment is attested, and the specification says so.


Community profile versus enterprise profile

Section titled “Community profile versus enterprise profile”
PropertyCommunity profile (specified; reference implementation exists)Enterprise profile (under implementation; tracked gaps)
TopologyOne canonical source plus a few consumersCanon plus N tenant forks; cross-ecosystem pull under implementation
CascadeClassify, distribute, pullPlus cross-ecosystem gated upstream-pull, in use across three organisations
ProvenanceUnsigned attribution envelope (not an audit record)Signed and anchored via EATP’s Audit Anchor (non-repudiable; depends on EATP v3, drafted but not yet released)
Overlay axisStack and languagePlus a tenant axis (deferred; expressed today via tenant forks)

The enterprise profile exercises the same MGA primitive at multi-tenant scale. The remaining evidence gaps (a public conformance suite; an independent implementation built from this specification that interoperates with the reference) are Published exit criteria, named openly. They do not gate Candidate status.


WEFT is honest about its evidence base. It is derived from one open reference implementation, deployed across three organisations, each adapting it to its own environment. That is real multi-organisation, multi-tenant deployment, but one implementation in the formal standards sense; environment adaptation is configuration, not an independent build. On that evidence, WEFT is advanced to Candidate: stable for implementation, with breaking changes strongly discouraged.

Domain-independence is demonstrated. Beyond software artifacts, the three-organisation deployment cascades a non-code artifact family, regulatory and standards content (EU AI Act, ISO/IEC 27001, ISO/IEC 42001, and sectoral frameworks), through the full MGA lifecycle in production. So the remaining gap to Published is implementation-independence, not domain-independence: WEFT runs in two domains but still on one implementation.

The path to Published has two open, tracked criteria:

  1. A public conformance suite (in progress), and
  2. At least one independent implementation built from this specification (not adapted from the reference) that interoperates through that suite.

Together these would give the two independent, interoperating implementations a Published Standard requires. The signed enterprise profile additionally depends on EATP v3, which is drafted but not yet released.

The specification is licensed under CC BY 4.0. The reference implementation is Apache 2.0, Foundation-owned, donated irrevocably by the individual contributor.


The mechanisms below are one way to satisfy the normative properties above. A conformant implementation MAY differ; nothing in this annex is normative.

  • A single classification manifest declares tiers, variants, variant-only files, exclusions, targets, obsoletions, and consumer overlays.
  • A three-valued whole-file overlay selection resolves each file to replacement, addition, or global-only.
  • Distribution runs in an isolated worktree built from the target’s remote main branch, so a reviewable proposal is prepared without touching the consumer’s working tree.
  • A per-session, append-only ledger re-derives its chain head on each run and relativizes paths.
  • A read-only fleet bucketer measures reach across member repositories without writing to them.
  • Version-chain re-anchoring occurs on contact, so a chain stays verifiable across a schema-version boundary.
  • An observe-then-digest-then-recodify loop produces candidate patterns for the human gate; it never promotes a pattern on its own.

Origination and improvement methods are composition examples, not machinery WEFT owns. Compliance-origination and the observe-to-recodify loop illustrate how an artifact may be minted or refined, but WEFT requires only that any mint or re-mint pass the human gate and carry attribution. WEFT does not own the improvement method itself.

Status. Intra-ecosystem, community-scale mechanisms are implemented and in use. Cross-ecosystem gated upstream-pull is under implementation across three organisations, expressed through tenant forks along the fixed stack-and-language overlay axis. Fork-to-canon write-back is a deliberate prohibition, not a missing feature. No deployment status is, by itself, evidence of implementation-independence; that gap is closed only by a second implementation built from this specification and interoperating through the conformance suite.