BernardLowe · Oct 10, 2026 · Oct 10, 2026 · Oct 10, 2026
diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
@@ -3,13 +3,15 @@ name: Build and deploy VitePress site
 on:
   push:
     branches: [main]
+  pull_request:
+    branches: [main]
   workflow_dispatch:
 
 permissions:
   contents: read
 
 concurrency:
-  group: github-pages
+  group: github-pages-${{ github.ref }}
   cancel-in-progress: false
 
 jobs:
@@ -25,16 +27,19 @@ jobs:
           node-version: 22
           cache: npm
       - uses: actions/configure-pages@v5
+        if: github.ref == 'refs/heads/main'
       - run: npm ci
       - run: npm test
       - run: npm run build
         env:
           BASE_PATH: /malt-web/
       - uses: actions/upload-pages-artifact@v4
+        if: github.ref == 'refs/heads/main'
         with:
           path: docs/.vitepress/dist
 
   deploy:
+    if: github.ref == 'refs/heads/main'
     needs: build
     runs-on: ubuntu-latest
     permissions:

diff --git a/README.md b/README.md
@@ -20,10 +20,10 @@ application concerns.
 ## Current Source and Verifier Pin
 
 Current source uses explicit typed authentication through
-`malt.authentication/3`, with Prefix and Positional trees. Retired Map/List,
+`malt.authentication/5`, with Prefix and Positional trees. Retired Map/List,
 Resolve/Read and Artifact compatibility adapters are removed. Applications
 select every traversal input as opaque label bytes, including the ordinary
-`@payload` label where required by their layout. Core rc.3 also offers optional
+`@payload` label where required by their layout. Core also offers optional
 `sdk/object` Map/List/Immutable constructors over these current contracts.
 
 The public verifier uses the supported `@dewebprotocol/malt/verifier` API and
@@ -32,8 +32,9 @@ copies WASM assets from the exact malt-ts commit pinned in `package-lock.json`.
 verifier asset-set digest, and the portable corpus digest. Run
 `npm run sync:verifier` after deliberately updating those pins; this website
 does not compile WASM or manage its own browser runtime. The current pin is
-SDK `0.0.3-rc.4` at `a145712a7a5f0759f4f2a8a64e42364947daaf41`, bound to
-Core `v0.0.10-rc.4` at `0d7b166d58d1c2e21ead96de9c66968caf630374`.
+SDK `0.0.3` at `735c894cb7dd4bbdfa7032c75f48f5f23820fd14`, bound to
+Core `v0.0.10` at `aaa78737c35f82fe91bb3f749cfddbcb7953ed2b`. The portable
+`authentication-v3.json` corpus is copied unchanged from that Core release.
 
 The Resolve tool calls the current Gateway typed query route. The Verify tool
 imports proof JSON locally and verifies only a query whose Root and request the
@@ -68,8 +69,9 @@ npm run preview
 
 ## Deployment
 
-GitHub Actions tests and builds each push to `main`, then publishes the static
-artifact to [GitHub Pages](https://dewebprotocol.github.io/malt-web/). Pages uses
+GitHub Actions tests and builds pull requests and each push to `main`. Main
+builds publish the static artifact to
+[GitHub Pages](https://dewebprotocol.github.io/malt-web/). Pages uses
 the Actions publishing source and the `github-pages` environment. The public
 site's base path is `/malt-web/`; local development defaults to `/`.
 

diff --git a/docs/.vitepress/config.ts b/docs/.vitepress/config.ts
@@ -29,8 +29,8 @@ export default defineConfig({
       { text: 'Docs', link: '/docs/runtime' },
       { text: 'Service', link: '/service' },
       {
-        text: 'Core v0.0.10-rc.3',
-        link: 'https://github.com/DeWebProtocol/malt-core/releases/tag/v0.0.10-rc.3'
+        text: 'Core v0.0.10',
+        link: 'https://github.com/DeWebProtocol/malt-core/releases/tag/v0.0.10'
       }
     ],
     sidebar: [

diff --git a/docs/.vitepress/theme/malt-client.mjs b/docs/.vitepress/theme/malt-client.mjs
@@ -1,4 +1,4 @@
-export const authenticationProfile = 'malt.authentication/3'
+export const authenticationProfile = 'malt.authentication/5'
 export const defaultGatewayURL = 'http://127.0.0.1:8080'
 
 export function buildAuthenticationURL(baseURL) {

diff --git a/docs/.vitepress/theme/verification-input.mjs b/docs/.vitepress/theme/verification-input.mjs
@@ -1,8 +1,8 @@
 export function verificationPairs(authentication) {
   if (!authentication || typeof authentication !== 'object') throw new Error('authentication evidence is required')
   const pairs = Object.entries(authentication).map(([name, pair]) => {
-    if (!['node', 'payload', 'range'].includes(name) || pair?.request?.profile !== 'malt.authentication/3' ||
-        pair?.result?.profile !== 'malt.authentication/3') throw new Error('unsupported authentication evidence')
+    if (!['node', 'payload', 'metadata', 'range'].includes(name) || pair?.request?.profile !== 'malt.authentication/5' ||
+        pair?.result?.profile !== 'malt.authentication/5') throw new Error('unsupported authentication evidence')
     return { name, request: pair.request, result: pair.result }
   })
   if (!pairs.length) throw new Error('authentication evidence is empty')

diff --git a/docs/concepts/list-map.md b/docs/concepts/list-map.md
@@ -17,12 +17,18 @@ uses by application convention. Generic relation structures need no payload.
 
 ## Positional
 
-A Positional Root authenticates indexed targets and sequence geometry. Direct
-labels encode uint64 indices as exactly eight unsigned big-endian bytes; text
-such as `"42"` is not an index encoding.
-Byte-range results bind metadata and ordered segment CIDs. Clients then check
-segment bytes, lengths and slicing. Positional Roots do not implicitly redirect
-through a payload selector.
+A Positional Root authenticates indexed targets, a count and an optional opaque
+payload CID. Only root slot zero stores metadata; all slots in non-root vectors
+hold content. For capacity 256, 255 elements fit in one vector; 256 elements
+require a root pointing to one full leaf vector. The count and capacity determine
+the tree shape, so height and per-node sizes are not stored.
+
+Direct labels encode uint64 indices as exactly eight unsigned big-endian bytes;
+text such as `"42"` is not an index encoding. Core range queries use element
+indices. Applications verify the bytes referenced by the payload CID and
+interpret their own format. UnixFS uses a JSON document for chunk width and
+file size, then verifies chunk CIDs and slices bytes locally. Heterogeneous
+sequences need no byte-size fields.
 
 ## Composition and updates
 

diff --git a/docs/docs/api.md b/docs/docs/api.md
@@ -6,7 +6,7 @@ Clients select an expected root and query, then verify the result locally.
 
 | Current route | Purpose |
 | --- | --- |
-| `POST /v1/authentication/query` | Resolve explicit label steps, prove a binding, or authenticate a byte range |
+| `POST /v1/authentication/query` | Resolve explicit label steps, prove a binding, or authenticate an element-index range |
 | `POST /v1/authentication/candidates` | Materialize a complete typed candidate in an unmanaged integration |
 | `POST /v1/authentication/batches` | Atomically materialize an ordered candidate batch with an exact receipt |
 | `POST /v1/cas` | Store payload bytes where the deployment permits unmanaged writes |
@@ -20,7 +20,7 @@ for deployment policy, including immutable CAS access.
 
 ```json
 {
-  "profile": "malt.authentication/3",
+  "profile": "malt.authentication/5",
   "root": "<caller-selected MALT Root CID>",
   "steps": [],
   "operation": "resolve"
@@ -31,11 +31,11 @@ for deployment policy, including immutable CAS access.
 uint64 indices as eight unsigned big-endian bytes. A binding request additionally
 selects `label`; a range
 request supplies `start` and optionally `end`, with an exclusive end. The
-[Core authentication contract](https://github.com/DeWebProtocol/malt-core/blob/v0.0.10-rc.4/docs/spec/authentication-contracts.md)
+[Core authentication contract](https://github.com/DeWebProtocol/malt-core/blob/v0.0.10/docs/spec/authentication-contracts.md)
 is normative for schemas and verification.
 
-Candidates use `malt.authentication/2`; batches use
-`malt.authentication-batch/1`; receipts use `malt.authentication-receipt/1`.
+Candidates use `malt.authentication/4`; batches use
+`malt.authentication-batch/2`; receipts use `malt.authentication-receipt/2`.
 An accepted receipt must bind the submitted transaction, base, root, batch
 digest and durable boundary. It records materialization, not a portable proof
 of a state transition or permission to promote a trusted root.

diff --git a/docs/docs/prooflists.md b/docs/docs/prooflists.md
@@ -1,6 +1,6 @@
 # Typed Authentication Proofs
 
-The current query profile is `malt.authentication/3`. An application constructs
+The current query profile is `malt.authentication/5`. An application constructs
 an explicit root, label traversal steps, and an operation: `resolve`, `binding`,
 or `range`. The untrusted executor returns traversal evidence and, when
 requested, binding or range evidence. Core verifies that result against the
@@ -30,8 +30,9 @@ metadata and ranges directly.
 
 ## Payload bytes and trust
 
-Range evidence binds ordered segment CIDs and geometry. Applications must also
-check downloaded segment bytes, lengths and slicing against that evidence.
+Range evidence binds element-index bounds, ordered CIDs, count and an optional
+metadata payload CID. Applications verify and decode that CID-bound document,
+then check downloaded chunk bytes, lengths and slicing using their own geometry.
 Verifying a proof alone does not check a displayed payload buffer.
 
 Proof validity is relative to the caller-selected snapshot. A proof does not

diff --git a/docs/docs/runtime.md b/docs/docs/runtime.md
@@ -14,8 +14,8 @@ narrow capabilities in `auth/arcset/materializer`. The old Map/List adapters,
 module-root facade, aggregate Store and Resolve/Read/client-root APIs are removed.
 Core does not own ArcTable persistence, CAS, HTTP, UnixFS or trust policy.
 
-Core `v0.0.10-rc.3` adds the optional [`sdk/object`
-API](https://github.com/DeWebProtocol/malt-core/blob/v0.0.10-rc.3/docs/guides/objects.md).
+Core `v0.0.10` provides the optional [`sdk/object`
+API](https://github.com/DeWebProtocol/malt-core/blob/v0.0.10/docs/guides/objects.md).
 Applications can compose Maps, Lists, immutable byte leaves and custom structs,
 commit their reachable references, then collect graph deltas for storage.
 These constructors use the current Prefix/Positional authentication contracts;
@@ -25,7 +25,8 @@ Persistence, publication and accepted-root policy remain with the caller.
 [`malt-ts`](https://github.com/DeWebProtocol/malt-ts) owns the supported
 TypeScript/JavaScript API, browser Workers and reproducible WASM distribution.
 Its API is separate from the Go Object API. Both this site's verifier and the
-Gateway Console now pin SDK `0.0.3-rc.4`, bound to published Core rc.4.
+Gateway Console pin SDK `0.0.3` at commit
+`735c894cb7dd4bbdfa7032c75f48f5f23820fd14`, bound to published Core `v0.0.10`.
 
 ## Gateway
 

diff --git a/docs/docs/unixfs-layout.md b/docs/docs/unixfs-layout.md
@@ -32,11 +32,15 @@ If traversal ends at a Prefix Root, content reading explicitly selects its
 ordinary application label `@payload`, encoded as `"QHBheWxvYWQ="`. A flat path
 that directly targets a payload or manifest needs no extra payload query. Core treats these bytes like every other label.
 
-Chunked files use Positional authentication with fixed-width geometry and
-ordered chunk CIDs. The local verified reader authenticates range evidence,
-fetches and checks segment bytes and lengths, then slices the requested range.
-A proof alone does not authenticate a displayed byte buffer. Encrypted UnixFS
-also checks the authenticated ciphertext width against its encrypted manifest.
+Chunked files use Positional authentication for count, an opaque metadata CID
+and ordered chunk CIDs. The root payload CID binds canonical
+`malt.unixfs.chunks/1` JSON containing `chunk_size` and `total_size` as decimal
+strings. The reader verifies those bytes and checks the geometry against the
+authenticated count before translating byte intervals into element-index queries.
+It then verifies range evidence, fetches and checks chunk bytes and lengths,
+and slices the requested interval. A proof alone does not authenticate a
+displayed byte buffer. Encrypted UnixFS also checks the CID-bound ciphertext
+width against its encrypted manifest.
 
 ## MALT Target Symlink Directory Boundary
 

diff --git a/docs/evaluation.md b/docs/evaluation.md
@@ -48,8 +48,9 @@ v0.0.5 `MALT-flat` result label is not a current runtime layout identifier.
 
 HAMT is a directory/map-relation baseline. Large-file range comparisons must
 also identify their chunk layout and payload-verification work. MALT range
-evidence authenticates chunk metadata and segment CIDs; the client still
-hashes fetched bytes and assembles the requested interval.
+evidence authenticates element-index bounds, count, an optional metadata CID
+and ordered chunk CIDs. The client verifies its CID-bound application geometry,
+hashes fetched chunks and assembles the requested byte interval.
 
 The [frozen harness record](/docs/evaluation#frozen-v0-0-5-harness) remains
 historical provenance. Its schemas, commands and results must not be relabeled

diff --git a/docs/index.md b/docs/index.md
@@ -61,7 +61,7 @@ import { withBase } from 'vitepress'
     </div>
     <div class="malt-strip">
       <strong>Current pre-v1 contracts</strong>
-      <span>Use explicit opaque labels with malt.authentication/3 and verify each result against the intended root and query.</span>
+      <span>Use explicit opaque labels with malt.authentication/5 and verify each result against the intended root and query.</span>
     </div>
     <div class="malt-strip">
       <strong>Filesystem boundary</strong>

diff --git a/docs/narrative/abstraction.md b/docs/narrative/abstraction.md
@@ -29,8 +29,8 @@ The two tree layouts serve different workloads:
 
 - **Prefix** authenticates keyed bindings and absence. A complete flat path may
   be a single label input; Core does not parse or group path segments.
-- **Positional** authenticates indexed bindings and count metadata. Its
-  fixed-chunk form also authenticates byte-layout metadata for range queries.
+- **Positional** authenticates indexed bindings, a count and an optional opaque
+  payload CID in the root. Applications interpret the referenced metadata.
 
 The current SDK exposes these through `derivation`, `auth/tree`, `engine`
 and `sdk/authentication`. Keyed and sequential application data no longer
@@ -43,7 +43,7 @@ at the current Root; a following step uses the reached Root's own descriptor.
 Applications choose all selectors and arc boundaries. There is no automatic
 longest-prefix grouping or implicit terminal payload redirect.
 
-The `malt.authentication/3` query contract supports resolve, binding and range
+The `malt.authentication/5` query contract supports resolve, binding and range
 operations. Local verification checks the caller's complete Root, requested
 steps, ordered continuity and final operation evidence. A missing binding
 proves where traversal stopped, without authenticating an unvisited suffix.
@@ -62,10 +62,12 @@ file and directory entries already point to their payload or manifest target.
 Large-file payloads use Positional chunk bindings. The three current UnixFS
 strategies are described in [UnixFS layouts](/docs/unixfs-layout).
 
-A Positional range result authenticates bounds, fixed chunk metadata and the
-ordered segment CIDs covered by the requested interval. The application must
-hash fetched bytes against those CIDs and assemble the requested slice. Core
-proof verification alone does not authenticate an arbitrary response body.
+A Positional range result authenticates element-index bounds, root metadata and
+the ordered CIDs in that interval. UnixFS verifies the JSON referenced by the
+root payload CID, checks its file size and chunk width against the authenticated
+count, and translates byte ranges into element-index queries. It then hashes
+fetched chunks and assembles the requested slice. Core proof verification alone
+does not authenticate an arbitrary response body.
 
 ## Updates and Trust
 

diff --git a/docs/narrative/evaluation-story.md b/docs/narrative/evaluation-story.md
@@ -23,14 +23,14 @@ The core read shape is:
 
 ```text
 Authenticate(root, label steps, resolve) -> destination + traversal evidence
-Authenticate(root, label steps, range) -> fixed-chunk metadata + segment bindings
+Authenticate(root, label steps, index range) -> count + metadata CID + element bindings
 Fetch and bind segment bytes -> requested byte interval
 ```
 
-The current typed range operation authenticates fixed chunk metadata, bounds
-and the ordered segment CIDs. The local runtime's UnixFS reader verifies that
-evidence against its selected Root, hashes fetched segment bytes, and assembles
-the requested slice. Proof and payload checks are separate measured work;
+The current typed range operation authenticates element-index bounds, count,
+an optional metadata CID and ordered element CIDs. The UnixFS reader verifies
+the referenced application JSON, translates byte intervals into index ranges,
+verifies those ranges against its selected Root, and hashes and slices chunks. Proof and payload checks are separate measured work;
 the removed `list_range` proof format and `VerifyRangeBody` helper are not
 current runtime APIs.
 

diff --git a/docs/narrative/system-design.md b/docs/narrative/system-design.md
@@ -74,13 +74,15 @@ reader explicitly queries the ordinary label `@payload`. A direct payload or
 manifest target needs no extra selector. Core treats this label as opaque bytes;
 the reserved-name policy belongs to the application or Object SDK.
 
-Range evidence authenticates fixed chunk metadata and selected chunk CIDs.
+Range evidence authenticates count, an optional metadata CID and selected
+element CIDs. UnixFS verifies its metadata JSON and translates byte ranges to
+element indices before checking chunk bytes.
 The reader then checks the fetched bytes and assembles the requested interval.
 The [UnixFS layout guide](/docs/unixfs-layout) describes the current strategies.
 
 The [Core repository](https://github.com/DeWebProtocol/malt-core) defines
 executable authentication semantics. The
 [local runtime](https://github.com/DeWebProtocol/malt) owns UnixFS and CLI
 behavior; its Go module path remains `github.com/dewebprotocol/malt-client`.
-Current source uses `malt.authentication/3`; exact release pins identify the
+Current source uses `malt.authentication/5`; exact release pins identify the
 implementation used by a deployed binary.
diff --git a/docs/overview.md b/docs/overview.md
@@ -42,7 +42,7 @@ MALT changes the boundary:
 - Prefix and Positional layouts are selected by a Root descriptor
 - KZG and IPA provide commitment backends
 - `engine` and `traversal` compose those primitives through narrow materializer capabilities
-- `malt.authentication/3` carries explicit queries and locally verified evidence
+- `malt.authentication/5` carries explicit queries and locally verified evidence
 - retained writers produce candidates and exact materialization batches
 - immutable payloads remain ordinary CAS data
 

diff --git a/docs/public/verifier/PROVENANCE.json b/docs/public/verifier/PROVENANCE.json
@@ -1,13 +1,13 @@
 {
   "schema": "malt.ts-verifier.provenance/v1",
   "source_repository": "https://github.com/DeWebProtocol/malt-ts.git",
-  "build_inputs_sha256": "9073c0f81dbe9baf8b0ee06e58b9c666a6f724fae3d07ae22b65d5735cd4c1b2",
+  "build_inputs_sha256": "610e2e0b50304b981e485d3e5f92db4b4552783a90671d1a26716d78d6d47396",
   "core": {
     "module_path": "github.com/dewebprotocol/malt-core",
-    "module_version": "v0.0.10-rc.4",
+    "module_version": "v0.0.10",
     "source_repository": "https://github.com/DeWebProtocol/malt-core.git",
-    "source_commit": "0d7b166d58d1c2e21ead96de9c66968caf630374",
-    "module_sum": "h1:BpA7vH0LwKTmipTlAUu97CniBXTxBT9f5AQWV8UFbmY=",
+    "source_commit": "aaa78737c35f82fe91bb3f749cfddbcb7953ed2b",
+    "module_sum": "h1:HgzuUot+AAKiLz20KdeUlnVDCVFHxfjQc7unsQOqm7Q=",
     "go_mod_sum": "h1:o6L8K9vJp5hyrVo3fUtSsj0rvNpcboOcOb3nQwnR/gs="
   },
   "target": "js/wasm",

diff --git a/docs/public/verifier/README.md b/docs/public/verifier/README.md
@@ -4,14 +4,17 @@ These files are copied byte-for-byte from the exact `@dewebprotocol/malt`
 package locked in `package-lock.json`. `verifier-source.json` records its
 malt-ts commit and version, the published Core source identity, the verifier
 asset-set digest, and the separately retained Core corpus digest.
+`authentication-v3.json` is copied unchanged from `conformance/` in the exact
+published Core release recorded by that pin; it is not generated by Web.
 
 The WASM, matching `wasm_exec.js`, `PROVENANCE.json`, and `SHA256SUMS` belong
 to malt-ts. Web preserves those files unchanged and imports the supported
 `@dewebprotocol/malt/verifier` API for browser initialization and verification.
 There is no Core checkout or Go/WASM compilation step in this repository.
 
-After a deliberate SDK dependency/pin update, run sequentially in the workspace
-CPU-limited scope:
+When updating the SDK dependency and pin, copy the matching Core corpus into
+this directory and record its SHA-256 in `verifier-source.json`. Then run
+sequentially in the workspace CPU-limited scope:
 
 ```sh
 npm ci