From 57bba0ab0b61e4869eaf3d2a048d65790095738b Mon Sep 17 00:00:00 2001 From: sierracatalina Date: Tue, 25 Aug 2026 16:19:53 -0400 Subject: [PATCH] fix(site): enforce Sierra editorial formatting --- docs/context-layer-ui-copy-boundary.md | 49 ++ docs/sierra-editorial-formatting.md | 68 +++ package.json | 4 +- scripts/format-context-layer-site.mjs | 142 ++++++ scripts/verify-context-layer-editorial.mjs | 349 ++++++++++++++ site/README.md | 2 + site/context-layer/_pages/architecture.html | 30 +- site/context-layer/_pages/code.html | 34 +- site/context-layer/_pages/demo.html | 180 ++++---- site/context-layer/_pages/essay.html | 148 +++--- site/context-layer/_pages/implementation.html | 342 +++++++------- site/context-layer/_pages/index.html | 14 +- site/context-layer/_pages/specification.html | 432 +++++++++--------- .../assets/context-layer-editorial.mjs | 275 +++++++++++ .../assets/context-layer-native.js | 2 +- .../demo/assets/context-layer.css | 1 - .../demo/assets/context-layer.js | 83 ++-- site/context-layer/demo/manifest.webmanifest | 6 +- .../downloads/context-layer-architecture.svg | 4 +- .../source/agent-navigation-manifest.json | 8 +- .../source/context-layer-blog-post.md | 4 +- ...yer-implementation-and-interoperability.md | 4 +- .../context-layer-technical-specification.md | 1 - site/icon.svg | 5 + tests/editorial-formatting.test.mjs | 35 ++ tests/public-site.test.mjs | 3 +- 26 files changed, 1579 insertions(+), 646 deletions(-) create mode 100644 docs/context-layer-ui-copy-boundary.md create mode 100644 docs/sierra-editorial-formatting.md create mode 100644 scripts/format-context-layer-site.mjs create mode 100644 scripts/verify-context-layer-editorial.mjs create mode 100644 site/context-layer/assets/context-layer-editorial.mjs create mode 100644 site/icon.svg create mode 100644 tests/editorial-formatting.test.mjs diff --git a/docs/context-layer-ui-copy-boundary.md b/docs/context-layer-ui-copy-boundary.md new file mode 100644 index 0000000..e382e9f --- /dev/null +++ b/docs/context-layer-ui-copy-boundary.md @@ -0,0 +1,49 @@ +# Context Layer UI copy boundary + +This file contains implementation guidance for agents and maintainers. None of +this guidance is public page copy. + +## Public copy contract + +The site-wide casing, punctuation, and type-role rules live in +[`sierra-editorial-formatting.md`](./sierra-editorial-formatting.md). Apply that +contract to every reader-facing Context Layer route and to copy generated after +page load. + +Reader-visible prose must do one of two things: + +- explain the Context Layer protocol, its limits, or its current implementation + status; +- describe an action the reader can take. + +Do not publish sentences about how the page, renderer, asset, or editorial +pipeline was constructed. Keep theme selection, canvas opacity, viewport +behavior, layout order, breakpoint goals, stylesheet packaging, archive +location, API configuration, allowlisted navigation, and publication workflow +in internal notes or verification code. + +Machine-facing artifacts such as `llms.txt`, schemas, source documents, and the +agent navigation manifest remain public when the protocol needs them. Do not +promote those endpoints as ordinary reader metadata unless a reader explicitly +enters a developer or machine-integration surface. + +## Deployment boundary + +- `site/context-layer/` is the canonical public documentation source. +- Vercel project `context-layer-public` must deploy with `site/` as its root. +- The standalone deployment rewrites `/` to the Context Layer index. It must not + replace the Sierra Catalina apex deployment. +- The Sierra host owns `/`, `robots.txt`, `sitemap.xml`, and the guide API. Its + scoped proxy exposes only the Context Layer routes from this deployment. + +## Publication checks + +- Run `npm run format:context-layer` after regenerating public HTML. +- Run `npm run verify:context-layer`, `npm run test`, `npm run lint`, and + `npm run release:hygiene` before publication. +- Review rendered text, not source files alone. +- Verify every canonical route at preview and production widths. +- Compare production responses with the canonical deployment so proxy drift + cannot hide stale copy. +- Treat sentences copied from agent instructions, design specifications, build + logs, or editorial workflow documents as suspect until rewritten for readers. diff --git a/docs/sierra-editorial-formatting.md b/docs/sierra-editorial-formatting.md new file mode 100644 index 0000000..c375fb9 --- /dev/null +++ b/docs/sierra-editorial-formatting.md @@ -0,0 +1,68 @@ +# Sierra editorial formatting + +This is an internal implementation contract for agents and maintainers. It is +not public page copy. + +## Reader-facing language + +- Lowercase ordinary prose, headings, navigation, labels, controls, metadata, + status messages, accessible names, and generated UI responses. +- Preserve `I`, proper names, acronyms, normative protocol keywords, versioned + identifiers, and established technical casing such as `AI`, `API`, `OpenAI`, + `OAuth`, `DPoP`, `GitHub`, `ActivityPub`, `SwiftUI`, and `macOS`. +- Use `&` instead of the standalone word `and`. Do not put a comma before `&`. +- In editorial narrative and interface copy, prefer single quotation marks, + use brackets rather than parentheses for asides, and do not use an em dash. + Normative specifications may retain standards punctuation where changing it + would reduce precision. +- Keep code, schemas, payloads, command output, URLs, email addresses, + user-authored input, and protocol source documents byte-for-byte intact. + +Do not use CSS as the editorial compliance mechanism. `text-transform` changes +presentation without fixing the DOM, copied text, accessible names, metadata, +or runtime-generated copy, and it cannot safely distinguish `AI` from ordinary +prose. A deliberately transformed short metadata label may remain decorative +only after its source text already satisfies this contract; body copy, +headlines, and technical identifiers must not depend on a transform. + +## Type roles + +- Display headings: Cormorant Garamond. +- Body copy: Lora. +- Navigation, indexes, labels, controls, and technical metadata: DM Mono. +- DM Sans is structural only and must not replace the display or body roles. + +## Enforcement boundaries + +`site/context-layer/assets/context-layer-editorial.mjs` is the shared formatter +for reader-facing copy. Its strict mode normalizes authored site copy against an +explicit casing glossary. Its conservative `preserveUnknownCase` mode is for +model-generated prose that has already been instructed to use lowercase +ordinary prose; that mode avoids destroying unfamiliar proper names and +acronyms. User-authored input must cross the UI boundary unchanged. + +`scripts/format-context-layer-site.mjs` applies strict normalization to the +seven generated pages in `site/context-layer/_pages/`. It skips technical +elements (`code`, `kbd`, `pre`, `samp`, `script`, `style`, `svg`, `textarea`, +and `var`) and never formats URL-bearing or data-bearing attributes. It does not +rewrite the Markdown protocol sources, schemas, fixtures, downloads, or +implementation artifacts published beside those pages. + +Runtime UI must select the boundary explicitly: + +- authored interface strings use strict normalization; +- generated guide prose uses conservative normalization; +- user questions and voice transcripts are rendered exactly as received; +- JSON and other technical renderings never pass through the prose formatter. + +Run these commands before publication: + +```text +npm run format:context-layer +npm run verify:context-layer +npm run test:site +``` + +The verifier must fail when ordinary capitals or the standalone word `and` +reappear outside protected technical content, or when a code, generated-copy, +or user-input boundary regresses. diff --git a/package.json b/package.json index 42ff62a..73a7b6c 100644 --- a/package.json +++ b/package.json @@ -18,10 +18,12 @@ "scripts": { "test": "npm run test:contracts && npm run test:site && npm run test:local-core && npm run test:proof", "test:contracts": "node --test tests/repository-boundary.test.mjs tests/reference-implementation.test.mjs", - "test:site": "node --test tests/public-site.test.mjs", + "test:site": "node --test tests/public-site.test.mjs tests/editorial-formatting.test.mjs", "test:local-core": "node --test tests/local-core.test.mjs tests/receipt-log-hardening.test.mjs", "test:proof": "node --test tests/local-core-demo.test.mjs tests/test-vectors.test.mjs", "demo:local-core": "node examples/local-core-demo.mjs", + "format:context-layer": "node scripts/format-context-layer-site.mjs", + "verify:context-layer": "node scripts/verify-context-layer-editorial.mjs", "release:hygiene": "node scripts/release-hygiene.mjs", "lint": "node node_modules/eslint/bin/eslint.js ." }, diff --git a/scripts/format-context-layer-site.mjs b/scripts/format-context-layer-site.mjs new file mode 100644 index 0000000..6969cdd --- /dev/null +++ b/scripts/format-context-layer-site.mjs @@ -0,0 +1,142 @@ +import { readFile, writeFile } from "node:fs/promises"; +import { resolve } from "node:path"; +import { pathToFileURL } from "node:url"; +import { formatEditorialText } from "../site/context-layer/assets/context-layer-editorial.mjs"; + +const root = resolve(import.meta.dirname, ".."); + +export const contextLayerPageNames = Object.freeze([ + "index", + "demo", + "architecture", + "specification", + "implementation", + "code", + "essay", +]); + +const protectedElements = new Set([ + "code", + "kbd", + "pre", + "samp", + "script", + "style", + "svg", + "textarea", + "var", +]); + +const voidElements = new Set([ + "area", + "base", + "br", + "col", + "embed", + "hr", + "img", + "input", + "link", + "meta", + "param", + "source", + "track", + "wbr", +]); + +/** + * Format authored reader-facing HTML while retaining technical elements, + * URL-bearing attributes, form values, and data payloads exactly as supplied. + */ +export function formatContextLayerHtml(html) { + const stack = []; + + return html + .split(/(<[^>]+>)/g) + .map((part) => { + if (!part.startsWith("<")) { + return stack.some((name) => protectedElements.has(name)) + ? part + : formatEditorialText(part, { html: true }); + } + + const closing = part.match(/^<\/([a-z0-9-]+)/i); + if (closing) { + const name = closing[1].toLowerCase(); + const index = stack.lastIndexOf(name); + if (index !== -1) stack.splice(index, 1); + return formatEditorialAttributes(part); + } + + const opening = part.match(/^<([a-z0-9-]+)/i); + if (opening && !/\/>$/.test(part)) { + const name = opening[1].toLowerCase(); + if (!voidElements.has(name)) stack.push(name); + } + + return formatEditorialAttributes(part); + }) + .join(""); +} + +export async function formatContextLayerPages({ check = false } = {}) { + const changed = []; + + for (const pageName of contextLayerPageNames) { + const pagePath = resolve(root, `site/context-layer/_pages/${pageName}.html`); + const html = await readFile(pagePath, "utf8"); + const formatted = formatContextLayerHtml(html); + if (formatted === html) continue; + + changed.push(pageName); + if (!check) await writeFile(pagePath, formatted, "utf8"); + } + + return changed; +} + +if (process.argv[1] && import.meta.url === pathToFileURL(resolve(process.argv[1])).href) { + const check = process.argv.includes("--check"); + const changed = await formatContextLayerPages({ check }); + + if (check && changed.length > 0) { + throw new Error(`editorial formatting required: ${changed.join(", ")}`); + } + + const action = check ? "verified" : "formatted"; + console.log(`${action} ${contextLayerPageNames.length} Context Layer pages with the Sierra editorial contract.`); +} + +function formatEditorialAttributes(tag) { + if (isProtectedTag(tag)) return tag; + + let formatted = tag.replace( + /\b(alt|aria-description|aria-label|data-guide-prompt|placeholder|title)=("([^"]*)"|'([^']*)')/gi, + (match, name, quotedValue, doubleValue, singleValue) => { + const quote = quotedValue[0]; + const value = doubleValue ?? singleValue ?? ""; + return `${name}=${quote}${formatEditorialText(value, { html: true })}${quote}`; + }, + ); + + if ( + /^ { + const quote = quotedValue[0]; + const value = doubleValue ?? singleValue ?? ""; + return `content=${quote}${formatEditorialText(value, { html: true })}${quote}`; + }, + ); + } + + return formatted; +} + +function isProtectedTag(tag) { + const name = tag.match(/^<\/?([a-z0-9-]+)/i)?.[1]?.toLowerCase(); + return name ? protectedElements.has(name) : false; +} diff --git a/scripts/verify-context-layer-editorial.mjs b/scripts/verify-context-layer-editorial.mjs new file mode 100644 index 0000000..976b940 --- /dev/null +++ b/scripts/verify-context-layer-editorial.mjs @@ -0,0 +1,349 @@ +import assert from "node:assert/strict"; +import { readFile, stat } from "node:fs/promises"; +import { resolve } from "node:path"; +import { pathToFileURL } from "node:url"; +import { + editorialCaseExceptions, + formatEditorialText, +} from "../site/context-layer/assets/context-layer-editorial.mjs"; +import { + contextLayerPageNames, + formatContextLayerHtml, +} from "./format-context-layer-site.mjs"; + +const root = resolve(import.meta.dirname, ".."); + +export async function verifyContextLayerEditorial() { + assert.equal(contextLayerPageNames.length, 7, "the editorial contract must cover all seven public pages"); + + const requiredFiles = [ + "docs/context-layer-ui-copy-boundary.md", + "docs/sierra-editorial-formatting.md", + "site/icon.svg", + "site/context-layer/assets/context-layer-editorial.mjs", + "site/context-layer/assets/context-layer-native.css", + "site/context-layer/assets/context-layer-native.js", + "site/context-layer/demo/assets/context-layer.css", + "site/context-layer/demo/assets/context-layer.js", + "site/context-layer/demo/manifest.webmanifest", + ...contextLayerPageNames.map((name) => `site/context-layer/_pages/${name}.html`), + ]; + + for (const file of requiredFiles) { + assert((await stat(resolve(root, file))).isFile(), `required editorial file missing: ${file}`); + } + + const pages = await Promise.all( + contextLayerPageNames.map(async (name) => [ + name, + await readFile(resolve(root, `site/context-layer/_pages/${name}.html`), "utf8"), + ]), + ); + + const deployment = JSON.parse(await readFile(resolve(root, "site/vercel.json"), "utf8")); + const rewriteMap = new Map(deployment.rewrites.map(({ source, destination }) => [source, destination])); + const expectedRoutes = new Map([ + ["/context-layer", "/context-layer/_pages/index.html"], + ["/context-layer/demo", "/context-layer/_pages/demo.html"], + ["/context-layer/architecture", "/context-layer/_pages/architecture.html"], + ["/context-layer/specification", "/context-layer/_pages/specification.html"], + ["/context-layer/implementation", "/context-layer/_pages/implementation.html"], + ["/context-layer/code", "/context-layer/_pages/code.html"], + ["/signal/the-context-layer", "/context-layer/_pages/essay.html"], + ]); + + for (const [route, destination] of expectedRoutes) { + assert.equal(rewriteMap.get(route), destination, `published route drifted: ${route}`); + } + + const allowedCasing = new Set(editorialCaseExceptions); + const forbiddenPublishedPhrases = [ + "responsive system map", + "every node remains legible at the current viewport", + "page scroll is the only navigation surface", + "secondary artifact", + "full-resolution system plate", + "compact map keeps", + "visible in one frame", + "page theme selects", + "matching opaque canvas", + "detailed sections continue below", + "theme-aware overview", + "sized to remain legible", + "reference archive", + "this view limits each pass", + "only after the layer model is clear", + "text is the default", + "navigate only to approved sections", + "without a configured api", + "website publication and deployment source", + "publication ui maintained separately", + "canonical local context", + "one-screen", + "source & implementation", + "rendered page follows", + "signal editorial contract", + ]; + for (const [name, html] of pages) { + assert.equal( + formatContextLayerHtml(html), + html, + `${name} page is not normalized; run npm run format:context-layer`, + ); + + const text = editorialText(html); + for (const phrase of forbiddenPublishedPhrases) { + assert( + !text.toLowerCase().includes(phrase), + `${name} page exposes internal authoring or rendering copy: ${phrase}`, + ); + } + assert(!text.includes("undefined"), `${name} page contains an unresolved render token`); + assert(!/\band\b/i.test(text), `${name} page must use & instead of the standalone word and`); + + const commaBeforeAmpersand = text.match(/.{0,80},\s*&.{0,80}/); + assert( + !commaBeforeAmpersand, + `${name} page must not place a comma before &: ${commaBeforeAmpersand?.[0] ?? ""}`, + ); + + for (const token of text.match(/\b[A-Za-z0-9-]*[A-Z][A-Za-z0-9-]*\b/g) ?? []) { + assert( + isAllowedEditorialCasing(token, allowedCasing), + `${name} page exposes non-editorial casing: ${token}`, + ); + } + } + + verifyFormatterBoundaries(); + await verifyRuntimeBoundaries(pages); + await verifyTypeRoles(); + await verifyMachineRoutes(); + + const essayHtml = pages.find(([name]) => name === "essay")?.[1] ?? ""; + const essayText = visibleText(essayHtml); + assert(!essayHtml.includes("""), "essay must use single quotation marks in reader prose"); + assert(!/\((?:MCP|A2A)\)/.test(essayText), "essay must use brackets for acronym asides"); + assert(!/[—]|—/.test(essayHtml), "essay must not use em dashes"); +} + +async function verifyMachineRoutes() { + const manifest = JSON.parse( + await readFile(resolve(root, "site/context-layer/source/agent-navigation-manifest.json"), "utf8"), + ); + assert.deepEqual( + manifest.public_routes.map(({ path }) => path), + [ + "/signal/the-context-layer", + "/context-layer/architecture", + "/context-layer/specification", + "/context-layer/implementation", + ], + "machine navigation must advertise canonical public routes", + ); + + const sourceEssay = await readFile( + resolve(root, "site/context-layer/source/context-layer-blog-post.md"), + "utf8", + ); + assert(!sourceEssay.includes("](/reference/"), "source essay must not advertise retired reference routes"); + assert(!sourceEssay.includes("](/writing/"), "source essay must not advertise retired writing routes"); +} + +if (process.argv[1] && import.meta.url === pathToFileURL(resolve(process.argv[1])).href) { + await verifyContextLayerEditorial(); + console.log( + `PASS Context Layer editorial contract: ${contextLayerPageNames.length} public pages plus static and runtime boundaries verified.`, + ); +} + +function verifyFormatterBoundaries() { + assert.equal( + formatEditorialText("Useful Context and OpenAI APIs"), + "useful context & OpenAI APIs", + "formatter must lowercase prose while preserving technical casing", + ); + assert.equal(formatEditorialText("API AND UI"), "API & UI", "uppercase AND must become an ampersand"); + assert.equal(formatEditorialText("USEFUL CONTEXT"), "useful context", "all-caps prose must normalize"); + assert.equal( + formatEditorialText("receivedAt and IDs"), + "receivedAt & IDs", + "camelCase identifiers and plural acronyms must retain casing", + ); + assert.equal( + formatEditorialText("https://Example.com/Foo-and-Bar"), + "https://Example.com/Foo-and-Bar", + "URLs must remain byte-for-byte intact", + ); + assert.equal( + formatEditorialText("Person@Example.com and OpenAI"), + "Person@Example.com & OpenAI", + "email addresses must remain byte-for-byte intact", + ); + assert.equal( + formatEditorialText("Ada Lovelace and José Álvarez use OpenAI APIs.", { preserveUnknownCase: true }), + "Ada Lovelace & José Álvarez use OpenAI APIs.", + "generated prose normalization must preserve unfamiliar proper names", + ); + assert.equal( + formatEditorialText("Use `API AND UI` and OpenAI."), + "use `API AND UI` & OpenAI.", + "inline code must remain byte-for-byte intact", + ); + assert.equal( + formatEditorialText("Before\n```js\nconst label = 'API AND UI';\n```\nAND after"), + "before\n```js\nconst label = 'API AND UI';\n```\n& after", + "fenced code must remain byte-for-byte intact", + ); + + const boundaryFixture = [ + '', + "

USEFUL CONTEXT AND OpenAI APIs

", + "
API AND UI
", + "", + '', + 'Link', + ].join(""); + const formatted = formatContextLayerHtml(boundaryFixture); + + assert(formatted.includes('content="useful context & OpenAI APIs"')); + assert(formatted.includes("

useful context & OpenAI APIs

")); + assert(formatted.includes("
API AND UI
"), "code elements must remain unchanged"); + assert(formatted.includes(""), "textarea input must remain unchanged"); + assert(formatted.includes('value="User AND API"'), "form values must remain unchanged"); + assert(formatted.includes('placeholder="ask OpenAI & continue"')); + assert(formatted.includes('href="https://Example.com/Foo-and-Bar"'), "URL attributes must remain unchanged"); + assert(formatted.includes('data-guide-prompt="ask OpenAI & continue"')); +} + +async function verifyRuntimeBoundaries(pages) { + const demoHtml = pages.find(([name]) => name === "demo")?.[1] ?? ""; + const demoJs = await readFile(resolve(root, "site/context-layer/demo/assets/context-layer.js"), "utf8"); + const demoCss = await readFile(resolve(root, "site/context-layer/demo/assets/context-layer.css"), "utf8"); + const nativeJs = await readFile(resolve(root, "site/context-layer/assets/context-layer-native.js"), "utf8"); + const manifest = JSON.parse( + await readFile(resolve(root, "site/context-layer/demo/manifest.webmanifest"), "utf8"), + ); + + assert( + demoHtml.includes(''), + "demo must load the shared formatter through the module runtime", + ); + assert( + demoJs.includes('import { formatEditorialText } from "../../assets/context-layer-editorial.mjs";'), + "runtime-generated UI must import the shared editorial formatter", + ); + assert(demoJs.includes("const editorial = (value)"), "authored runtime copy must use strict formatting"); + assert( + demoJs.includes("const editorialGenerated = (value)") && demoJs.includes("preserveUnknownCase: true"), + "generated guide copy must use conservative formatting", + ); + assert( + demoJs.includes("let answerFormatter = editorialGenerated") && + demoJs.includes("answerFormatter = editorial;") && + demoJs.includes("const answer = answerFormatter(response.answer)"), + "guide answers must select the generated or authored boundary explicitly", + ); + assert( + demoJs.includes('addTranscript("Guide", answer, null)'), + "formatted guide answers must not be transformed twice", + ); + assert( + demoJs.includes('addTranscript("You", question, null)'), + "user-authored questions must cross the transcript boundary unchanged", + ); + assert( + demoJs.includes("new SpeechSynthesisUtterance(answer)"), + "voice output must use the same normalized answer shown on screen", + ); + assert( + demoJs.includes('qs("[data-stage-code]").textContent = JSON.stringify(stage.data, null, 2);'), + "JSON renderings must bypass the prose formatter", + ); + + const transcriptRoleRule = demoCss.match(/\.guide-transcript strong\s*\{([^}]*)\}/)?.[1] ?? ""; + assert( + !transcriptRoleRule.includes("text-transform"), + "transcript labels must not rely on CSS casing", + ); + assert( + nativeJs.includes("`copy code snippet ${index + 1} to clipboard`"), + "copy control accessible names must comply in source", + ); + assert.equal(manifest.name, "context layer"); + assert.equal(manifest.short_name, "context layer"); + assert.equal( + manifest.description, + "a public interactive demonstration of the context layer working proposal.", + ); +} + +async function verifyTypeRoles() { + const nativeCss = await readFile(resolve(root, "site/context-layer/assets/context-layer-native.css"), "utf8"); + const demoCss = await readFile(resolve(root, "site/context-layer/demo/assets/context-layer.css"), "utf8"); + + for (const [label, css] of [["native", nativeCss], ["demo", demoCss]]) { + assert(css.includes("Cormorant Garamond"), `${label} CSS must retain the display typeface`); + assert(css.includes("Lora"), `${label} CSS must retain the body typeface`); + assert(css.includes("DM Mono"), `${label} CSS must retain the interface typeface`); + } +} + +function editorialText(html) { + const withoutTechnicalContent = html.replace( + /<(code|kbd|pre|samp|script|style|svg|textarea|var)\b[^>]*>[\s\S]*?<\/\1>/gi, + " technicalvalue ", + ); + const attributeValues = [ + ...withoutTechnicalContent.matchAll( + /\b(?:alt|aria-description|aria-label|data-guide-prompt|placeholder|title)=(?:"([^"]*)"|'([^']*)')/gi, + ), + ].map((match) => match[1] ?? match[2] ?? ""); + const metaValues = [...withoutTechnicalContent.matchAll(/]*>/gi)] + .map(([tag]) => { + if ( + !/\b(?:name|property)=["'](?:description|og:description|og:image:alt|og:title|twitter:description|twitter:image:alt|twitter:title)["']/i.test(tag) + ) { + return ""; + } + const match = tag.match(/\bcontent=(?:"([^"]*)"|'([^']*)')/i); + return match?.[1] ?? match?.[2] ?? ""; + }) + .filter(Boolean); + + return visibleText([withoutTechnicalContent, ...attributeValues, ...metaValues].join(" ")); +} + +function visibleText(html) { + return html + .replace(/]*>[\s\S]*?<\/script>/gi, " ") + .replace(/]*>[\s\S]*?<\/style>/gi, " ") + .replace(/<[^>]+>/g, " ") + .replace(/&/g, "&") + .replace(/'|'/g, "'") + .replace(/"/g, '"') + .replace(/\s+/g, " ") + .trim(); +} + +function isAllowedEditorialCasing(token, exceptions) { + if (exceptions.has(token)) return true; + if (/^[a-z]+(?:[A-Z][A-Za-z0-9]*)+$/.test(token)) return true; + if ( + /^(?=[A-Za-z0-9]*[a-z])(?=(?:[A-Za-z0-9]*[A-Z]){2})[A-Z][A-Za-z0-9]*$/.test(token) + ) { + return true; + } + + const parts = token.split("-"); + return ( + parts.length > 1 && + parts.some((part) => exceptions.has(part) || /^[a-z]+(?:[A-Z][A-Za-z0-9]*)+$/.test(part)) && + parts.every( + (part) => + exceptions.has(part) || + /^[a-z0-9]+$/.test(part) || + /^[a-z]+(?:[A-Z][A-Za-z0-9]*)+$/.test(part), + ) + ); +} diff --git a/site/README.md b/site/README.md index 6502137..221d06c 100644 --- a/site/README.md +++ b/site/README.md @@ -5,3 +5,5 @@ This directory contains the canonical public source for the Context Layer docume It is deliberately isolated from Sierra Catalina's personal-site application. The static route contract in `vercel.json` makes this directory independently previewable and deployable while preserving the production paths. Public protocol claims must remain consistent with the authoritative objects, schemas, and proof artifacts at the repository root. + +Before publication, run `npm run format:context-layer`, `npm run verify:context-layer`, `npm test`, `npm run lint`, and `npm run release:hygiene` from the repository root. Deploy this `site/` directory through the linked `context-layer-public` project; the Sierra host remains responsible for the apex homepage and proxies only the documented Context Layer routes. diff --git a/site/context-layer/_pages/architecture.html b/site/context-layer/_pages/architecture.html index 6dab9d3..43e5edf 100644 --- a/site/context-layer/_pages/architecture.html +++ b/site/context-layer/_pages/architecture.html @@ -4,18 +4,18 @@ - + - - + + - + -Context Layer architecture | sierra catalina +context layer architecture | sierra catalina @@ -44,16 +44,16 @@

the whole system.
one explicit boundary.

-

00 / one-screen overview

+

00 / protocol overview

the exchange at a glance.

-

the compact map keeps the six-step flow, explicit policy crossing, receipt rail & writeback loop visible in one frame.

+

six recorded steps move context from capture to bounded action. receipts record outcomes & route proposed writeback through policy.

-context layer architecture: capture, normalize, vault, decide, bundle and act, followed by a receipt and policy-bound writeback -context layer architecture: capture, normalize, vault, decide, bundle and act, followed by a receipt and policy-bound writeback +context layer architecture: capture, normalize, vault, decide, bundle & act, followed by a receipt & policy-bound writeback +context layer architecture: capture, normalize, vault, decide, bundle & act, followed by a receipt & policy-bound writeback
-
the page theme selects the matching opaque canvas. the detailed sections continue below.open the SVG ↗
+
capture, policy, scoped disclosure, action, receipts & writeback in one exchange.view full-size diagram ↗
@@ -107,17 +107,17 @@

each state has a receipt.

-

portable reference

-

one-screen protocol map.

-

the SVG is an opaque, theme-aware overview sized to remain legible in one frame on desktop & mobile. the detailed system map remains preserved in the reference archive.

+

protocol reference

+

the exchange in one map.

+

download a portable summary of the request, decision, disclosure, action & writeback lifecycle, or read the specification for the complete contract.

-download one-screen SVG ↓ +download SVG diagram ↓ read the specification
-

Context Layer / public working proposal

+

context layer / public working proposal

sierra catalina / 2026

diff --git a/site/context-layer/_pages/code.html b/site/context-layer/_pages/code.html index 260b67e..33cdcea 100644 --- a/site/context-layer/_pages/code.html +++ b/site/context-layer/_pages/code.html @@ -4,18 +4,18 @@ - + - - + + - + -Context Layer reference starter | sierra catalina +context layer reference starter | sierra catalina @@ -78,23 +78,23 @@

v0.2 reference implementation.

download

use the reviewed artifacts.

reference implementationcontext-layer-reference.mjs ↓ -context request schemacontext-request.schema.json ↓ -policy decision schemapolicy-decision.schema.json ↓ -scoped bundle schemascoped-context-bundle.schema.json ↓ -memory proposal schemamemory-update-proposal.schema.json ↓ -receipt schemareceipt.schema.json ↓ -valid exchange fixturevalid-exchange.json ↓ -valid decision fixturevalid-policy-decision.json ↓ -invalid decision fixtureinvalid-policy-decision.json ↓ -valid proposal fixturevalid-memory-update-proposal.json ↓ -invalid proposal fixtureinvalid-memory-update-proposal.json ↓ -invalid receipt fixtureinvalid-secret-receipt.json ↓ +context request schemacontext-request.schema.JSON ↓ +policy decision schemapolicy-decision.schema.JSON ↓ +scoped bundle schemascoped-context-bundle.schema.JSON ↓ +memory proposal schemamemory-update-proposal.schema.JSON ↓ +receipt schemareceipt.schema.JSON ↓ +valid exchange fixturevalid-exchange.JSON ↓ +valid decision fixturevalid-policy-decision.JSON ↓ +invalid decision fixtureinvalid-policy-decision.JSON ↓ +valid proposal fixturevalid-memory-update-proposal.JSON ↓ +invalid proposal fixtureinvalid-memory-update-proposal.JSON ↓ +invalid receipt fixtureinvalid-secret-receipt.JSON ↓
-

Context Layer / public working proposal

+

context layer / public working proposal

sierra catalina / 2026

diff --git a/site/context-layer/_pages/demo.html b/site/context-layer/_pages/demo.html index c6553d8..773be21 100644 --- a/site/context-layer/_pages/demo.html +++ b/site/context-layer/_pages/demo.html @@ -5,13 +5,13 @@ - + - - + + - Context Layer interactive demo | sierra catalina + context layer interactive demo | sierra catalina @@ -20,11 +20,11 @@ - + - +
@@ -46,30 +46,30 @@
-

Context Layer / working proposal

-

Useful context,
without total access.

-

A proposed protocol for letting apps and agents request only the context a task needs. Raw memory stays behind a user-controlled policy boundary. Every disclosure is scoped, expiring, and receipted.

+

context layer / working proposal

+

useful context,
without total access.

+

a proposed protocol for letting apps & agents request only the context a task needs. raw memory stays behind a user-controlled policy boundary. every disclosure is scoped, expiring & receipted.

- Run the demo - Open the map + run the demo + open the map
-

One request / progressively reduced

-

Watch context become a purpose-bound bundle.

+

one request / progressively reduced

+

watch context become a purpose-bound bundle.

    -
  1. 01Requesttask asks
    2. -
  2. 02Vaultcontext stays private
    3. -
  3. 03Policyfields reduce
    4. -
  4. 04Bundleminimum reveal
    5. -
  5. 05Surfaceresult appears
    6. -
  6. 06Receiptdecision records
    7. +
  7. 01requesttask asks
    8. +
  8. 02vaultcontext stays private
    9. +
  9. 03policyfields reduce
    10. +
  10. 04bundleminimum reveal
    11. +
  11. 05surfaceresult appears
    12. +
  12. 06receiptdecision records
- +
@@ -77,25 +77,25 @@

Useful context,
without total access.

-

Why this exists

-

More useful agents should not require more exposed lives.

+

why this exists

+

more useful agents should not require more exposed lives.

  1. 01 -

    Problem

    AI becomes more useful with context. Today, getting that context often means copying private memory into every platform that wants to use it.

    +

    problem

    AI becomes more useful with context. today, getting that context often means copying private memory into every platform that wants to use it.

  2. 02 -

    Protocol

    Context Layer keeps private memory behind a policy boundary. Apps request a purpose-bound bundle instead of receiving unrestricted access.

    +

    protocol

    context layer keeps private memory behind a policy boundary. apps request a purpose-bound bundle instead of receiving unrestricted access.

  3. 03 -

    Proof

    Every interaction should show what was used, who received it, why it was allowed, how long it lasts, and what receipt records the result.

    +

    proof

    every interaction should show what was used, who received it, why it was allowed, how long it lasts & what receipt records the result.

  4. 04 -

    Status

    This is a working proposal and synthetic demonstrator. It is not an adopted standard, production vault, or security certification.

    +

    status

    this is a working proposal & synthetic demonstrator. it is not an adopted standard, production vault, or security certification.

@@ -105,53 +105,53 @@

More useful agents should not require more exposed lives.

-

Synthetic protocol demo

-

Plan a day without sharing a life.

+

synthetic protocol demo

+

plan a day without sharing a life.

-

A fictional itinerary app plans a Saturday in Harbor City. The data is synthetic, stays in this browser, and resets locally.

+

a fictional itinerary app plans a Saturday in Harbor City. the data is synthetic, stays in this browser & resets locally.

- Scenario / Harbor City - Step 1 of 6 + scenario / Harbor City + step 1 of 6
- +
-
- - - - - - +
+ + + + + +
-

Context request

-

The app declares what it needs and why.

-

It requests enough context to plan a Saturday, not permission to browse an entire vault.

+

context request

+

the app declares what it needs & why.

+

it requests enough context to plan a Saturday, not permission to browse an entire vault.

- Requested -

Purpose: build a one-day itinerary. Retention: none.

+ requested +

purpose: build a one-day itinerary. retention: none.

- - + +
-
+
-
Input5 fields
+
input5 fields
    -
    Output5 fields
    +
    output5 fields
      @@ -159,17 +159,17 @@

      The app declares what it needs and why.

      - Disclosure - Request defines five fields + disclosure + request defines five fields
      -
      +
      100%
      - View protocol data + view protocol data
      @@ -180,28 +180,28 @@

      The app declares what it needs and why.

      -

      Progressive protocol map

      -

      Read one layer at a time.

      +

      progressive protocol map

      +

      read one layer at a time.

      -

      The complete architecture remains available as a reference, but this view limits each pass to one responsibility and its current-world equivalents.

      +

      each layer shows what enters, what stays private, how policy reduces scope & which evidence the exchange records.

      -
      - - - - - +
      + + + + +
      -

      Need the full system view? Open the technical diagram only after the layer model is clear.

      +

      need the full system view? see capture, policy, scoped disclosure, action & writeback in the complete architecture.

      @@ -210,32 +210,32 @@

      Read one layer at a time.

      -

      Protocol guide

      -

      Ask the site to explain or move.

      -

      Text is the default. The guide can answer from this proposal and navigate only to approved sections on this page. Without a configured API, it remains a transparent local guide.

      +

      protocol guide

      +

      ask the site to explain or move.

      +

      ask about policy, bundles, receipts or the demo. the guide explains the proposal & can jump to the relevant section.

      - Local guide - Ready + local guide + ready
      -
      - - - +
      + + +
      -

      Guide Ask a protocol question or tell me which part you want to see.

      +

      guide ask a protocol question or tell me which part you want to see.

      - - - + + +
      - - + +
      @@ -245,20 +245,20 @@

      Ask the site to explain or move.

      -

      Reference and status

      -

      A proposal you can inspect.

      +

      reference & status

      +

      a proposal you can inspect.

      -

      The demonstrator traces one request from capture through policy, scoped disclosure, and receipt. The linked documents describe the protocol objects, trust boundaries, and open implementation questions in more detail.

      +

      the demonstrator traces one request from capture through policy, scoped disclosure & receipt. the linked documents describe the protocol objects, trust boundaries & open implementation questions in more detail.

      - 01Draft technical specificationCore objects, lifecycles, policy, security - 02Implementation profilesAdapters, agents, web, mobile, interoperability - 03Plain-language introductionWhy the layer exists and who it can serve - 04Navigation manifestMachine-readable public sections and actions + 01draft technical specificationcore objects, lifecycles, policy, security + 02implementation profilesadapters, agents, web, mobile, interoperability + 03plain-language introductionwhy the layer exists & who it can serve + 04system architecturetrust zones, policy boundary & receipt lifecycle
      - Working proposal -

      This site demonstrates intended behavior with fictional data. It does not claim standards adoption, production security, live vault access, or completed interoperability.

      + working proposal +

      this site demonstrates intended behavior with fictional data. it does not claim standards adoption, production security, live vault access, or completed interoperability.

      @@ -266,7 +266,7 @@

      A proposal you can inspect.

      -

      Context Layer / public working proposal

      +

      context layer / public working proposal

      sierra catalina / 2026

      diff --git a/site/context-layer/_pages/essay.html b/site/context-layer/_pages/essay.html index b5de6b6..64344d4 100644 --- a/site/context-layer/_pages/essay.html +++ b/site/context-layer/_pages/essay.html @@ -4,14 +4,14 @@ - + - - + + - + @@ -40,7 +40,7 @@

      signal editorial / dossier 001

      the context layer: give AI the context it needs without giving it everything

      -

      a proposal for user-owned memory, purpose-bound disclosure, reversible agent writes, & receipts people can inspect

      +

      a proposal for user-owned memory, purpose-bound disclosure, reversible agent writes & receipts people can inspect

      published 2026.08.12 @@ -48,116 +48,116 @@

      the context layer: give AI the context it needs without giving it everything

      - -

      AI systems become more useful when they understand the person, project, history, & constraints around a task. today, the common way to provide that understanding is also the source of the problem: copy more private data into more applications, prompts, vendor databases, vector stores, & agent sessions.

      + +

      AI systems become more useful when they understand the person, project, history & constraints around a task. today, the common way to provide that understanding is also the source of the problem: copy more private data into more applications, prompts, vendor databases, vector stores & agent sessions.

      that trade is not sustainable. people should not have to choose between an assistant that knows nothing & an assistant that can read everything.

      -

      the context layer is a proposed application-layer protocol for a different model. a person keeps a user-owned context vault containing source events, derived claims, summaries, provenance, identity bindings, & policies. apps & agents do not receive an open-ended vault connection. they make a purpose-bound request. a policy boundary evaluates it. a semantic proxy releases the minimum useful context as a short-lived bundle. sensitive operations leave receipts. any new memory suggested by an agent returns as a proposal rather than silently becoming truth.

      +

      the context layer is a proposed application-layer protocol for a different model. a person keeps a user-owned context vault containing source events, derived claims, summaries, provenance, identity bindings & policies. apps & agents do not receive an open-ended vault connection. they make a purpose-bound request. a policy boundary evaluates it. a semantic proxy releases the minimum useful context as a short-lived bundle. sensitive operations leave receipts. any new memory suggested by an agent returns as a proposal rather than silently becoming truth.

      in one sentence:

      -

      the context layer lets useful context move while keeping authority, provenance, & disclosure boundaries attached.

      +

      the context layer lets useful context move while keeping authority, provenance & disclosure boundaries attached.

      this project is currently a proposal & interactive architecture demonstrator. it is not yet a production vault, deployed standard, completed security system, or claim that every named integration already exists.

      -

      the missing layer in today's AI stack#

      +

      the missing layer in today's AI stack#

      most modern AI stacks have several well-developed layers:

      • networks & transports move bytes.
      • application APIs expose data & actions.
      • agent protocols connect models to tools or other agents.
      • models interpret information & generate outputs.
      • user interfaces turn those outputs into workflows.

      what is often missing is a durable contract for the context between them.

      when context has no independent contract, every app invents its own memory model. a chat transcript becomes a profile. a profile becomes a retrieval index. a retrieval index becomes an implicit permission grant. an extracted guess becomes a durable fact. a helpful automation becomes an action whose inputs & authority are hard to reconstruct later.

      the result is a set of recurring failures:

      -
      problemcommon behavior todaycontext layer response
      context fragmentationthe same person or project is reconstructed separately in every appnormalize sources into a user-controlled context model with provenance
      coarse accessan integration receives an entire mailbox, drive, or memory storerequire a purpose, requested fields, recipient, retention window, & policy decision
      prompt overexposureraw notes are pasted into a model because extracting the relevant part is difficultuse a semantic proxy to redact, alias, compress, & route task-specific facts
      lost provenancea summary survives after its source & confidence are forgottenkeep source references & derivation metadata attached to claims
      stale or contradictory memorythe latest generated summary overwrites older nuanceversion summaries & preserve contradictory branches until they are resolved
      silent writebackan agent observation becomes memory without reviewtreat writeback as a proposal requiring validation & policy approval
      private discovery leakageexternal search or matching services inspect a full private profilerun matching behind an inbound discovery proxy & release only a minimum reveal
      invisible automationusers cannot tell which context caused an actionwrite reviewable receipts for policy decisions, model calls, tools, bundles, & external actions
      +
      problemcommon behavior todaycontext layer response
      context fragmentationthe same person or project is reconstructed separately in every appnormalize sources into a user-controlled context model with provenance
      coarse accessan integration receives an entire mailbox, drive, or memory storerequire a purpose, requested fields, recipient, retention window & policy decision
      prompt overexposureraw notes are pasted into a model because extracting the relevant part is difficultuse a semantic proxy to redact, alias, compress & route task-specific facts
      lost provenancea summary survives after its source & confidence are forgottenkeep source references & derivation metadata attached to claims
      stale or contradictory memorythe latest generated summary overwrites older nuanceversion summaries & preserve contradictory branches until they are resolved
      silent writebackan agent observation becomes memory without reviewtreat writeback as a proposal requiring validation & policy approval
      private discovery leakageexternal search or matching services inspect a full private profilerun matching behind an inbound discovery proxy & release only a minimum reveal
      invisible automationusers cannot tell which context caused an actionwrite reviewable receipts for policy decisions, model calls, tools, bundles & external actions

      the context layer does not solve these problems by building a bigger shared database. it solves them by making movement itself explicit.

      -

      a tour of the protocol#

      +

      a tour of the protocol#

      the architecture has seven stages. they form a continuous path, but each stage has a distinct responsibility.

      -

      1. capture source events#

      +

      1. capture source events#

      context begins as events: a message arrived, a file was imported, a browser page was clipped, a meeting ended, a payment completed, a voice note was recorded, or a device reported a signal.

      -

      capture does not immediately declare what an event means. it records what happened & where it came from. source tagging adds the app, account, device, URL, author, transport, timestamp, integrity data, confidence, & whether a user confirmed the source.

      +

      capture does not immediately declare what an event means. it records what happened & where it came from. source tagging adds the app, account, device, URL, author, transport, timestamp, integrity data, confidence & whether a user confirmed the source.

      this distinction matters. a source event is evidence. an interpretation is a claim derived from that evidence.

      -

      2. normalize & extract without erasing origin#

      -

      email, matrix events, ActivityPub activities, browser clips, files, & agent messages all have different shapes. normalization maps them into stable event records. deduplication can recognize that two channels carried the same underlying event while preserving both sightings as provenance.

      -

      extraction then derives entities, relationships, claims, time ranges, locations, commitments, embeddings, & possible contradictions. derived records keep links back to the source events that support them. confidence & validity are attributes, not afterthoughts.

      +

      2. normalize & extract without erasing origin#

      +

      email, Matrix events, ActivityPub activities, browser clips, files & agent messages all have different shapes. normalization maps them into stable event records. deduplication can recognize that two channels carried the same underlying event while preserving both sightings as provenance.

      +

      extraction then derives entities, relationships, claims, time ranges, locations, commitments, embeddings & possible contradictions. derived records keep links back to the source events that support them. confidence & validity are attributes, not afterthoughts.

      the goal is not to force the world's data into one universal ontology. the goal is to provide a small stable envelope that can carry typed domain data without losing evidence.

      -

      3. keep the vault as the authority boundary#

      +

      3. keep the vault as the authority boundary#

      the user-owned context vault is the private authority boundary. it may be local-first, self-hosted, organization-hosted, or provided as a managed service, but the ownership contract stays the same: consumers request context; they do not receive unrestricted raw-vault reads by default.

      the vault can contain:

      • raw source events & attachments
      • normalized records & extracted claims
      • a memory graph of entities & relationships
      • versioned summaries
      • contradictions & alternate branches
      • provenance & integrity records
      • identity & permission bindings
      • policy rules & consent state
      • scoped bundles & receipt references
      -

      "user-owned" therefore means more than where bytes are stored. it means the user, or an explicitly delegated authority, controls access, export, correction, deletion, key recovery, & policy.

      -

      4. turn access into a request & a decision#

      -

      an external agent should not ask, "can I see the memory?" it should submit an egress request that says:

      +

      'user-owned' therefore means more than where bytes are stored. it means the user, or an explicitly delegated authority, controls access, export, correction, deletion, key recovery & policy.

      +

      4. turn access into a request & a decision#

      +

      an external agent should not ask 'can I see the memory?' it should submit an egress request that says:

      • what task is being performed?
      • which context fields or claim types are needed?
      • who is requesting them?
      • which model, tool, agent, or organization will receive them?
      • what actions might follow?
      • how long may the context be retained?
      • does the request permit onward disclosure?
      • which receipt must be produced?
      -

      the policy boundary evaluates identity, scope, purpose, consent, expiration, requested action, sensitivity, & current user rules. its result can be allow, deny, allow with reduced scope, or require approval.

      -

      consent is not a checkbox that permanently legalizes every future use. in this model, consent is bound to a purpose, recipient, scope, & time window.

      -

      5. use proxies to reveal less#

      +

      the policy boundary evaluates identity, scope, purpose, consent, expiration, requested action, sensitivity & current user rules. its result can be allow, deny, allow with reduced scope, or require approval.

      +

      consent is not a checkbox that permanently legalizes every future use. in this model, consent is bound to a purpose, recipient, scope & time window.

      +

      5. use proxies to reveal less#

      the semantic proxy is the outbound gate. it can:

      • remove fields unrelated to the task
      • redact confidential values
      • replace identities with stable aliases or pseudonyms
      • compress many source records into a few task-level claims
      • route different fields to different recipients
      • preserve provenance handles without exposing raw source payloads
      -

      the discovery proxy performs the inverse pattern for inbound matching. an opportunity feed, public relay, recruiter, marketplace, or other external system can ask whether a private profile matches a condition. the query is authenticated, rate-limited, & evaluated inside the user's boundary. the response reveals the smallest useful next step, such as "available for a paid prototype engagement," rather than the underlying skills graph, private notes, or work history.

      -

      minimum reveal is not perfect privacy. repeated yes/no queries can still leak information. that is why discovery needs identity checks, query budgets, correlation defenses, receipts, & escalation to user approval.

      -

      6. deliver a scoped context bundle#

      +

      the discovery proxy performs the inverse pattern for inbound matching. an opportunity feed, public relay, recruiter, marketplace, or other external system can ask whether a private profile matches a condition. the query is authenticated, rate-limited & evaluated inside the user's boundary. the response reveals the smallest useful next step, such as 'available for a paid prototype engagement,' rather than the underlying skills graph, private notes, or work history.

      +

      minimum reveal is not perfect privacy. repeated yes/no queries can still leak information. that is why discovery needs identity checks, query budgets, correlation defenses, receipts & escalation to user approval.

      +

      6. deliver a scoped context bundle#

      the output is a scoped context bundle: a task-ready, short-lived packet containing only the approved material.

      a bundle can carry:

      • approved facts & summaries
      • provenance references
      • purpose & task definition
      • instructions & behavioral constraints
      • allowed tools & actions
      • explicitly denied actions
      • expiration & retention rules
      • surface hints for cards, tables, maps, timelines, or workspaces
      • a receipt contract
      -

      for an agent, this is the difference between "here is my entire memory" & "draft this reply using the deadline & stakeholder, do not send it, do not mention the confidential budget note, & expire the context after 24 hours."

      +

      for an agent, this is the difference between 'here is my entire memory' & 'draft this reply using the deadline & stakeholder, do not send it, do not mention the confidential budget note & expire the context after 24 hours.'

      the bundle is where policy becomes executable context.

      -

      7. make actions & writeback reviewable#

      +

      7. make actions & writeback reviewable#

      approved bundles can be consumed by a local agent, cloud model, workflow runner, voice interface, search surface, browser overlay, or self-assembling UI. the consuming surface should show enough policy & provenance state for a person to understand why information is present & what actions are available.

      -

      sensitive operations write receipts. a receipt records who or what acted, which policy decision authorized it, which bundle was used, what kind of operation occurred, when it happened, & whether it succeeded. input & output digests can support later integrity checks without storing sensitive payloads in the receipt itself.

      -

      receipts are evidence, not magic. a signed record can prove that a component reported an action; it cannot prove that the action was wise, that the source was true, or that no undisclosed side effect occurred. useful receipt systems still need trustworthy implementations, readable summaries, retention policy, & audit tooling.

      -

      finally, an agent's new observation returns as a proposed memory update. the system can check its sources, compare it with existing claims, score contradictions, & request user approval. only then can it become durable context.

      -

      a concrete example#

      +

      sensitive operations write receipts. a receipt records who or what acted, which policy decision authorized it, which bundle was used, what kind of operation occurred, when it happened & whether it succeeded. input & output digests can support later integrity checks without storing sensitive payloads in the receipt itself.

      +

      receipts are evidence, not magic. a signed record can prove that a component reported an action; it cannot prove that the action was wise, that the source was true, or that no undisclosed side effect occurred. useful receipt systems still need trustworthy implementations, readable summaries, retention policy & audit tooling.

      +

      finally, an agent's new observation returns as a proposed memory update. the system can check its sources, compare it with existing claims, score contradictions & request user approval. only then can it become durable context.

      +

      a concrete example#

      imagine that an email says:

      -

      can you send the launch timeline by friday? do not disclose the budget delta yet.

      +

      can you send the launch timeline by Friday? do not disclose the budget delta yet.

      the context layer flow could look like this:

      -
      1. capture: record the email as a private source event with sender, account, timestamp, & message identity.
      2. extract: derive two claims: a timeline is requested by friday, & a budget detail is restricted.
      3. request: an email-drafting agent asks for the context needed to draft a reply.
      4. policy: permit the deadline & stakeholder; deny the confidential budget note; allow drafting but not sending; set a 24-hour expiry.
      5. proxy: produce a concise task summary & retain opaque provenance handles.
      6. bundle: deliver the approved facts, email_draft tool permission, "do not send" instruction, expiry, & receipt requirement.
      7. interface: show a draft with preview, edit, & approve controls.
      8. receipt: record bundle creation, model use, & draft generation.
      9. writeback: if the agent suspects the deadline moved to thursday, store that as a proposal requiring a source or user confirmation, not as an automatic correction.
      +
      1. capture: record the email as a private source event with sender, account, timestamp & message identity.
      2. extract: derive two claims: a timeline is requested by Friday & a budget detail is restricted.
      3. request: an email-drafting agent asks for the context needed to draft a reply.
      4. policy: permit the deadline & stakeholder; deny the confidential budget note; allow drafting but not sending; set a 24-hour expiry.
      5. proxy: produce a concise task summary & retain opaque provenance handles.
      6. bundle: deliver the approved facts, email_draft tool permission 'do not send' instruction, expiry & receipt requirement.
      7. interface: show a draft with preview, edit & approve controls.
      8. receipt: record bundle creation, model use & draft generation.
      9. writeback: if the agent suspects the deadline moved to Thursday, store that as a proposal requiring a source or user confirmation, not as an automatic correction.

      the assistant remains useful. the budget note never needed to leave the vault. the user can see what happened.

      -

      who this is for#

      -

      people using several AI products#

      -

      individuals should not have to rebuild their preferences, projects, relationships, & history inside every assistant. a portable context layer can let them switch models or interfaces while retaining control over the source material & disclosure rules.

      -

      agent & application developers#

      -

      developers need a predictable input contract. scoped bundles give agents structured facts, instructions, tool limits, & expiry instead of a pile of unbounded retrieved text. receipts & proposed writebacks also make evaluation & debugging more concrete.

      -

      product teams building AI-enabled workflows#

      -

      teams can use the layer to separate context governance from each product surface. a search view, dashboard, voice interface, & automation can consume the same approved bundle while presenting different interfaces.

      -

      organizations with audit or privacy obligations#

      -

      purpose binding, provenance, short-lived access, user approval, & receipts map well to environments where data use must be explainable. the context layer is not itself a compliance certification, but it creates better places to enforce & test organizational controls.

      -

      open-protocol & decentralized-web communities#

      -

      open social, messaging, storage, & agent protocols move information across independent systems. context layer adapters can add a user-owned decision boundary before those systems receive private context, without replacing their native transport or data models.

      -

      marketplaces & discovery systems#

      +

      who this is for#

      +

      people using several AI products#

      +

      individuals should not have to rebuild their preferences, projects, relationships & history inside every assistant. a portable context layer can let them switch models or interfaces while retaining control over the source material & disclosure rules.

      +

      agent & application developers#

      +

      developers need a predictable input contract. scoped bundles give agents structured facts, instructions, tool limits & expiry instead of a pile of unbounded retrieved text. receipts & proposed writebacks also make evaluation & debugging more concrete.

      +

      product teams building AI-enabled workflows#

      +

      teams can use the layer to separate context governance from each product surface. a search view, dashboard, voice interface & automation can consume the same approved bundle while presenting different interfaces.

      +

      organizations with audit or privacy obligations#

      +

      purpose binding, provenance, short-lived access, user approval & receipts map well to environments where data use must be explainable. the context layer creates better places to enforce & test organizational controls without serving as a compliance certification.

      +

      open-protocol & decentralized-web communities#

      +

      open social, messaging, storage & agent protocols move information across independent systems. context layer adapters can add a user-owned decision boundary before those systems receive private context, without replacing their native transport or data models.

      +

      marketplaces & discovery systems#

      private matching can support opportunities, collaborators, services, or communities without publishing a complete personal graph. the discovery profile is aimed at exactly this class of use case.

      -

      what it can work with#

      +

      what it can work with#

      the context layer is designed to sit above existing protocols, not compete with them.

      -

      web & messaging sources#

      -

      HTTP APIs, email, files, browser events, audio, device signals, matrix rooms, ActivityPub activities, AT protocol records, nostr events, & application-specific webhooks can all be represented through capture adapters. the adapter's responsibility is to preserve source identity, timing, integrity information, & native semantics.

      -

      ActivityPub, for example, defines client-to-server & federated server-to-server social interactions over ActivityStreams. AT protocol has its own self-authenticating identity, repositories, & lexicon schemas. nostr uses signed events distributed through relays. matrix defines JSON-over-HTTP APIs & federated room state. context layer should map these systems into source & provenance records; it should not flatten away their security or consistency models.

      -

      agent protocols#

      -

      model context protocol (MCP) standardizes how AI hosts connect to resources, prompts, & tools. context layer can expose an approved bundle as an MCP resource or require a context layer request before a sensitive MCP tool executes. MCP remains the tool & resource protocol; context layer supplies the user-owned context policy around it.

      -

      agent2agent (A2A) standardizes collaboration between independent agents. a context layer bundle can be carried as structured task data or an artifact, with recipient & retention constraints bound to the remote agent. A2A remains the agent communication protocol; context layer defines which private context the task may receive.

      -

      storage & content addressing#

      -

      local databases, encrypted object stores, & content-addressed systems can hold vault or receipt data. IPFS can provide verifiable content identifiers & portable references, but public IPFS is not private storage: unencrypted content & provider metadata can be exposed. raw private vault material should not be published to a public content-addressed network merely because its address is a hash.

      -

      models, agents, & voice systems#

      -

      local models, cloud models, codex-style coding agents, goose-style local agents, workflow engines, & custom runtimes can consume scoped bundles. the current public proof includes one capability-bound local-agent consumer. realtime voice remains an informative future profile, not a conforming implementation.

      -

      payment & metering#

      +

      web & messaging sources#

      +

      HTTP APIs, email, files, browser events, audio, device signals, Matrix rooms, ActivityPub activities, AT protocol records, Nostr events & application-specific webhooks can all be represented through capture adapters. the adapter's responsibility is to preserve source identity, timing, integrity information & native semantics.

      +

      ActivityPub, for example, defines client-to-server & federated server-to-server social interactions over ActivityStreams. AT protocol has its own self-authenticating identity, repositories & lexicon schemas. Nostr uses signed events distributed through relays. Matrix defines JSON-over-HTTP APIs & federated room state. context layer should map these systems into source & provenance records; it should not flatten away their security or consistency models.

      +

      agent protocols#

      +

      model context protocol [MCP] standardizes how AI hosts connect to resources, prompts & tools. context layer can expose an approved bundle as an MCP resource or require a context layer request before a sensitive MCP tool executes. MCP remains the tool & resource protocol; context layer supplies the user-owned context policy around it.

      +

      Agent2Agent [A2A] standardizes collaboration between independent agents. a context layer bundle can be carried as structured task data or an artifact, with recipient & retention constraints bound to the remote agent. A2A remains the agent communication protocol; context layer defines which private context the task may receive.

      +

      storage & content addressing#

      +

      local databases, encrypted object stores & content-addressed systems can hold vault or receipt data. IPFS can provide verifiable content identifiers & portable references, but public IPFS is not private storage: unencrypted content & provider metadata can be exposed. raw private vault material should not be published to a public content-addressed network merely because its address is a hash.

      +

      models, agents & voice systems#

      +

      local models, cloud models, Codex-style coding agents, Goose-style local agents, workflow engines & custom runtimes can consume scoped bundles. the current public proof includes one capability-bound local-agent consumer. realtime voice remains an informative future profile, not a conforming implementation.

      +

      payment & metering#

      payment protocols such as x402 can be used by an application to require payment for a service or agent action. a context layer request could carry a payment requirement or receipt reference, but payment authorization is separate from permission to disclose private context. paying for an operation must never imply blanket access to the vault.

      -

      "works with" in this proposal means there is a coherent adapter mapping. it does not mean the current static demonstrator ships production adapters for every system listed above.

      -

      what the context layer is not#

      +

      'works with' in this proposal means there is a coherent adapter mapping. it does not mean the current static demonstrator ships production adapters for every system listed above.

      +

      what the context layer is not#

      clear boundaries are more useful than ambitious labels. the context layer is not:

      -
      • a replacement for HTTP, TLS, matrix, ActivityPub, AT protocol, nostr, MCP, A2A, or IPFS
      • a universal identity provider or a new authentication standard
      • a particular graph database, vector database, model, or cloud vendor
      • a promise that semantic redaction is infallible
      • a way to bypass the source system's terms, permissions, or access controls
      • a guarantee that a signed receipt describes a correct or safe action
      • a license for autonomous agents to write permanent memory
      • a production implementation in its current repository form
      -

      it is a contract for context objects, decisions, bundles, & evidence at the boundary between private memory & external computation.

      -

      design principles#

      +
      • a replacement for HTTP, TLS, Matrix, ActivityPub, AT protocol, Nostr, MCP, A2A, or IPFS
      • a universal identity provider or a new authentication standard
      • a particular graph database, vector database, model, or cloud vendor
      • a promise that semantic redaction is infallible
      • a way to bypass the source system's terms, permissions, or access controls
      • a guarantee that a signed receipt describes a correct or safe action
      • a license for autonomous agents to write permanent memory
      • a production implementation in its current repository form
      +

      it is a contract for context objects, decisions, bundles & evidence at the boundary between private memory & external computation.

      +

      design principles#

      the proposal can be judged by a small set of principles:

      -
      1. useful without total access. a task should receive enough context to succeed without receiving unrelated private material.
      2. provenance survives transformation. summaries & claims remain traceable to evidence, even after compression.
      3. purpose is part of authorization. who, what, why, how long, & which action are evaluated together.
      4. disclosure is reducible. policy can narrow a request rather than only allow or deny everything.
      5. discovery reveals the minimum. matching happens inside the private boundary whenever possible.
      6. writes are proposals first. generated observations do not silently become durable truth.
      7. sensitive operations leave evidence. receipts are portable, readable, & append-only at the logical level.
      8. interfaces show authority state. users can see provenance, permissions, expiry, & pending approvals where decisions happen.
      9. protocols compose. context layer adapters preserve the native semantics & security model of the system they connect.
      10. failure closes the gate. missing identity, ambiguous purpose, expired policy, invalid signatures, & unavailable receipt storage do not produce broader access.
      -

      what exists today#

      +
      1. useful without total access. a task should receive enough context to succeed without receiving unrelated private material.
      2. provenance survives transformation. summaries & claims remain traceable to evidence, even after compression.
      3. purpose is part of authorization. who, what, why, how long & which action are evaluated together.
      4. disclosure is reducible. policy can narrow a request rather than only allow or deny everything.
      5. discovery reveals the minimum. matching happens inside the private boundary whenever possible.
      6. writes are proposals first. generated observations do not silently become durable truth.
      7. sensitive operations leave evidence. receipts are portable, readable & append-only at the logical level.
      8. interfaces show authority state. users can see provenance, permissions, expiry & pending approvals where decisions happen.
      9. protocols compose. context layer adapters preserve the native semantics & security model of the system they connect.
      10. failure closes the gate. missing identity, ambiguous purpose, expired policy, invalid signatures & unavailable receipt storage do not produce broader access.
      +

      what exists today#

      the current project contains:

      -
      • a plain-language overview of the problem & proposed layer
      • a reviewed v0.2 technical specification & implementation profiles
      • a complete protocol architecture map
      • five v0.2 core schemas & a dependency-free reference runtime
      • an experimental encrypted local core with four policy states, authenticated bundle envelopes, & anchored receipts
      • one narrow UTF-8 files adapter, one local-agent consumer, a minimized demo, & executable test vectors
      • an unsubmitted nostr interoperability discussion draft
      +
      • a plain-language overview of the problem & proposed layer
      • a reviewed v0.2 technical specification & implementation profiles
      • a complete protocol architecture map
      • five v0.2 core schemas & a dependency-free reference runtime
      • an experimental encrypted local core with four policy states, authenticated bundle envelopes & anchored receipts
      • one narrow UTF-8 files adapter, one local-agent consumer, a minimized demo & executable test vectors
      • an unsubmitted Nostr interoperability discussion draft

      these artifacts make the current contract & tested single-user profile reviewable as one flow. they do not prove production security, third-party interoperability, managed key custody, hostile-administrator resistance, or independent conformance.

      -

      the next implementation milestone should harden this narrow profile rather than widen the architecture map: stabilize the v0.2 contracts, move key & rollback-anchor custody onto deployment-defined protected boundaries, connect an authenticated real-world source & consumer, & run an independent security review.

      -

      the practical test#

      +

      the next implementation milestone should harden this narrow profile rather than widen the architecture map: stabilize the v0.2 contracts, move key & rollback-anchor custody onto deployment-defined protected boundaries, connect an authenticated real-world source & consumer & run an independent security review.

      +

      the practical test#

      every context-driven interaction should be able to answer three questions:

      -
      1. what context is involved?
      2. who gets to use it, for what purpose, & for how long?
      3. what receipt proves the decision & resulting operation?
      +
      1. what context is involved?
      2. who gets to use it, for what purpose & for how long?
      3. what receipt proves the decision & resulting operation?

      if an AI product cannot answer those questions, it does not yet have a context architecture. it has data access.

      the context layer is an attempt to make the better architecture portable.

      -

      further reading#

      -
      +

      further reading#

      +
      -source markdown ↓ +source Markdown ↓ implementation starter →
      diff --git a/site/context-layer/_pages/implementation.html b/site/context-layer/_pages/implementation.html index 737fbc3..dbed41b 100644 --- a/site/context-layer/_pages/implementation.html +++ b/site/context-layer/_pages/implementation.html @@ -4,18 +4,18 @@ - + - - + + - + -Context Layer Implementation and Interoperability Profiles | sierra catalina +context layer implementation & interoperability profiles | sierra catalina @@ -39,8 +39,8 @@

      technical reference / implementation

      -

      Context Layer Implementation and Interoperability Profiles

      -

      Adapter guidance for building on existing protocols without flattening their security model.

      +

      context layer implementation & interoperability profiles

      +

      adapter guidance for building on existing protocols without flattening their security model.

      working draft 2026.08 @@ -48,16 +48,16 @@

      Context Layer Implementation and Interoperability Profiles

      - -
      FieldValue
      StatusWorking Draft - informative companion to the technical specification
      Date2026-08-12
      Applies tocontext-layer/0.2-draft
      Primary audienceApplication architects, adapter authors, agent developers, mobile and web teams, security reviewers
      -

      1. Purpose#

      -

      This document explains how to implement the Context Layer draft with existing sources, transports, agent protocols, models, storage systems, and user interfaces.

      -

      It uses adapter compatibility as a precise term:

      -

      A system is adapter-compatible when its native objects and security metadata can be mapped to Context Layer objects without violating the core invariants.

      -

      Adapter compatibility does not imply that an adapter exists in this repository, that two vendors have tested interoperability, or that the Context Layer is part of the external protocol's official specification.

      -

      The current repository contains the draft specification, five schemas, a dependency-free reference runtime, and an experimental single-user local core with synthetic data. The profiles below define broader implementation targets; website publication and deployment source are maintained separately.

      -

      2. Where the Context Layer fits#

      -

      The Context Layer should be implemented as a control and representation layer above existing protocols:

      + +
      fieldvalue
      statusworking draft - informative companion to the technical specification
      date2026-08-12
      applies tocontext-layer/0.2-draft
      primary audienceapplication architects, adapter authors, agent developers, mobile & web teams, security reviewers
      +

      1. purpose#

      +

      this document explains how to implement the context layer draft with existing sources, transports, agent protocols, models, storage systems & user interfaces.

      +

      it uses adapter compatibility as a precise term:

      +

      a system is adapter-compatible when its native objects & security metadata can be mapped to context layer objects without violating the core invariants.

      +

      adapter compatibility does not imply that an adapter exists in this repository, that two vendors have tested interoperability, or that the context layer is part of the external protocol's official specification.

      +

      the current repository contains the draft specification, five schemas, a dependency-free reference runtime & an experimental single-user local core with synthetic data. broader adapter, platform & interoperability profiles remain implementation targets.

      +

      2. where the context layer fits#

      +

      the context layer should be implemented as a control & representation layer above existing protocols:

      sources and networks
   HTTP | email | files | ActivityPub | AT Protocol | Nostr | Matrix | devices
         |
@@ -72,31 +72,31 @@ 
      2. Where the Context Layer fits
      -

      Existing protocols remain authoritative for transport, native identity, signatures, federation, and domain behavior. The Context Layer adds a user-owned decision about what private context may cross into those systems.

      -

      3. Deployment profiles#

      -

      3.1 Personal local-first profile#

      -

      Audience: an individual using local agents and selected cloud services.

      -

      Topology:

      -
      • Vault, policy engine, semantic proxy, and receipt store run on a trusted personal device or private home service.
      • Source adapters ingest selected local files, browser events, mail, calendars, or messages.
      • Local agents connect through process-local IPC or authenticated loopback endpoints.
      • Cloud model requests receive short-lived scoped bundles.
      • Writeback requires approval by default.
      -

      Required controls:

      -
      • Operating-system credential storage
      • Encrypted vault at rest
      • Loopback-only local HTTP by default
      • Per-client or per-launch authorization
      • Explicit source onboarding
      • Clear bundle and writeback approval surfaces
      • Backup and recovery separate from application caches
      -

      This is the recommended first implementation profile because it keeps the trust boundary small and testable.

      -

      3.2 Organization or team profile#

      -

      Audience: a company or team that needs shared project context with individual and organizational boundaries.

      -

      Topology:

      -
      • Separate personal, team, and organization-owned subjects and vault partitions
      • Central identity and authorization with purpose-aware policy
      • Shared receipt service with independent access policy
      • Remote agents and tools connected through authenticated gateways
      • Administrative policy layered beneath, not silently replacing, user or data-owner consent where required
      -

      Additional requirements:

      -
      • Tenant isolation
      • Delegation and revocation
      • Service identities and workload authentication
      • Data-region and retention policy
      • Administrative and user-visible receipts
      • Export, legal hold, deletion, and incident response procedures
      • Policy simulation before deployment
      -

      3.3 Federated discovery profile#

      -

      Audience: marketplaces, social discovery, opportunity matching, community recommendations, or cross-organization agent discovery.

      -

      Topology:

      -
      • External systems submit narrow discovery requests.
      • A discovery proxy evaluates requests inside the subject's private boundary.
      • Results use minimum reveal and expiring contact routes.
      • Higher-detail exchange requires a second policy decision and often user approval.
      -

      Additional requirements:

      -
      • Strong requester identity or explicit anonymous classification
      • Semantic query budgets and coordinated-probe detection
      • Response uniformity where negative results could leak private attributes
      • Abuse reporting and requester revocation
      • Receipts for queries and reveals
      • A clear distinction between public profile data and private match features
      -

      4. Compatibility matrix#

      -
      System or categoryContext Layer roleMappingCurrent repository statePrimary caveat
      HTTP + TLSNetwork bindingCarry requests, bundles, receipts, and adapter traffic over authenticated HTTPSLinked as official references; no complete Context Layer APIHTTP transports data but does not supply purpose policy
      EmailSource adapter and action targetMessage becomes source_event; draft/send are separate capabilitiesSynthetic email flow onlyMailbox access is broader than permission to disclose every message
      Files and browser clipsSource adaptersFile metadata and content references become source eventsNarrow local UTF-8 files adapter with synthetic fixturesPreserve origin, MIME type, path privacy, and integrity
      Audio and voice notesSource adapterMedia reference plus transcript and confidenceSynthetic examples onlyTranscript is derived data and must retain media provenance
      ActivityPubSocial source and outbound adapterActivityStreams object and delivery metadata map to source/provenance; outbound posts require action policyReference link onlyFederated content is untrusted input and HTML must be sanitized
      AT ProtocolSocial source and outbound adapterDID, repo record, CID, Lexicon type, and verification map to source/provenanceReference link onlyPublic repositories are not a private vault
      NostrSigned-event source and discovery channelEvent ID, pubkey, kind, tags, signature, and relay sightings map to source/provenanceReference links plus an unsubmitted interoperability discussion draftRelay visibility and key custody require separate policy
      MatrixMessaging source and action adapterEvent ID, room, sender, origin timestamp, state relation, and auth context map to source/provenanceReference link onlyRoom history and encryption state must not be flattened away
      IPFSContent-addressed reference and artifact transportCID may identify encrypted/public bundle artifacts or receipt batchesReference link onlyPublic IPFS does not make unencrypted content private
      MCPAgent-to-tool/resource bridgeApproved bundles exposed as resources; context requests and actions exposed as toolsOne local-agent consumer; no production MCP serverMCP authorization does not replace Context Layer purpose policy
      A2AAgent-to-agent task transportBundle carried as structured task data or artifact; remote agent bound as recipientReference link onlyRemote agent retention and onward disclosure must be explicit
      Local/cloud modelsContext consumersPrompt or model input assembled only from a scoped bundleIllustrative runtime referencesProvider retention and logging remain part of recipient policy
      OpenAI RealtimeVoice or multimodal consumerWebRTC session receives scoped instructions and context through a backendInformative profile only; no conforming implementationStandard API keys must remain server-side and a demo is not hardened production infrastructure
      Web UIApproval and consumption surfaceShow bundle provenance, permissions, expiry, actions, and receiptsInformative profile only; publication UI maintained separatelyStatic pages do not enforce policy
      iOS/mobileApproval and consumption surfaceNative app consumes bundles and short-lived sessions; credentials use platform storageNot implementedNever embed provider API keys in an app binary
      x402Optional payment conditionRequest or action can reference a payment requirement and payment receiptReference link onlyPayment does not grant context permission
      -

      5. Generic adapter contract#

      -

      Every adapter should have an adapter manifest:

      +

      existing protocols remain authoritative for transport, native identity, signatures, federation & domain behavior. the context layer adds a user-owned decision about what private context may cross into those systems.

      +

      3. deployment profiles#

      +

      3.1 personal local-first profile#

      +

      audience: an individual using local agents & selected cloud services.

      +

      topology:

      +
      • vault, policy engine, semantic proxy & receipt store run on a trusted personal device or private home service.
      • source adapters ingest selected local files, browser events, mail, calendars, or messages.
      • local agents connect through process-local IPC or authenticated loopback endpoints.
      • cloud model requests receive short-lived scoped bundles.
      • writeback requires approval by default.
      +

      required controls:

      +
      • operating-system credential storage
      • encrypted vault at rest
      • loopback-only local HTTP by default
      • per-client or per-launch authorization
      • explicit source onboarding
      • clear bundle & writeback approval surfaces
      • backup & recovery separate from application caches
      +

      this is the recommended first implementation profile because it keeps the trust boundary small & testable.

      +

      3.2 organization or team profile#

      +

      audience: a company or team that needs shared project context with individual & organizational boundaries.

      +

      topology:

      +
      • separate personal, team & organization-owned subjects & vault partitions
      • central identity & authorization with purpose-aware policy
      • shared receipt service with independent access policy
      • remote agents & tools connected through authenticated gateways
      • administrative policy layered beneath, not silently replacing, user or data-owner consent where required
      +

      additional requirements:

      +
      • tenant isolation
      • delegation & revocation
      • service identities & workload authentication
      • data-region & retention policy
      • administrative & user-visible receipts
      • export, legal hold, deletion & incident response procedures
      • policy simulation before deployment
      +

      3.3 federated discovery profile#

      +

      audience: marketplaces, social discovery, opportunity matching, community recommendations, or cross-organization agent discovery.

      +

      topology:

      +
      • external systems submit narrow discovery requests.
      • a discovery proxy evaluates requests inside the subject's private boundary.
      • results use minimum reveal & expiring contact routes.
      • higher-detail exchange requires a second policy decision & often user approval.
      +

      additional requirements:

      +
      • strong requester identity or explicit anonymous classification
      • semantic query budgets & coordinated-probe detection
      • response uniformity where negative results could leak private attributes
      • abuse reporting & requester revocation
      • receipts for queries & reveals
      • a clear distinction between public profile data & private match features
      +

      4. compatibility matrix#

      +
      system or categorycontext layer rolemappingcurrent repository stateprimary caveat
      HTTP + TLSnetwork bindingcarry requests, bundles, receipts & adapter traffic over authenticated HTTPSlinked as official references; no complete context layer APIHTTP transports data but does not supply purpose policy
      emailsource adapter & action targetmessage becomes source_event; draft/send are separate capabilitiessynthetic email flow onlymailbox access is broader than permission to disclose every message
      files & browser clipssource adaptersfile metadata & content references become source eventsnarrow local UTF-8 files adapter with synthetic fixturespreserve origin, MIME type, path privacy & integrity
      audio & voice notessource adaptermedia reference plus transcript & confidencesynthetic examples onlytranscript is derived data & must retain media provenance
      ActivityPubsocial source & outbound adapterActivityStreams object & delivery metadata map to source/provenance; outbound posts require action policyreference link onlyfederated content is untrusted input & HTML must be sanitized
      AT protocolsocial source & outbound adapterDID, repo record, CID, lexicon type & verification map to source/provenancereference link onlypublic repositories are not a private vault
      Nostrsigned-event source & discovery channelevent ID, pubkey, kind, tags, signature & relay sightings map to source/provenancereference links plus an unsubmitted interoperability discussion draftrelay visibility & key custody require separate policy
      Matrixmessaging source & action adapterevent ID, room, sender, origin timestamp, state relation & auth context map to source/provenancereference link onlyroom history & encryption state must not be flattened away
      IPFScontent-addressed reference & artifact transportCID may identify encrypted/public bundle artifacts or receipt batchesreference link onlypublic IPFS does not make unencrypted content private
      MCPagent-to-tool/resource bridgeapproved bundles exposed as resources; context requests & actions exposed as toolsone local-agent consumer; no production MCP serverMCP authorization does not replace context layer purpose policy
      A2Aagent-to-agent task transportbundle carried as structured task data or artifact; remote agent bound as recipientreference link onlyremote agent retention & onward disclosure must be explicit
      local/cloud modelscontext consumersprompt or model input assembled only from a scoped bundleillustrative runtime referencesprovider retention & logging remain part of recipient policy
      OpenAI realtimevoice or multimodal consumerWebRTC session receives scoped instructions & context through a backendinformative profile only; no conforming implementationstandard API keys must remain server-side & a demo is not hardened production infrastructure
      web UIapproval & consumption surfaceshow bundle provenance, permissions, expiry, actions & receiptsstatic demonstrator onlystatic pages do not enforce policy
      iOS/mobileapproval & consumption surfacenative app consumes bundles & short-lived sessions; credentials use platform storagenot implementednever embed provider API keys in an app binary
      x402optional payment conditionrequest or action can reference a payment requirement & payment receiptreference link onlypayment does not grant context permission
      +

      5. generic adapter contract#

      +

      every adapter should have an adapter manifest:

      {
   "adapter_id": "com.example.context-layer.matrix",
   "adapter_version": "0.1.0",
@@ -116,89 +116,89 @@ 
      5. Generic adapter contract5.1 Capture requirements#
      
-
      An inbound adapter MUST:
      
-
      1. Verify native signatures or authentication when the native protocol supports them.
      2. Record verification outcome separately from source content.
      3. Preserve a native identifier or its collision-resistant digest.
      4. Preserve source, capture, edit, and deletion times.
      5. Preserve visibility and audience semantics.
      6. Classify external content as untrusted data.
      7. Store raw payload inside the vault or an approved encrypted object store.
      8. Emit a source event referencing that payload.
      9. Document fields lost during normalization.
      10. Avoid triggering outbound actions during capture.
      
-
      5.2 Action requirements#
      
-
      An outbound adapter MUST:
      
-
      1. Receive a valid scoped bundle addressed to its runtime.
      2. Enforce the exact allowed action.
      3. Obtain step-up approval for side effects when required.
      4. Avoid substituting broader native credentials for narrower bundle permissions.
      5. Record the native transaction identifier and outcome.
      6. Write the required receipt before reporting final success.
      7. Return any new observations as proposals, not direct vault mutations.
      
-
      5.3 Edit and deletion behavior#
      
-
      Adapters MUST document whether the native system supports edits, redactions, deletions, tombstones, or immutable events. A normalized event MUST NOT be silently rewritten when a native record changes. The adapter SHOULD append a new event or version that references the prior record.
      
-
      6. Source profiles#
      
-
      6.1 HTTP APIs and webhooks#
      
+
      5.1 capture requirements#
      
+
      an inbound adapter MUST:
      
+
      1. verify native signatures or authentication when the native protocol supports them.
      2. record verification outcome separately from source content.
      3. preserve a native identifier or its collision-resistant digest.
      4. preserve source, capture, edit & deletion times.
      5. preserve visibility & audience semantics.
      6. classify external content as untrusted data.
      7. store raw payload inside the vault or an approved encrypted object store.
      8. emit a source event referencing that payload.
      9. document fields lost during normalization.
      10. avoid triggering outbound actions during capture.
      
+
      5.2 action requirements#
      
+
      an outbound adapter MUST:
      
+
      1. receive a valid scoped bundle addressed to its runtime.
      2. enforce the exact allowed action.
      3. obtain step-up approval for side effects when required.
      4. avoid substituting broader native credentials for narrower bundle permissions.
      5. record the native transaction identifier & outcome.
      6. write the required receipt before reporting final success.
      7. return any new observations as proposals, not direct vault mutations.
      
+
      5.3 edit & deletion behavior#
      
+
      adapters MUST document whether the native system supports edits, redactions, deletions, tombstones, or immutable events. a normalized event MUST NOT be silently rewritten when a native record changes. the adapter SHOULD append a new event or version that references the prior record.
      
+
      6. source profiles#
      
+
      6.1 HTTP APIs & webhooks#
      
 
      HTTP is the default transport for many adapters.
      
-
      Recommended mapping:
      
-
      • Target URI and method -> source operation metadata
      • Authenticated principal -> source actor
      • Provider event ID or idempotency key -> native identifier
      • Date and provider timestamps -> source time fields
      • ETag, digest, or signature -> integrity metadata
      • Content type -> payload media type
      • Response status -> capture or action outcome
      
-
      Webhook endpoints MUST validate provider signatures where available, enforce content limits, reject replay, and rate-limit before parsing expensive content. Server-side request forgery defenses are required when captured payloads contain fetchable URLs.
      
-
      6.2 Email#
      
-
      Email capture should preserve:
      
-
      • Message-ID and thread references
      • Envelope sender and recipient separately from display headers
      • Original date and received-chain metadata
      • MIME structure and attachments
      • Authentication results when available
      • Account and folder source
      • User-applied labels
      
-
      An agent capability such as email.create_draft is distinct from email.send. A bundle granting draft creation MUST NOT authorize send, forward, mailbox search, or attachment access unless listed separately.
      
-
      6.3 Files and local workspace data#
      
-
      File adapters should preserve:
      
-
      • Stable file identity where the platform provides one
      • Original path as a vault-private field
      • File name, media type, size, modification time, and digest
      • Source repository or workspace
      • Version-control commit when applicable
      • Access-control context
      
-
      Bundles should expose an opaque file handle, excerpt, derived claim, or approved copy rather than an unrestricted local path. A consumer must not use path traversal or symlink resolution to escape the granted workspace.
      
-
      6.4 Audio and transcripts#
      
-
      Audio should be modeled as a media source event. A transcript is a derived artifact with:
      
-
      • Model or service identifier
      • Language
      • Timing segments when available
      • Confidence
      • Speaker-attribution status
      • Link to the source media
      • Redaction state
      
-
      Transcript text MUST NOT be represented as direct human assertion when it was produced by automatic speech recognition.
      
+
      recommended mapping:
      
+
      • target URI & method -> source operation metadata
      • authenticated principal -> source actor
      • provider event ID or idempotency key -> native identifier
      • Date & provider timestamps -> source time fields
      • ETag, digest, or signature -> integrity metadata
      • content type -> payload media type
      • response status -> capture or action outcome
      
+
      webhook endpoints MUST validate provider signatures where available, enforce content limits, reject replay & rate-limit before parsing expensive content. server-side request forgery defenses are required when captured payloads contain fetchable URLs.
      
+
      6.2 email#
      
+
      email capture should preserve:
      
+
      • Message-ID & thread references
      • envelope sender & recipient separately from display headers
      • original date & received-chain metadata
      • MIME structure & attachments
      • authentication results when available
      • account & folder source
      • user-applied labels
      
+
      an agent capability such as email.create_draft is distinct from email.send. a bundle granting draft creation MUST NOT authorize send, forward, mailbox search, or attachment access unless listed separately.
      
+
      6.3 files & local workspace data#
      
+
      file adapters should preserve:
      
+
      • stable file identity where the platform provides one
      • original path as a vault-private field
      • file name, media type, size, modification time & digest
      • source repository or workspace
      • version-control commit when applicable
      • access-control context
      
+
      bundles should expose an opaque file handle, excerpt, derived claim, or approved copy rather than an unrestricted local path. a consumer must not use path traversal or symlink resolution to escape the granted workspace.
      
+
      6.4 audio & transcripts#
      
+
      audio should be modeled as a media source event. a transcript is a derived artifact with:
      
+
      • model or service identifier
      • language
      • timing segments when available
      • confidence
      • speaker-attribution status
      • link to the source media
      • redaction state
      
+
      transcript text MUST NOT be represented as direct human assertion when it was produced by automatic speech recognition.
      
 
      6.5 ActivityPub#
      
-
      ActivityPub defines client-to-server and server-to-server social activity using ActivityStreams 2.0.
      
-
      Mapping guidance:
      
-
      • Activity or Object id -> native identifier
      • actor -> source actor
      • published, updated -> source times
      • to, cc, bto, bcc, audience -> native visibility metadata
      • Activity type -> source event type
      • Object content -> untrusted payload
      • Delivery inbox/outbox -> source route
      
-
      Adapters MUST sanitize active content, preserve audience semantics, handle recursive objects defensively, and rate-limit federation traffic. A public ActivityPub object is evidence from an external source, not automatically a trusted claim.
      
-
      6.6 AT Protocol#
      
-
      AT Protocol provides DID-based identity, self-authenticating repositories, content-addressed records, XRPC, and Lexicon schemas.
      
-
      Mapping guidance:
      
-
      • DID -> native principal
      • Handle -> mutable display identifier, not the stable identity
      • Record URI and CID -> native object identity and integrity
      • Lexicon NSID -> source schema type
      • Repository commit and signature verification -> provenance
      • Firehose or subscription sequence -> capture ordering
      
-
      AT Protocol repositories contain public account records. They should be treated as a source or publication target, not as storage for raw private vault content. Context Layer extensions for AT Protocol should use properly governed Lexicons rather than inventing conflicting fields.
      
+
      ActivityPub defines client-to-server & server-to-server social activity using ActivityStreams 2.0.
      
+
      mapping guidance:
      
+
      • activity or object id -> native identifier
      • actor -> source actor
      • published, updated -> source times
      • to, cc, bto, bcc, audience -> native visibility metadata
      • activity type -> source event type
      • object content -> untrusted payload
      • delivery inbox/outbox -> source route
      
+
      adapters MUST sanitize active content, preserve audience semantics, handle recursive objects defensively & rate-limit federation traffic. a public ActivityPub object is evidence from an external source, not automatically a trusted claim.
      
+
      6.6 AT protocol#
      
+
      AT protocol provides DID-based identity, self-authenticating repositories, content-addressed records, XRPC & lexicon schemas.
      
+
      mapping guidance:
      
+
      • DID -> native principal
      • handle -> mutable display identifier, not the stable identity
      • record URI & CID -> native object identity & integrity
      • lexicon NSID -> source schema type
      • repository commit & signature verification -> provenance
      • firehose or subscription sequence -> capture ordering
      
+
      AT protocol repositories contain public account records. they should be treated as a source or publication target, not as storage for raw private vault content. context layer extensions for AT protocol should use properly governed lexicons rather than inventing conflicting fields.
      
 
      6.7 Nostr#
      
 
      NIP-01 defines signed Nostr events distributed through relays.
      
-
      Mapping guidance:
      
-
      • Event id -> native identifier and content digest
      • pubkey -> source principal
      • created_at -> source time
      • kind -> native event type
      • tags -> typed native metadata
      • sig and verification outcome -> integrity metadata
      • Relay URL and first-seen time -> provenance sighting
      
-
      One event received from several relays should normally become one canonical source event with several relay sightings, not several independent facts. Deletion requests are protocol events and do not guarantee that every relay removed prior content.
      
-
      Private context MUST NOT be published to public relays by default. Key custody and signing approval remain separate action-policy concerns.
      
+
      mapping guidance:
      
+
      • event id -> native identifier & content digest
      • pubkey -> source principal
      • created_at -> source time
      • kind -> native event type
      • tags -> typed native metadata
      • sig & verification outcome -> integrity metadata
      • relay URL & first-seen time -> provenance sighting
      
+
      one event received from several relays should normally become one canonical source event with several relay sightings, not several independent facts. deletion requests are protocol events & do not guarantee that every relay removed prior content.
      
+
      private context MUST NOT be published to public relays by default. key custody & signing approval remain separate action-policy concerns.
      
 
      6.8 Matrix#
      
-
      The Matrix Client-Server API uses JSON over HTTP for clients to send events and synchronize room history.
      
-
      Mapping guidance:
      
-
      • event_id -> native identifier
      • room_id -> native context container
      • sender -> source actor
      • origin_server_ts -> source time
      • Event type and state key -> native schema and state identity
      • Relation metadata -> edit, reply, thread, or replacement relationship
      • Encryption and decryption status -> source trust metadata
      
-
      Adapters MUST preserve room visibility, membership context, encryption state, redaction, and replacement relationships. A decrypted event remains private according to room and user policy; decryption is not permission to forward it to a model.
      
-
      6.9 IPFS and content-addressed storage#
      
-
      IPFS identifies content by CID and can transport content-addressed files or DAGs.
      
-
      Safe Context Layer uses include:
      
-
      • Public schema documents
      • Encrypted bundle artifacts where key distribution is separately controlled
      • Content digests for exported receipt batches
      • Public conformance fixtures
      • Portable non-sensitive documentation
      
-
      Unsafe default uses include:
      
-
      • Raw private source events
      • Unencrypted context bundles
      • Direct personal identifiers
      • Secrets or capability tokens
      • Sensitive receipt logs
      
-
      IPFS privacy documentation notes that public network metadata and unencrypted content can be exposed. A CID verifies content identity; it does not create confidentiality, authorization, deletion, or guaranteed persistence.
      
-
      7. Agent and model profiles#
      
-
      7.1 Model Context Protocol#
      
-
      MCP standardizes connections between AI hosts and resources, prompts, and tools.
      
-
      Recommended mapping:
      
-
      Context Layer conceptMCP representation
      Approved bundleRead-only MCP resource with expiring authorization, or structured tool result
      Context requestMCP tool such as request_context with a narrow JSON schema
      User approvalHost-controlled elicitation or separate approval surface
      Action capabilitySeparate MCP tool with explicit input schema and scope
      Proposed writebackTool such as propose_memory_update, never an unrestricted storage resource
      ReceiptStructured tool result plus durable Context Layer receipt
      
-
      MCP servers that expose user-specific data should use its authorization framework and security guidance. Context Layer policy remains an additional resource-use decision. An OAuth token proving access to an MCP server does not by itself authorize every vault field or purpose.
      
-
      The host should keep bundle facts separate from tool descriptions and untrusted resource content. Tool calls must remain allowlisted by the bundle even if the model requests another tool.
      
-
      7.2 Agent2Agent Protocol#
      
-
      A2A defines communication and task collaboration between independent agents.
      
-
      Recommended mapping:
      
-
      • A2A Agent Card -> requester or recipient capability metadata
      • A2A Task -> Context Layer task reference
      • A2A structured DataPart -> scoped bundle or bundle reference
      • A2A Artifact -> generated output governed by bundle action and retention policy
      • A2A task status -> operation receipt input
      • Remote agent identity -> bundle recipient
      
-
      The bundle should be encrypted for and bound to the intended remote agent or trusted gateway. A remote agent must not forward bundle contents to sub-agents or tools unless onward disclosure and those recipients are granted.
      
-
      A2A and MCP are complementary: A2A connects agents to agents; MCP connects AI hosts to tools and resources. Context Layer constrains the private context carried into either relationship.
      
-
      7.3 Direct model API#
      
-
      For a direct local or cloud model call:
      
-
      1. Validate the bundle.
      2. Build the prompt from context, instructions, capabilities, and restrictions as separate sections.
      3. Include only approved facts and source excerpts.
      4. Record the exact model/provider category, not a secret credential.
      5. Apply provider retention and region behavior as recipient-policy inputs.
      6. Restrict tool calling to bundle capabilities.
      7. Validate model output before an external action.
      8. Write a model-call receipt with safe digests and token or cost metadata as permitted.
      9. Convert suggested new facts to memory proposals.
      
-
      Model context windows, embeddings, and vector retrieval are implementation details. They do not define authorization.
      
-
      7.4 OpenAI Realtime voice profile#
      
-
      The OpenAI Realtime WebRTC guide describes browser or mobile WebRTC connection setup through a developer-controlled backend or short-lived client credential.
      
-
      Recommended Context Layer flow:
      
-
      1. The UI requests a voice-capable bundle for a named task.
      2. Policy grants the required facts, tools, duration, and audio behavior.
      3. A backend creates a short-lived Realtime session; the standard provider key stays server-side.
      4. Session instructions contain the bundle's approved context and restrictions.
      5. Tool calls route through policy-aware backend handlers.
      6. Transcripts are classified and captured only when consent and retention policy permit.
      7. Session creation, model calls, tools, and any writeback proposals create receipts.
      8. The session and bundle expire together or the earlier expiry wins.
      
-
      This repository does not include a conforming Realtime voice profile. Any future Realtime implementation must add public-user authentication, durable abuse controls, policy-aware tool handlers, explicit consent, and receipt behavior before deployment.
      
-
      8. User interface profiles#
      
-
      8.1 Required authority state#
      
-
      Any approval or action surface should expose:
      
-
      • Current subject or vault
      • Requester and recipient
      • Purpose
      • Context categories, with sensitive categories highlighted
      • Allowed and denied actions
      • Expiration
      • Whether onward disclosure is allowed
      • Whether memory writeback is disabled, proposed, or approved
      • Receipt status
      • Provenance access appropriate to the user
      
-
      Interfaces must not rely on color alone for policy state.
      
-
      8.2 Self-assembling UI#
      
-
      Core 0.2-draft bundles do not contain surface_hints. A separately negotiated UI profile may associate hints with a bundle reference or publish a derived schema:
      
+
      the Matrix client-server API uses JSON over HTTP for clients to send events & synchronize room history.
      
+
      mapping guidance:
      
+
      • event_id -> native identifier
      • room_id -> native context container
      • sender -> source actor
      • origin_server_ts -> source time
      • event type & state key -> native schema & state identity
      • relation metadata -> edit, reply, thread, or replacement relationship
      • encryption & decryption status -> source trust metadata
      
+
      adapters MUST preserve room visibility, membership context, encryption state, redaction & replacement relationships. a decrypted event remains private according to room & user policy; decryption is not permission to forward it to a model.
      
+
      6.9 IPFS & content-addressed storage#
      
+
      IPFS identifies content by CID & can transport content-addressed files or DAGs.
      
+
      safe context layer uses include:
      
+
      • public schema documents
      • encrypted bundle artifacts where key distribution is separately controlled
      • content digests for exported receipt batches
      • public conformance fixtures
      • portable non-sensitive documentation
      
+
      unsafe default uses include:
      
+
      • raw private source events
      • unencrypted context bundles
      • direct personal identifiers
      • secrets or capability tokens
      • sensitive receipt logs
      
+
      IPFS privacy documentation notes that public network metadata & unencrypted content can be exposed. a CID verifies content identity; it does not create confidentiality, authorization, deletion, or guaranteed persistence.
      
+
      7. agent & model profiles#
      
+
      7.1 model context protocol#
      
+
      MCP standardizes connections between AI hosts & resources, prompts & tools.
      
+
      recommended mapping:
      
+
      context layer conceptMCP representation
      approved bundleread-only MCP resource with expiring authorization, or structured tool result
      context requestMCP tool such as request_context with a narrow JSON schema
      user approvalhost-controlled elicitation or separate approval surface
      action capabilityseparate MCP tool with explicit input schema & scope
      proposed writebacktool such as propose_memory_update, never an unrestricted storage resource
      receiptstructured tool result plus durable context layer receipt
      
+
      MCP servers that expose user-specific data should use its authorization framework & security guidance. context layer policy remains an additional resource-use decision. an OAuth token proving access to an MCP server does not by itself authorize every vault field or purpose.
      
+
      the host should keep bundle facts separate from tool descriptions & untrusted resource content. tool calls must remain allowlisted by the bundle even if the model requests another tool.
      
+
      7.2 Agent2Agent protocol#
      
+
      A2A defines communication & task collaboration between independent agents.
      
+
      recommended mapping:
      
+
      • A2A agent card -> requester or recipient capability metadata
      • A2A task -> context layer task reference
      • A2A structured DataPart -> scoped bundle or bundle reference
      • A2A artifact -> generated output governed by bundle action & retention policy
      • A2A task status -> operation receipt input
      • remote agent identity -> bundle recipient
      
+
      the bundle should be encrypted for & bound to the intended remote agent or trusted gateway. a remote agent must not forward bundle contents to sub-agents or tools unless onward disclosure & those recipients are granted.
      
+
      A2A & MCP are complementary: A2A connects agents to agents; MCP connects AI hosts to tools & resources. context layer constrains the private context carried into either relationship.
      
+
      7.3 direct model API#
      
+
      for a direct local or cloud model call:
      
+
      1. validate the bundle.
      2. build the prompt from context, instructions, capabilities & restrictions as separate sections.
      3. include only approved facts & source excerpts.
      4. record the exact model/provider category, not a secret credential.
      5. apply provider retention & region behavior as recipient-policy inputs.
      6. restrict tool calling to bundle capabilities.
      7. validate model output before an external action.
      8. write a model-call receipt with safe digests & token or cost metadata as permitted.
      9. convert suggested new facts to memory proposals.
      
+
      model context windows, embeddings & vector retrieval are implementation details. they do not define authorization.
      
+
      7.4 OpenAI realtime voice profile#
      
+
      the OpenAI realtime WebRTC guide describes browser or mobile WebRTC connection setup through a developer-controlled backend or short-lived client credential.
      
+
      recommended context layer flow:
      
+
      1. the UI requests a voice-capable bundle for a named task.
      2. policy grants the required facts, tools, duration & audio behavior.
      3. a backend creates a short-lived realtime session; the standard provider key stays server-side.
      4. session instructions contain the bundle's approved context & restrictions.
      5. tool calls route through policy-aware backend handlers.
      6. transcripts are classified & captured only when consent & retention policy permit.
      7. session creation, model calls, tools & any writeback proposals create receipts.
      8. the session & bundle expire together or the earlier expiry wins.
      
+
      this repository does not include a conforming realtime voice profile. any future realtime implementation must add public-user authentication, durable abuse controls, policy-aware tool handlers, explicit consent & receipt behavior before deployment.
      
+
      8. user interface profiles#
      
+
      8.1 required authority state#
      
+
      any approval or action surface should expose:
      
+
      • current subject or vault
      • requester & recipient
      • purpose
      • context categories, with sensitive categories highlighted
      • allowed & denied actions
      • expiration
      • whether onward disclosure is allowed
      • whether memory writeback is disabled, proposed, or approved
      • receipt status
      • provenance access appropriate to the user
      
+
      interfaces must not rely on color alone for policy state.
      
+
      8.2 self-assembling UI#
      
+
      core 0.2-draft bundles do not contain surface_hints. a separately negotiated UI profile may associate hints with a bundle reference or publish a derived schema:
      
 
      {
   "profile": "https://example.com/context-layer/ui-hints-v1",
   "bundle_ref": "urn:cl:bundle:ctxb_209",
@@ -209,72 +209,72 @@ 
      8.2 Self-assembling UI
      
-
      Surface hints are not executable code and do not expand the core bundle's authority. A renderer must map them to trusted components from an allowlisted design system. Generated markup, scripts, and remote component URLs should not be accepted from untrusted profiles.
      
-
      8.3 Web profile#
      
-
      • Keep approvals and receipts in first-class views, not hidden settings.
      • Use accessible focus, keyboard, and screen-reader behavior.
      • Avoid rendering untrusted source HTML without sanitization.
      • Keep secrets and standard provider credentials off the client.
      • Use strict Content Security Policy and origin checks for privileged routes.
      • Make expiry and revoked state visible.
      
-
      8.4 iOS and mobile profile#
      
-
      An iOS client can act as an approval surface, context consumer, capture adapter, or local vault host.
      
-
      Recommended boundaries:
      
-
      • Store OAuth tokens and local encryption keys using platform-secure facilities.
      • Never embed a standard model-provider API key in the app.
      • Request short-lived provider sessions from an authenticated backend.
      • Use per-feature OS permissions and explain which source adapter needs each one.
      • Keep background capture opt-in, visible, and bounded.
      • Handle protected-data unavailability when the device is locked.
      • Bind local cached bundles to the app instance and expiration.
      • Queue receipts safely offline and fail closed for operations whose receipt is mandatory.
      • Expose pending memory proposals and approvals in a durable review queue.
      
-
      The current repository does not include an iOS project, so this is a target profile rather than implemented behavior.
      
-
      9. Payments and x402#
      
-
      x402 uses HTTP payment requirements for services and agents. It can compose with Context Layer in three places:
      
-
      • A discovery request may require payment before expensive private matching.
      • An action capability may require a payment authorization.
      • A receipt may reference an external payment receipt.
      
-
      The policy engine must evaluate payment and context separately:
      
+
      surface hints are not executable code & do not expand the core bundle's authority. a renderer must map them to trusted components from an allowlisted design system. generated markup, scripts & remote component URLs should not be accepted from untrusted profiles.
      
+
      8.3 web profile#
      
+
      • keep approvals & receipts in first-class views, not hidden settings.
      • use accessible focus, keyboard & screen-reader behavior.
      • avoid rendering untrusted source HTML without sanitization.
      • keep secrets & standard provider credentials off the client.
      • use strict content security policy & origin checks for privileged routes.
      • make expiry & revoked state visible.
      
+
      8.4 iOS & mobile profile#
      
+
      an iOS client can act as an approval surface, context consumer, capture adapter, or local vault host.
      
+
      recommended boundaries:
      
+
      • store OAuth tokens & local encryption keys using platform-secure facilities.
      • never embed a standard model-provider API key in the app.
      • request short-lived provider sessions from an authenticated backend.
      • use per-feature OS permissions & explain which source adapter needs each one.
      • keep background capture opt-in, visible & bounded.
      • handle protected-data unavailability when the device is locked.
      • bind local cached bundles to the app instance & expiration.
      • queue receipts safely offline & fail closed for operations whose receipt is mandatory.
      • expose pending memory proposals & approvals in a durable review queue.
      
+
      the current repository does not include an iOS project, so this is a target profile rather than implemented behavior.
      
+
      9. payments & x402#
      
+
      x402 uses HTTP payment requirements for services & agents. it can compose with context layer in three places:
      
+
      • a discovery request may require payment before expensive private matching.
      • an action capability may require a payment authorization.
      • a receipt may reference an external payment receipt.
      
+
      the policy engine must evaluate payment & context separately:
      
 
      payment satisfied != context disclosure authorized
 context disclosure authorized != payment action authorized
      
-
      Payment credentials, wallet keys, and transaction secrets must not be included in context bundles. Only minimal payment status and receipt references should cross the boundary.
      
-
      10. End-to-end integration recipes#
      
-
      10.1 Email source to drafting agent#
      
-
      1. Capture a native email and preserve Message-ID, MIME, account, sender, recipient, and timestamp.
      2. Extract deadline and stakeholder claims; classify a budget note as restricted.
      3. Agent submits a request for deadline and stakeholder with email.create_draft.
      4. Policy denies the budget field and email.send.
      5. Semantic proxy emits a short bundle.
      6. Agent generates a draft and calls the draft-only adapter.
      7. Receipt records model call and native draft ID.
      8. Any inferred deadline change becomes a proposal.
      
+
      payment credentials, wallet keys & transaction secrets must not be included in context bundles. only minimal payment status & receipt references should cross the boundary.
      
+
      10. end-to-end integration recipes#
      
+
      10.1 email source to drafting agent#
      
+
      1. capture a native email & preserve Message-ID, MIME, account, sender, recipient & timestamp.
      2. extract deadline & stakeholder claims; classify a budget note as restricted.
      3. agent submits a request for deadline & stakeholder with email.create_draft.
      4. policy denies the budget field & email.send.
      5. semantic proxy emits a short bundle.
      6. agent generates a draft & calls the draft-only adapter.
      7. receipt records model call & native draft ID.
      8. any inferred deadline change becomes a proposal.
      
 
      10.2 Nostr opportunity discovery#
      
-
      1. A capture adapter verifies a signed event from one or more relays.
      2. It records one source event and several relay sightings.
      3. The opportunity service submits an authenticated discovery query.
      4. The proxy checks query budget and evaluates private skills locally.
      5. It returns possible_match and an approval-required contact route.
      6. User approval creates a second bundle containing only the chosen contact detail.
      7. Both the query and reveal produce receipts.
      
+
      1. a capture adapter verifies a signed event from one or more relays.
      2. it records one source event & several relay sightings.
      3. the opportunity service submits an authenticated discovery query.
      4. the proxy checks query budget & evaluates private skills locally.
      5. it returns possible_match & an approval-required contact route.
      6. user approval creates a second bundle containing only the chosen contact detail.
      7. both the query & reveal produce receipts.
      
 
      10.3 MCP tool using private project context#
      
-
      1. MCP host invokes request_context with task, selectors, tool, and expiry.
      2. Context Layer returns needs_approval or an approved bundle resource.
      3. Host makes the bundle available only to the current model turn or workflow.
      4. Model requests an allowlisted MCP tool.
      5. Tool handler validates the bundle capability again before side effects.
      6. Tool output and receipt return as structured data.
      7. MCP server cannot resolve opaque provenance without a new request.
      
+
      1. MCP host invokes request_context with task, selectors, tool & expiry.
      2. context layer returns needs_approval or an approved bundle resource.
      3. host makes the bundle available only to the current model turn or workflow.
      4. model requests an allowlisted MCP tool.
      5. tool handler validates the bundle capability again before side effects.
      6. tool output & receipt return as structured data.
      7. MCP server cannot resolve opaque provenance without a new request.
      
 
      10.4 A2A delegation#
      
-
      1. Local agent discovers a remote agent's capabilities.
      2. Local policy binds the remote agent as recipient and prohibits onward disclosure.
      3. Bundle is encrypted or delivered through a trusted gateway as structured task data.
      4. Remote agent completes the task within listed actions.
      5. Remote result includes task metadata; a Context Layer gateway writes the receipt.
      6. Any follow-up requiring more context creates a new request.
      
-
      10.5 Voice assistant on web or iOS#
      
-
      1. User chooses voice mode and a task.
      2. UI displays which context categories and tools will be available.
      3. Policy issues a short-lived bundle.
      4. Backend creates a short-lived Realtime session; long-lived credentials remain outside the client.
      5. Voice model receives only approved facts and tools.
      6. Tool actions require server-side capability checks and any step-up approval.
      7. Transcript capture follows a separate consent and retention rule.
      8. Session, bundle, and voice indicators end together.
      
-
      11. Implementation sequence#
      
-
      The architecture map should not be implemented all at once. A practical sequence is:
      
-
      Phase 0: Contract and fixtures#
      
-
      • Freeze draft object names and invariants.
      • Publish JSON Schemas for request, decision, bundle, proposal, and receipt.
      • Create valid and invalid synthetic fixtures.
      • Implement deterministic schema and secret scans.
      
-
      Phase 1: Local core#
      
-
      • Build one local vault with encrypted source payloads.
      • Implement one policy engine with explicit allow, reduce, deny, and approval states.
      • Implement semantic field filtering plus a simple deterministic bundle issuer.
      • Write append-only local receipts.
      • Prove raw-vault isolation in tests.
      
-
      Phase 2: One real source and one consumer#
      
-
      • Add one source adapter, preferably files or email with a narrow scope.
      • Add one consumer, preferably a local agent or MCP host.
      • Implement proposal-only writeback.
      • Test expiry, revocation, and receipt failure.
      
-
      Phase 3: Discovery and remote agents#
      
-
      • Add query budgets and minimum-reveal responses.
      • Add an A2A or remote-agent profile.
      • Introduce recipient-bound encryption and stronger identity.
      • Perform privacy and abuse testing.
      
-
      Phase 4: UI and platform expansion#
      
-
      • Build consistent web and iOS approval/receipt surfaces.
      • Add Realtime voice using short-lived sessions.
      • Add trusted self-assembling UI components.
      • Publish a cross-language conformance kit.
      
-
      12. Verification checklist#
      
-
      Architecture#
      
-
      • [ ] External consumers cannot enumerate raw vault objects.
      • [ ] Request, decision, bundle, and receipt IDs form a traceable chain.
      • [ ] Policy can reduce scope, not only allow or deny.
      • [ ] Every bundle is recipient-bound and expiring.
      • [ ] Proposed writeback is separated from committed memory.
      
-
      Adapter fidelity#
      
-
      • [ ] Native identifiers and security metadata are preserved.
      • [ ] Edits, deletions, and relay sightings have explicit mappings.
      • [ ] Untrusted content cannot become control instructions.
      • [ ] Lossy fields are documented and tested.
      
-
      Security#
      
-
      • [ ] Secrets are absent from client bundles, logs, archives, and receipts.
      • [ ] Local network services are not exposed beyond their intended boundary.
      • [ ] Network tokens are validated for issuer, audience, expiry, and scope.
      • [ ] Prompt injection cannot expand capabilities.
      • [ ] Discovery probes are rate-limited by semantic and identity context.
      • [ ] Receipt preflight failure closes the operation; post-action persistence failure enters an indeterminate recovery state.
      
-
      User experience#
      
-
      • [ ] Approval shows requester, purpose, fields, actions, recipient, and expiry.
      • [ ] Denied and withheld context is represented without leaking it.
      • [ ] Receipts are readable and searchable.
      • [ ] Pending memory proposals have approve, reject, and inspect-source paths.
      • [ ] Voice and background capture states are continuously visible.
      
-
      Operations#
      
-
      • [ ] Key rotation, backup, recovery, revocation, and deletion are documented.
      • [ ] Conformance fixtures run deterministically.
      • [ ] Version migrations are tested before policy or schema rollout.
      • [ ] Incident response can identify affected bundles and recipients from receipts.
      
-
      13. Known limitations and research areas#
      
-
      • Semantic redaction is probabilistic and can leak indirect identifiers.
      • Provenance does not guarantee source truth.
      • Signed receipts attest to reported operations, not complete behavioral correctness.
      • Recipient deletion and retention may be impossible to enforce after disclosure without trusted hardware or legal controls.
      • Minimum-reveal matching remains vulnerable to inference without robust query accounting.
      • Cross-device user ownership requires difficult recovery and delegation choices.
      • Policy language can become too complex for users to understand.
      • Self-assembling interfaces can obscure authority unless constrained to trusted components.
      • Interoperability requires governance, registered schemas, test suites, and multiple independent implementations.
      
-
      These limitations are part of the protocol design problem, not reasons to hide the boundary behind a generic "AI memory" feature.
      
-
      14. Primary references#
      
-
      +
      1. local agent discovers a remote agent's capabilities.
      2. local policy binds the remote agent as recipient & prohibits onward disclosure.
      3. bundle is encrypted or delivered through a trusted gateway as structured task data.
      4. remote agent completes the task within listed actions.
      5. remote result includes task metadata; a context layer gateway writes the receipt.
      6. any follow-up requiring more context creates a new request.
      +

      10.5 voice assistant on web or iOS#

      +
      1. user chooses voice mode & a task.
      2. UI displays which context categories & tools will be available.
      3. policy issues a short-lived bundle.
      4. backend creates a short-lived realtime session; long-lived credentials remain outside the client.
      5. voice model receives only approved facts & tools.
      6. tool actions require server-side capability checks & any step-up approval.
      7. transcript capture follows a separate consent & retention rule.
      8. session, bundle & voice indicators end together.
      +

      11. implementation sequence#

      +

      the architecture map should not be implemented all at once. a practical sequence is:

      +

      phase 0: contract & fixtures#

      +
      • freeze draft object names & invariants.
      • publish JSON schemas for request, decision, bundle, proposal & receipt.
      • create valid & invalid synthetic fixtures.
      • implement deterministic schema & secret scans.
      +

      phase 1: local core#

      +
      • build one local vault with encrypted source payloads.
      • implement one policy engine with explicit allow, reduce, deny & approval states.
      • implement semantic field filtering plus a simple deterministic bundle issuer.
      • write append-only local receipts.
      • prove raw-vault isolation in tests.
      +

      phase 2: one real source & one consumer#

      +
      • add one source adapter, preferably files or email with a narrow scope.
      • add one consumer, preferably a local agent or MCP host.
      • implement proposal-only writeback.
      • test expiry, revocation & receipt failure.
      +

      phase 3: discovery & remote agents#

      +
      • add query budgets & minimum-reveal responses.
      • add an A2A or remote-agent profile.
      • introduce recipient-bound encryption & stronger identity.
      • perform privacy & abuse testing.
      +

      phase 4: UI & platform expansion#

      +
      • build consistent web & iOS approval/receipt surfaces.
      • add realtime voice using short-lived sessions.
      • add trusted self-assembling UI components.
      • publish a cross-language conformance kit.
      +

      12. verification checklist#

      +

      architecture#

      +
      • [ ] external consumers cannot enumerate raw vault objects.
      • [ ] request, decision, bundle & receipt IDs form a traceable chain.
      • [ ] policy can reduce scope, not only allow or deny.
      • [ ] every bundle is recipient-bound & expiring.
      • [ ] proposed writeback is separated from committed memory.
      +

      adapter fidelity#

      +
      • [ ] native identifiers & security metadata are preserved.
      • [ ] edits, deletions & relay sightings have explicit mappings.
      • [ ] untrusted content cannot become control instructions.
      • [ ] lossy fields are documented & tested.
      +

      security#

      +
      • [ ] secrets are absent from client bundles, logs, archives & receipts.
      • [ ] local network services are not exposed beyond their intended boundary.
      • [ ] network tokens are validated for issuer, audience, expiry & scope.
      • [ ] prompt injection cannot expand capabilities.
      • [ ] discovery probes are rate-limited by semantic & identity context.
      • [ ] receipt preflight failure closes the operation; post-action persistence failure enters an indeterminate recovery state.
      +

      user experience#

      +
      • [ ] approval shows requester, purpose, fields, actions, recipient & expiry.
      • [ ] denied & withheld context is represented without leaking it.
      • [ ] receipts are readable & searchable.
      • [ ] pending memory proposals have approve, reject & inspect-source paths.
      • [ ] voice & background capture states are continuously visible.
      +

      operations#

      +
      • [ ] key rotation, backup, recovery, revocation & deletion are documented.
      • [ ] conformance fixtures run deterministically.
      • [ ] version migrations are tested before policy or schema rollout.
      • [ ] incident response can identify affected bundles & recipients from receipts.
      +

      13. known limitations & research areas#

      +
      • semantic redaction is probabilistic & can leak indirect identifiers.
      • provenance does not guarantee source truth.
      • signed receipts attest to reported operations, not complete behavioral correctness.
      • recipient deletion & retention may be impossible to enforce after disclosure without trusted hardware or legal controls.
      • minimum-reveal matching remains vulnerable to inference without robust query accounting.
      • cross-device user ownership requires difficult recovery & delegation choices.
      • policy language can become too complex for users to understand.
      • self-assembling interfaces can obscure authority unless constrained to trusted components.
      • interoperability requires governance, registered schemas, test suites & multiple independent implementations.
      +

      these limitations are part of the protocol design problem, not reasons to hide the boundary behind a generic "AI memory" feature.

      +

      14. primary references#

      +
      -

      Context Layer / public working proposal

      +

      context layer / public working proposal

      sierra catalina / 2026

      diff --git a/site/context-layer/_pages/index.html b/site/context-layer/_pages/index.html index ac56521..c68aeb8 100644 --- a/site/context-layer/_pages/index.html +++ b/site/context-layer/_pages/index.html @@ -4,18 +4,18 @@ - + - - + + - + -the Context Layer | sierra catalina +the context layer | sierra catalina @@ -40,7 +40,7 @@

      dossier 001 / public working proposal / 2026.08.21

      -

      the Context Layer.

      +

      the context layer.

      a user-controlled contract for moving the minimum useful context across models, agents & applications.

      read the essay @@ -92,7 +92,7 @@

      from argument to implementation.

      -

      Context Layer / public working proposal

      +

      context layer / public working proposal

      sierra catalina / 2026

      diff --git a/site/context-layer/_pages/specification.html b/site/context-layer/_pages/specification.html index 9751745..03a48da 100644 --- a/site/context-layer/_pages/specification.html +++ b/site/context-layer/_pages/specification.html @@ -4,18 +4,18 @@ - + - - + + - + -Context Layer Protocol | sierra catalina +context layer protocol | sierra catalina @@ -39,8 +39,8 @@

      technical reference / v0.2 draft

      -

      Context Layer Protocol

      -

      A reviewable core contract for implementation and interoperability experiments.

      +

      context layer protocol

      +

      a reviewable core contract for implementation & interoperability experiments.

      working draft 2026.08 @@ -48,37 +48,37 @@

      Context Layer Protocol

      - -

      Draft Technical Specification v0.2#

      -
      FieldValue
      StatusWorking Draft - not an adopted standard
      Version identifiercontext-layer/0.2-draft
      Date2026-08-17
      Editors' targetReviewable core contract for implementation and interoperability experiments
      Canonical local context../agent-navigation-manifest.json
      -

      Change log#

      -
      • 2026.08.17 · v0.2 draft · purpose codes, Lite profile, expires_at unification
      -

      Abstract#

      -

      The Context Layer is an application-layer protocol for exchanging purpose-bound context between a user-controlled context vault and external applications, agents, models, discovery systems, and user interfaces. It defines source and provenance records, context requests, policy decisions, scoped context bundles, proposed memory updates, and operation receipts.

      -

      The protocol's central invariant is that a consumer receives an approved bundle rather than unrestricted raw-vault access. The specification is transport-neutral. An HTTP binding and adapter guidance are defined as profiles; existing transports and domain protocols retain their own semantics.

      -

      This document defines the target contract. The current project is an interactive demonstrator and does not yet implement the complete protocol.

      -

      1. Requirements language#

      -

      The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

      -

      Normative requirements apply only to an implementation claiming conformance with the named profile. Descriptive text and examples are informative unless explicitly labeled normative.

      -

      2. Status and scope#

      -

      2.1 In scope#

      -

      This draft specifies:

      -
      • The trust boundary between a context vault and a context consumer
      • Stable envelopes for source events, derived claims, context requests, policy decisions, scoped context bundles, discovery results, proposed memory updates, and receipts
      • The lifecycle for outbound context, inbound discovery, and memory writeback
      • Minimum policy inputs and disclosure constraints
      • Provenance and expiry requirements
      • A transport-neutral core and an optional HTTP binding
      • Conformance roles and failure behavior
      • Security and privacy requirements that are specific to context movement
      -

      2.2 Protocol boundary#

      -

      Context Layer governs the context exchange: purpose-bound requests, policy decisions, scoped bundles, receipts, and proposed writeback. It composes with deployment-selected transport, identity, authentication, cryptography, storage, source authorization, and payment systems.

      -

      A conforming deployment MUST preserve source permissions and select identity, encryption, key-management, storage, audit, and redaction controls appropriate to its threat model. Conformance does not imply legal compliance or correct model output.

      -

      3. Design goals and invariants#

      -

      A conforming implementation MUST preserve these invariants:

      -
      1. No ambient raw-vault access. A context consumer MUST NOT receive an unrestricted vault query interface as the default exchange mechanism.
      2. Purpose-bound requests. Every disclosure MUST be tied to an authenticated requester, declared purpose, recipient, requested scope, and validity window.
      3. Reducible scope. A policy engine MUST be able to grant a strict subset of a request.
      4. Provenance continuity. Every disclosed derived claim MUST contain or reference enough provenance to identify its supporting source records within the authority boundary.
      5. Expiry. Every scoped bundle MUST have an explicit expiration time or a single-use constraint. The CL-Core-Lite profile requires both a finite expires_at and single_use: true.
      6. Non-escalation. A consumer MUST NOT infer permission for fields, tools, actions, retention, or onward disclosure that are absent from a bundle.
      7. Proposed writeback. Agent-generated memory MUST enter as a proposal unless an explicit policy grants automatic commit for that exact proposal class.
      8. Receipted sensitive operations. A required receipt path MUST be available before a sensitive operation begins. An implementation MUST NOT report success until its completion receipt is durable.
      9. Minimum reveal for discovery. External matching MUST return only policy-approved result fields and MUST NOT expose private match features or scores unless explicitly granted.
      10. Native-protocol preservation. Adapters MUST preserve security-relevant semantics from the source protocol rather than flattening them into unauthenticated text.
      -

      4. Architecture#

      -

      4.1 Components#

      -
      ComponentResponsibilityTrust position
      Capture adapterConvert native source material into source events and provenanceMay cross from an external or untrusted system into the vault boundary
      NormalizerMap source-specific shapes into stable typed recordsInside the vault boundary
      ExtractorDerive claims, entities, relations, summaries, and contradictionsInside the vault boundary
      Context vaultStore private source records, derived context, identities, policies, and receipt referencesUser-controlled authority boundary
      Policy engineEvaluate requester, purpose, scope, recipient, action, consent, retention, and receipt requirementsTrusted decision point
      Semantic proxyRedact, alias, compress, transform, and route outbound contextBoundary enforcement point
      Discovery proxyEvaluate external matching requests and produce minimum-reveal responsesInbound boundary enforcement point
      Bundle issuerAssemble immutable, short-lived, task-specific contextTrusted issuer
      Context consumerUse a bundle in an app, agent, model, workflow, or UIOutside or separately sandboxed from the vault
      Receipt storePersist logically append-only operation evidenceTrusted evidence service; may be separately administered
      Approval surfaceObtain and record a person's approval when requiredTrusted user-interaction boundary
      -

      One process MAY implement several components, but logical responsibilities and authorization checks MUST remain separable and testable.

      -

      4.2 Trust zones#

      -

      The minimum deployment model contains three zones:

      -
      1. Vault zone: raw sources, private claims, identity bindings, policy, and keys.
      2. Controlled exchange zone: policy engine, proxies, bundle issuer, and receipt writer.
      3. Consumer or untrusted zone: external apps, remote agents, public discovery systems, relays, models, and UI plug-ins.
      -

      The consumer MAY be locally operated and still be treated as a separate trust zone. Process locality is not proof of authorization.

      -

      4.3 Core flow#

      + +

      draft technical specification v0.2#

      +
      fieldvalue
      statusworking draft - not an adopted standard
      version identifiercontext-layer/0.2-draft
      date2026-08-17
      editors' targetreviewable core contract for implementation & interoperability experiments
      +

      change log#

      +
      • 2026.08.17 · v0.2 draft · purpose codes, lite profile, expires_at unification
      +

      abstract#

      +

      the context layer is an application-layer protocol for exchanging purpose-bound context between a user-controlled context vault & external applications, agents, models, discovery systems & user interfaces. it defines source & provenance records, context requests, policy decisions, scoped context bundles, proposed memory updates & operation receipts.

      +

      the protocol's central invariant is that a consumer receives an approved bundle rather than unrestricted raw-vault access. the specification is transport-neutral. an HTTP binding & adapter guidance are defined as profiles; existing transports & domain protocols retain their own semantics.

      +

      this document defines the target contract. the current project is an interactive demonstrator & does not yet implement the complete protocol.

      +

      1. requirements language#

      +

      the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY & OPTIONAL in this document are to be interpreted as described in BCP 14 when & only when, they appear in all capitals.

      +

      normative requirements apply only to an implementation claiming conformance with the named profile. descriptive text & examples are informative unless explicitly labeled normative.

      +

      2. status & scope#

      +

      2.1 in scope#

      +

      this draft specifies:

      +
      • the trust boundary between a context vault & a context consumer
      • stable envelopes for source events, derived claims, context requests, policy decisions, scoped context bundles, discovery results, proposed memory updates & receipts
      • the lifecycle for outbound context, inbound discovery & memory writeback
      • minimum policy inputs & disclosure constraints
      • provenance & expiry requirements
      • a transport-neutral core & an optional HTTP binding
      • conformance roles & failure behavior
      • security & privacy requirements that are specific to context movement
      +

      2.2 protocol boundary#

      +

      context layer governs the context exchange: purpose-bound requests, policy decisions, scoped bundles, receipts & proposed writeback. it composes with deployment-selected transport, identity, authentication, cryptography, storage, source authorization & payment systems.

      +

      a conforming deployment MUST preserve source permissions & select identity, encryption, key-management, storage, audit & redaction controls appropriate to its threat model. conformance does not imply legal compliance or correct model output.

      +

      3. design goals & invariants#

      +

      a conforming implementation MUST preserve these invariants:

      +
      1. no ambient raw-vault access. a context consumer MUST NOT receive an unrestricted vault query interface as the default exchange mechanism.
      2. purpose-bound requests. every disclosure MUST be tied to an authenticated requester, declared purpose, recipient, requested scope & validity window.
      3. reducible scope. a policy engine MUST be able to grant a strict subset of a request.
      4. provenance continuity. every disclosed derived claim MUST contain or reference enough provenance to identify its supporting source records within the authority boundary.
      5. expiry. every scoped bundle MUST have an explicit expiration time or a single-use constraint. the CL-Core-Lite profile requires both a finite expires_at & single_use: true.
      6. non-escalation. a consumer MUST NOT infer permission for fields, tools, actions, retention, or onward disclosure that are absent from a bundle.
      7. proposed writeback. agent-generated memory MUST enter as a proposal unless an explicit policy grants automatic commit for that exact proposal class.
      8. receipted sensitive operations. a required receipt path MUST be available before a sensitive operation begins. an implementation MUST NOT report success until its completion receipt is durable.
      9. minimum reveal for discovery. external matching MUST return only policy-approved result fields & MUST NOT expose private match features or scores unless explicitly granted.
      10. native-protocol preservation. adapters MUST preserve security-relevant semantics from the source protocol rather than flattening them into unauthenticated text.
      +

      4. architecture#

      +

      4.1 components#

      +
      componentresponsibilitytrust position
      capture adapterconvert native source material into source events & provenancemay cross from an external or untrusted system into the vault boundary
      normalizermap source-specific shapes into stable typed recordsinside the vault boundary
      extractorderive claims, entities, relations, summaries & contradictionsinside the vault boundary
      context vaultstore private source records, derived context, identities, policies & receipt referencesuser-controlled authority boundary
      policy engineevaluate requester, purpose, scope, recipient, action, consent, retention & receipt requirementstrusted decision point
      semantic proxyredact, alias, compress, transform & route outbound contextboundary enforcement point
      discovery proxyevaluate external matching requests & produce minimum-reveal responsesinbound boundary enforcement point
      bundle issuerassemble immutable, short-lived, task-specific contexttrusted issuer
      context consumeruse a bundle in an app, agent, model, workflow, or UIoutside or separately sandboxed from the vault
      receipt storepersist logically append-only operation evidencetrusted evidence service; may be separately administered
      approval surfaceobtain & record a person's approval when requiredtrusted user-interaction boundary
      +

      one process MAY implement several components, but logical responsibilities & authorization checks MUST remain separable & testable.

      +

      4.2 trust zones#

      +

      the minimum deployment model contains three zones:

      +
      1. vault zone: raw sources, private claims, identity bindings, policy & keys.
      2. controlled exchange zone: policy engine, proxies, bundle issuer & receipt writer.
      3. consumer or untrusted zone: external apps, remote agents, public discovery systems, relays, models & UI plug-ins.
      +

      the consumer MAY be locally operated & still be treated as a separate trust zone. process locality is not proof of authorization.

      +

      4.3 core flow#

      native source
   -> capture + source tagging
   -> normalize + deduplicate
@@ -92,38 +92,38 @@ 
      4.3 Core flow5. Terminology#
      
-
      Subject The person, organization, project, device, or other principal whose context is governed. The subject may be represented by a deployment-local pseudonymous identifier.
      
-
      Source event An immutable or versioned record of an observed native event plus origin metadata. It is evidence, not automatically a fact.
      
-
      Claim A typed statement derived from one or more source events. A claim has provenance, confidence, validity, and status.
      
-
      Vault The authority boundary that stores and governs source events, claims, summaries, identities, policies, and receipts. "User-owned" refers to control and delegation, not necessarily physical device location.
      
-
      Context request A request for specific context for a named purpose, recipient, task, retention period, and action set.
      
-
      Policy decision The versioned outcome of evaluating a request against identity, consent, sensitivity, purpose, recipient, action, expiry, and receipt rules.
      
-
      Semantic proxy The outbound enforcement component that produces the least-context representation allowed by policy.
      
-
      Discovery proxy The inbound enforcement component that evaluates an external query against private context and returns a minimum-reveal result.
      
-
      Scoped context bundle An immutable, expiring packet of approved context, provenance, instructions, capabilities, restrictions, and receipt requirements.
      
-
      Receipt A logically append-only record of a request, decision, transform, disclosure, model call, tool call, external action, or memory operation.
      
-
      Memory update proposal A candidate addition, change, contradiction, or retraction that has not yet been committed as durable context.
      
-
      6. Common representation rules#
      
-
      6.1 Serialization#
      
-
      The core representation is JSON encoded as UTF-8.
      
-
      Every top-level object MUST contain:
      
-
      FieldTypeRequirement
      spec_versionstringMUST equal a supported protocol identifier such as context-layer/0.2-draft
      typestringMUST identify the object type
      idstringMUST be unique within the issuing authority
      created_atstringMUST be an RFC 3339 timestamp
      issuerobjectMUST identify the issuing component or authority
      
-
      Identifiers SHOULD be opaque URIs such as urn:cl:bundle:019.... Identifiers MUST NOT embed email addresses, names, access tokens, raw content, or other unnecessary private data.
      
-
      Timestamps MUST use RFC 3339 format and SHOULD be normalized to UTC. Implementations MUST preserve the original timestamp and timezone when they are material to the source.
      
-
      6.2 Media type#
      
-
      This draft uses application/vnd.context-layer+json as an experimental media-type string. It is not IANA registered. Production interoperability work MUST either register an appropriate media type or negotiate a deployment-specific type without misrepresenting registration status.
      
-
      6.3 Extension fields#
      
-
      The five CL-Core-Lite object schemas in this draft are closed: implementations MUST reject unknown top-level fields. Version 0.2-draft does not define portable extensions or required_extensions members.
      
-
      An experimental profile MAY publish a derived schema with a collision-resistant namespace, but an object using that profile is not a core 0.2-draft object unless the profile is explicitly negotiated. A future specification revision may define optional and required extension negotiation; implementations MUST NOT silently treat unknown fields as authorized extensions before then.
      
-
      6.4 Integrity#
      
-
      Objects MAY include an integrity object with a digest, canonicalization method, and signature reference. A signature MUST cover the protocol version, object type, identifier, issuer, timestamps, and all security-relevant fields.
      
-
      This draft does not mandate a signing suite. Deployments MUST define canonical serialization and key verification before claiming cryptographically verifiable receipts or bundles.
      
-
      7. Core data objects#
      
-
      The examples in this section use synthetic values and omit optional fields for readability.
      
+
      5. terminology#
      
+
      subject the person, organization, project, device, or other principal whose context is governed. the subject may be represented by a deployment-local pseudonymous identifier.
      
+
      source event an immutable or versioned record of an observed native event plus origin metadata. it is evidence, not automatically a fact.
      
+
      claim a typed statement derived from one or more source events. a claim has provenance, confidence, validity & status.
      
+
      vault the authority boundary that stores & governs source events, claims, summaries, identities, policies & receipts. "user-owned" refers to control & delegation, not necessarily physical device location.
      
+
      context request a request for specific context for a named purpose, recipient, task, retention period & action set.
      
+
      policy decision the versioned outcome of evaluating a request against identity, consent, sensitivity, purpose, recipient, action, expiry & receipt rules.
      
+
      semantic proxy the outbound enforcement component that produces the least-context representation allowed by policy.
      
+
      discovery proxy the inbound enforcement component that evaluates an external query against private context & returns a minimum-reveal result.
      
+
      scoped context bundle an immutable, expiring packet of approved context, provenance, instructions, capabilities, restrictions & receipt requirements.
      
+
      receipt a logically append-only record of a request, decision, transform, disclosure, model call, tool call, external action, or memory operation.
      
+
      memory update proposal a candidate addition, change, contradiction, or retraction that has not yet been committed as durable context.
      
+
      6. common representation rules#
      
+
      6.1 serialization#
      
+
      the core representation is JSON encoded as UTF-8.
      
+
      every top-level object MUST contain:
      
+
      fieldtyperequirement
      spec_versionstringMUST equal a supported protocol identifier such as context-layer/0.2-draft
      typestringMUST identify the object type
      idstringMUST be unique within the issuing authority
      created_atstringMUST be an RFC 3339 timestamp
      issuerobjectMUST identify the issuing component or authority
      
+
      identifiers SHOULD be opaque URIs such as urn:cl:bundle:019.... identifiers MUST NOT embed email addresses, names, access tokens, raw content, or other unnecessary private data.
      
+
      timestamps MUST use RFC 3339 format & SHOULD be normalized to UTC. implementations MUST preserve the original timestamp & timezone when they are material to the source.
      
+
      6.2 media type#
      
+
      this draft uses application/vnd.context-layer+json as an experimental media-type string. it is not IANA registered. production interoperability work MUST either register an appropriate media type or negotiate a deployment-specific type without misrepresenting registration status.
      
+
      6.3 extension fields#
      
+
      the five CL-Core-Lite object schemas in this draft are closed: implementations MUST reject unknown top-level fields. version 0.2-draft does not define portable extensions or required_extensions members.
      
+
      an experimental profile MAY publish a derived schema with a collision-resistant namespace, but an object using that profile is not a core 0.2-draft object unless the profile is explicitly negotiated. a future specification revision may define optional & required extension negotiation; implementations MUST NOT silently treat unknown fields as authorized extensions before then.
      
+
      6.4 integrity#
      
+
      objects MAY include an integrity object with a digest, canonicalization method & signature reference. a signature MUST cover the protocol version, object type, identifier, issuer, timestamps & all security-relevant fields.
      
+
      this draft does not mandate a signing suite. deployments MUST define canonical serialization & key verification before claiming cryptographically verifiable receipts or bundles.
      
+
      7. core data objects#
      
+
      the examples in this section use synthetic values & omit optional fields for readability.
      
 
      7.1 source_event#
      
-
      A source_event records evidence captured from a native source.
      
-
      Required fields:
      
+
      a source_event records evidence captured from a native source.
      
+
      required fields:
      
 
      • subject_ref
      • occurred_at or an explicit occurred_at_unknown: true
      • captured_at
      • source.adapter
      • source.native_id_ref or source.native_id_digest
      • payload_ref
      • classification
      • provenance
      
 
      {
   "spec_version": "context-layer/0.2-draft",
@@ -146,10 +146,10 @@ 
      7.1 source_event
      
-
      The event envelope SHOULD reference raw payload stored inside the vault rather than duplicate sensitive payload into every index. A capture adapter MUST preserve native signatures, event identifiers, authorization context, and deletion markers when the source protocol provides them.
      
+
      the event envelope SHOULD reference raw payload stored inside the vault rather than duplicate sensitive payload into every index. a capture adapter MUST preserve native signatures, event identifiers, authorization context & deletion markers when the source protocol provides them.
      
 
      7.2 context_claim#
      
-
      A context_claim is a typed statement supported by source events or other claims.
      
-
      Required fields:
      
+
      a context_claim is a typed statement supported by source events or other claims.
      
+
      required fields:
      
 
      • subject_ref
      • predicate
      • object
      • status
      • confidence
      • provenance_refs
      • validity
      
 
      {
   "spec_version": "context-layer/0.2-draft",
@@ -165,10 +165,10 @@ 
      7.2 context_claim7.3 context_request#
      
-
      A context_request asks the vault to release or use context.
      
-
      Required fields:
      
+
      a context_request asks the vault to release or use context.
      
+
      required fields:
      
 
      • subject_ref
      • requester
      • recipient
      • purpose_code
      • task
      • selectors
      • requested_actions
      • retention
      • receipt_requirement
      • expires_at
      
 
      {
   "spec_version": "context-layer/0.2-draft",
@@ -198,17 +198,17 @@ 
      7.3 context_request7.3.1 Purpose code registry#
      
-
      The v0.2 core registry is deliberately small:
      
-
      CodeIntended use
      draft.responseDraft a response without sending it
      summarize.materialSummarize supplied or authorized material
      retrieve.contextRetrieve approved context for a declared task
      plan.taskProduce a plan without executing side effects
      execute.approved_actionExecute an action already covered by explicit approval
      discover.minimum_revealEvaluate discovery while returning only approved fields
      propose.memory_updateSubmit a proposal for later validation and approval
      
-
      Core codes are lowercase dotted names. Deployment extensions MUST use a collision-resistant lowercase namespace beginning with x., for example x.example.review.contract. An unknown code MUST be denied unless policy lists the exact code. Implementations MUST NOT authorize a purpose by prefix matching, semantic similarity, or inference from optional purpose text.
      
+
      in request & decision receipt requirements, level & required MUST agree: none requires required: false, while decision & operation require required: true. all other pairings are invalid.
      
+
      purpose_code is the normative policy input. optional purpose text is informative & MUST NOT broaden authorization beyond the registered code. a request MUST NOT use wildcards for selectors or actions unless a separate policy explicitly permits that wildcard for the requester & subject.
      
+
      7.3.1 purpose code registry#
      
+
      the v0.2 core registry is deliberately small:
      
+
      codeintended use
      draft.responsedraft a response without sending it
      summarize.materialsummarize supplied or authorized material
      retrieve.contextretrieve approved context for a declared task
      plan.taskproduce a plan without executing side effects
      execute.approved_actionexecute an action already covered by explicit approval
      discover.minimum_revealevaluate discovery while returning only approved fields
      propose.memory_updatesubmit a proposal for later validation & approval
      
+
      core codes are lowercase dotted names. deployment extensions MUST use a collision-resistant lowercase namespace beginning with x., for example x.example.review.contract. an unknown code MUST be denied unless policy lists the exact code. implementations MUST NOT authorize a purpose by prefix matching, semantic similarity, or inference from optional purpose text.
      
 
      7.4 policy_decision#
      
-
      A policy_decision records the result of evaluating a context request.
      
-
      Required fields:
      
+
      a policy_decision records the result of evaluating a context request.
      
+
      required fields:
      
 
      • request_ref
      • decision
      • policy_snapshot
      • granted_selectors
      • denied_selectors
      • granted_actions
      • denied_actions
      • transform_requirements
      • retention
      • onward_disclosure
      • receipt_requirement
      • expires_at
      • reason_codes
      
-
      Valid decisions are:
      
+
      valid decisions are:
      
 
      • allow
      • allow_with_reductions
      • deny
      • needs_approval
      
 
      {
   "spec_version": "context-layer/0.2-draft",
@@ -236,10 +236,10 @@ 
      7.4 policy_decision7.5 scoped_context_bundle#
      
-
      A scoped_context_bundle is the only standard object through which a general context consumer receives disclosed context.
      
-
      Required fields:
      
+
      a scoped_context_bundle is the only standard object through which a general context consumer receives disclosed context.
      
+
      required fields:
      
 
      • subject_alias
      • request_ref
      • decision_ref
      • recipient
      • purpose_code
      • issued_at
      • expires_at
      • single_use with the exact value true for CL-Core-Lite
      • context
      • provenance
      • instructions
      • capabilities
      • restrictions
      • receipt_contract
      
 
      {
   "spec_version": "context-layer/0.2-draft",
@@ -284,11 +284,11 @@ 
      7.5 scoped_context_bundle
      
-
      The bundle MUST NOT contain resolvable raw-vault credentials. A provenance handle exposed to a consumer SHOULD be opaque and SHOULD require a separate authorized request to resolve. Consumers MUST stop using a bundle after expiry and SHOULD delete cached material according to the retention contract.
      
-
      Bundles SHOULD be immutable. A change in scope, context, actions, or expiry SHOULD create a new bundle with a reference to the prior bundle.
      
+
      the bundle MUST NOT contain resolvable raw-vault credentials. a provenance handle exposed to a consumer SHOULD be opaque & SHOULD require a separate authorized request to resolve. consumers MUST stop using a bundle after expiry & SHOULD delete cached material according to the retention contract.
      
+
      bundles SHOULD be immutable. a change in scope, context, actions, or expiry SHOULD create a new bundle with a reference to the prior bundle.
      
 
      7.6 minimum_reveal_response#
      
-
      A discovery proxy returns a minimum_reveal_response.
      
-
      Required fields:
      
+
      a discovery proxy returns a minimum_reveal_response.
      
+
      required fields:
      
 
      • request_ref
      • result
      • reveal
      • requires_user_approval
      • query_budget_state
      • expires_at
      
 
      {
   "spec_version": "context-layer/0.2-draft",
@@ -306,10 +306,10 @@ 
      7.6 minimum_reveal_response
      
-
      The response MUST NOT expose private match features, raw similarity scores, or negative evidence unless policy explicitly grants them. Implementations MUST rate-limit and correlate semantically similar queries, not only byte-identical requests.
      
+
      the response MUST NOT expose private match features, raw similarity scores, or negative evidence unless policy explicitly grants them. implementations MUST rate-limit & correlate semantically similar queries, not only byte-identical requests.
      
 
      7.7 memory_update_proposal#
      
-
      A memory_update_proposal carries a candidate change without granting durable truth status.
      
-
      Required fields:
      
+
      a memory_update_proposal carries a candidate change without granting durable truth status.
      
+
      required fields:
      
 
      • subject_ref
      • operation
      • proposed_claims
      • provenance_refs
      • rationale
      • submitted_by
      • status
      • approval_requirement
      • expires_at
      
 
      {
   "spec_version": "context-layer/0.2-draft",
@@ -333,11 +333,11 @@ 
      7.7 memory_update_proposal
      
-
      An implementation MUST NOT commit a proposal lacking required provenance or approval. Rejection and expiry MUST be recorded without deleting the proposal's audit history when policy requires that history.
      
+
      an implementation MUST NOT commit a proposal lacking required provenance or approval. rejection & expiry MUST be recorded without deleting the proposal's audit history when policy requires that history.
      
 
      7.8 receipt#
      
-
      A receipt records a security-relevant operation.
      
-
      Required fields:
      
-
      • operation
      • actor
      • subject_ref or a policy-approved alias
      • request_ref and/or decision_ref when applicable
      • bundle_ref when applicable
      • started_at
      • completed_at
      • outcome
      • policy_snapshot
      • input_digest
      • output_digest
      • user_summary
      
+
      a receipt records a security-relevant operation.
      
+
      required fields:
      
+
      • operation
      • actor
      • subject_ref or a policy-approved alias
      • request_ref &/or decision_ref when applicable
      • bundle_ref when applicable
      • started_at
      • completed_at
      • outcome
      • policy_snapshot
      • input_digest
      • output_digest
      • user_summary
      
 
      {
   "spec_version": "context-layer/0.2-draft",
   "type": "receipt",
@@ -359,46 +359,46 @@ 
      7.8 receipt8. Protocol lifecycles#
      
-
      8.1 Ingestion lifecycle#
      
-
      1. Authenticate or classify the native source.
      2. Capture a source event and native integrity metadata.
      3. Classify sensitivity before broad indexing.
      4. Normalize into stable event fields.
      5. Deduplicate while retaining every provenance path.
      6. Extract claims with confidence and validity.
      7. Detect contradictions and preserve branches.
      8. Store source and derived records under vault policy.
      9. Write ingestion receipts where policy requires them.
      
-
      An untrusted source MUST NOT be promoted to a trusted claim solely because a model summarized it confidently.
      
-
      8.2 Outbound context lifecycle#
      
-
      1. Authenticate the requester and bind it to a client instance where possible.
      2. Validate the request schema, expiry, purpose, recipient, and requested actions.
      3. Evaluate policy against a versioned snapshot.
      4. Obtain human approval when required.
      5. Resolve only granted selectors.
      6. Apply required redaction, aliasing, compression, and routing.
      7. Assemble and optionally sign an immutable bundle.
      8. Deliver the bundle to the named recipient.
      9. Receive operation receipts from the consumer or trusted gateway.
      10. Expire and revoke the bundle according to policy.
      
-
      Any change to recipient, purpose, action, or requested scope MUST trigger a new decision.
      
-
      8.3 Inbound discovery lifecycle#
      
-
      1. Authenticate or classify the requester.
      2. Enforce request, identity, semantic, and time-window rate limits.
      3. Validate that the query purpose is eligible for private matching.
      4. Evaluate the query inside the vault or controlled exchange zone.
      5. Apply minimum-reveal policy.
      6. Require approval before exposing a contact route or sensitive attribute.
      7. Return an expiring response.
      8. Write a receipt including query class, requester, decision, and reveal class.
      
-
      Discovery systems SHOULD add noise, thresholds, batching, or other privacy defenses when repeated aggregate results could reveal private features. This draft does not mandate one privacy-preserving matching algorithm.
      
-
      8.4 Memory writeback lifecycle#
      
-
      1. Accept a proposal, not a direct mutation, from a consumer.
      2. Validate schema and submitter authority.
      3. Require source references for factual claims unless policy marks the claim type as subjective or explicitly source-free.
      4. Compare with current claims and detect contradictions.
      5. Calculate any required confidence or trust signals.
      6. Obtain approval according to claim sensitivity and automation policy.
      7. Commit, reject, or expire the proposal.
      8. Write a receipt and preserve supersession links.
      
-
      Automatic commit MAY be enabled only for narrowly defined, low-risk proposal classes with explicit policy and rollback behavior.
      
-
      9. Policy evaluation#
      
-
      9.1 Mandatory policy inputs#
      
-
      The policy engine MUST evaluate at least:
      
-
      • Authenticated requester and client instance
      • Subject and delegated authority
      • Recipient and onward-disclosure status
      • Registered purpose_code and task class, plus optional explanatory purpose text
      • Requested selectors and sensitivity labels
      • Requested actions and side-effect class
      • Retention and bundle expiry
      • Applicable consent or approval state
      • Source trust and claim confidence where material
      • Receipt availability and required receipt level
      • Current rate limits and anomaly state
      
-
      9.2 Decision properties#
      
-
      Policy decisions MUST be deterministic with respect to their recorded inputs and policy snapshot, except for explicitly identified external signals such as risk scores. When nondeterministic or time-varying signals are used, the decision MUST record their values or stable references.
      
-
      Policies SHOULD deny by default when:
      
-
      • Requester identity cannot be verified to the required assurance level
      • purpose_code is absent, unknown, or not authorized for the requester
      • Recipient is ambiguous
      • Requested scope uses an unauthorized wildcard
      • Consent or approval is missing
      • Retention exceeds policy
      • A required receipt service is unavailable
      • The request or bundle has expired
      • An untrusted discovery requester exceeds its query budget
      
-
      9.3 Human approval#
      
-
      An approval surface MUST show, in user-readable form:
      
-
      • Who is asking
      • What context categories will be disclosed
      • Why they are requested
      • Which recipient will receive them
      • Which actions may occur
      • How long access lasts
      • Whether onward disclosure is permitted
      • What evidence will be written
      
-
      Approval identifiers MUST be single-use or bound to the exact request digest. A changed request MUST invalidate the prior approval.
      
-
      9.4 Writeback isolation#
      
-
      Consumer writeback MUST enter the authority boundary as a memory_update_proposal. A Core consumer MUST NOT receive a direct raw-vault mutation capability. Validation, contradiction handling, approval, commit, and the resulting receipt remain distinct authority-side operations. A future companion profile MAY define those authority-side operations, but it MUST preserve proposal-only submission at the consumer boundary.
      
-
      10. Optional HTTP binding#
      
-
      The Context Layer core is transport-neutral. This section defines an experimental HTTP profile using HTTP Semantics.
      
-
      10.1 Transport requirements#
      
-
      • Production endpoints MUST use HTTPS with current TLS guidance.
      • Clients and servers MUST authenticate according to the deployment's identity profile.
      • OAuth deployments SHOULD follow OAuth 2.0 Security Best Current Practice, RFC 9700.
      • Bearer tokens MUST be audience-restricted and least-privilege.
      • Credentials MUST NOT appear in URLs.
      • Mutating requests SHOULD support an Idempotency-Key header.
      • Requests MUST include Context-Layer-Version: 0.2-draft or negotiate an equivalent version.
      • Request and response bodies use application/vnd.context-layer+json for this experimental profile.
      
-
      10.2 Capability document#
      
-
      An implementation MAY expose a capability document at:
      
+
      receipts MUST NOT contain secrets, raw authorization headers, model API keys, full private prompts, or raw source payloads. the receipt contract exposes an optional nullable supersedes_ref field. a correction MUST be represented by a new receipt with supersedes_ref set to the exact receipt URN of the prior record. a non-correction receipt MAY omit supersedes_ref or set it to null.
      
+
      8. protocol lifecycles#
      
+
      8.1 ingestion lifecycle#
      
+
      1. authenticate or classify the native source.
      2. capture a source event & native integrity metadata.
      3. classify sensitivity before broad indexing.
      4. normalize into stable event fields.
      5. deduplicate while retaining every provenance path.
      6. extract claims with confidence & validity.
      7. detect contradictions & preserve branches.
      8. store source & derived records under vault policy.
      9. write ingestion receipts where policy requires them.
      
+
      an untrusted source MUST NOT be promoted to a trusted claim solely because a model summarized it confidently.
      
+
      8.2 outbound context lifecycle#
      
+
      1. authenticate the requester & bind it to a client instance where possible.
      2. validate the request schema, expiry, purpose, recipient & requested actions.
      3. evaluate policy against a versioned snapshot.
      4. obtain human approval when required.
      5. resolve only granted selectors.
      6. apply required redaction, aliasing, compression & routing.
      7. assemble & optionally sign an immutable bundle.
      8. deliver the bundle to the named recipient.
      9. receive operation receipts from the consumer or trusted gateway.
      10. expire & revoke the bundle according to policy.
      
+
      any change to recipient, purpose, action, or requested scope MUST trigger a new decision.
      
+
      8.3 inbound discovery lifecycle#
      
+
      1. authenticate or classify the requester.
      2. enforce request, identity, semantic & time-window rate limits.
      3. validate that the query purpose is eligible for private matching.
      4. evaluate the query inside the vault or controlled exchange zone.
      5. apply minimum-reveal policy.
      6. require approval before exposing a contact route or sensitive attribute.
      7. return an expiring response.
      8. write a receipt including query class, requester, decision & reveal class.
      
+
      discovery systems SHOULD add noise, thresholds, batching, or other privacy defenses when repeated aggregate results could reveal private features. this draft does not mandate one privacy-preserving matching algorithm.
      
+
      8.4 memory writeback lifecycle#
      
+
      1. accept a proposal, not a direct mutation, from a consumer.
      2. validate schema & submitter authority.
      3. require source references for factual claims unless policy marks the claim type as subjective or explicitly source-free.
      4. compare with current claims & detect contradictions.
      5. calculate any required confidence or trust signals.
      6. obtain approval according to claim sensitivity & automation policy.
      7. commit, reject, or expire the proposal.
      8. write a receipt & preserve supersession links.
      
+
      automatic commit MAY be enabled only for narrowly defined, low-risk proposal classes with explicit policy & rollback behavior.
      
+
      9. policy evaluation#
      
+
      9.1 mandatory policy inputs#
      
+
      the policy engine MUST evaluate at least:
      
+
      • authenticated requester & client instance
      • subject & delegated authority
      • recipient & onward-disclosure status
      • registered purpose_code & task class, plus optional explanatory purpose text
      • requested selectors & sensitivity labels
      • requested actions & side-effect class
      • retention & bundle expiry
      • applicable consent or approval state
      • source trust & claim confidence where material
      • receipt availability & required receipt level
      • current rate limits & anomaly state
      
+
      9.2 decision properties#
      
+
      policy decisions MUST be deterministic with respect to their recorded inputs & policy snapshot, except for explicitly identified external signals such as risk scores. when nondeterministic or time-varying signals are used, the decision MUST record their values or stable references.
      
+
      policies SHOULD deny by default when:
      
+
      • requester identity cannot be verified to the required assurance level
      • purpose_code is absent, unknown, or not authorized for the requester
      • recipient is ambiguous
      • requested scope uses an unauthorized wildcard
      • consent or approval is missing
      • retention exceeds policy
      • a required receipt service is unavailable
      • the request or bundle has expired
      • an untrusted discovery requester exceeds its query budget
      
+
      9.3 human approval#
      
+
      an approval surface MUST show, in user-readable form:
      
+
      • who is asking
      • what context categories will be disclosed
      • why they are requested
      • which recipient will receive them
      • which actions may occur
      • how long access lasts
      • whether onward disclosure is permitted
      • what evidence will be written
      
+
      approval identifiers MUST be single-use or bound to the exact request digest. a changed request MUST invalidate the prior approval.
      
+
      9.4 writeback isolation#
      
+
      consumer writeback MUST enter the authority boundary as a memory_update_proposal. a core consumer MUST NOT receive a direct raw-vault mutation capability. validation, contradiction handling, approval, commit & the resulting receipt remain distinct authority-side operations. a future companion profile MAY define those authority-side operations, but it MUST preserve proposal-only submission at the consumer boundary.
      
+
      10. optional HTTP binding#
      
+
      the context layer core is transport-neutral. this section defines an experimental HTTP profile using HTTP semantics.
      
+
      10.1 transport requirements#
      
+
      • production endpoints MUST use HTTPS with current TLS guidance.
      • clients & servers MUST authenticate according to the deployment's identity profile.
      • OAuth deployments SHOULD follow OAuth 2.0 security best current practice, RFC 9700.
      • bearer tokens MUST be audience-restricted & least-privilege.
      • credentials MUST NOT appear in URLs.
      • mutating requests SHOULD support an Idempotency-Key header.
      • requests MUST include Context-Layer-Version: 0.2-draft or negotiate an equivalent version.
      • request & response bodies use application/vnd.context-layer+json for this experimental profile.
      
+
      10.2 capability document#
      
+
      an implementation MAY expose a capability document at:
      
 
      GET /.well-known/context-layer
      
-
      This path is an unregistered draft convention. The response should list protocol versions, roles, endpoint URLs, supported object types, auth metadata, extensions, receipt capabilities, maximum bundle lifetime, and conformance report location.
      
-
      10.3 Suggested resource endpoints#
      
-
      Method and pathPurpose
      POST /context/v1/requestsSubmit a context request
      GET /context/v1/requests/{id}Read request status as an authorized principal
      POST /context/v1/requests/{id}/decisionsRecord a policy or approval decision; restricted to trusted decision roles
      GET /context/v1/bundles/{id}Retrieve an authorized bundle, preferably once or with strong replay controls
      POST /context/v1/bundles/{id}/receiptsSubmit a consumer operation receipt
      POST /context/v1/discoverySubmit a discovery request
      POST /context/v1/memory-proposalsSubmit a proposed memory update
      GET /context/v1/receipts/{id}Retrieve a receipt subject to receipt privacy policy
      
-
      These paths are a draft binding, not globally registered endpoints.
      
-
      The following minimal OpenAPI 3.1 fragment is informative. It illustrates schema reuse without defining authentication or deployment-specific error policy:
      
+
      this path is an unregistered draft convention. the response should list protocol versions, roles, endpoint URLs, supported object types, auth metadata, extensions, receipt capabilities, maximum bundle lifetime & conformance report location.
      
+
      10.3 suggested resource endpoints#
      
+
      method & pathpurpose
      POST /context/v1/requestssubmit a context request
      GET /context/v1/requests/{id}read request status as an authorized principal
      POST /context/v1/requests/{id}/decisionsrecord a policy or approval decision; restricted to trusted decision roles
      GET /context/v1/bundles/{id}retrieve an authorized bundle, preferably once or with strong replay controls
      POST /context/v1/bundles/{id}/receiptssubmit a consumer operation receipt
      POST /context/v1/discoverysubmit a discovery request
      POST /context/v1/memory-proposalssubmit a proposed memory update
      GET /context/v1/receipts/{id}retrieve a receipt subject to receipt privacy policy
      
+
      these paths are a draft binding, not globally registered endpoints.
      
+
      the following minimal OpenAPI 3.1 fragment is informative. it illustrates schema reuse without defining authentication or deployment-specific error policy:
      
 
      openapi: 3.1.0
 info:
   title: Context Layer Core Lite
@@ -420,10 +420,10 @@ 
      10.3 Suggested resource endpoints
      
-
      10.4 Status and error behavior#
      
-
      Recommended HTTP statuses:
      
+
      10.4 status & error behavior#
      
+
      recommended HTTP statuses:
      
 
      • 200 OK: synchronous successful read or decision result
      • 201 Created: request, bundle, proposal, or receipt created
      • 202 Accepted: asynchronous evaluation or approval pending
      • 400 Bad Request: invalid syntax or schema
      • 401 Unauthorized: authentication absent or invalid
      • 403 Forbidden: authenticated principal lacks permission
      • 404 Not Found: unknown object or intentionally concealed existence
      • 409 Conflict: idempotency conflict, stale policy, or contradictory state transition
      • 410 Gone: expired or revoked bundle
      • 413 Content Too Large: payload exceeds limits
      • 415 Unsupported Media Type: unsupported representation
      • 422 Unprocessable Content: valid syntax with invalid protocol semantics
      • 429 Too Many Requests: rate or query budget exceeded
      • 503 Service Unavailable: required policy, approval, vault, or receipt component unavailable
      
-
      Error bodies MUST use a stable machine code and a safe user message. They MUST NOT expose policy internals, private match features, secrets, stack traces, or raw upstream responses.
      
+
      error bodies MUST use a stable machine code & a safe user message. they MUST NOT expose policy internals, private match features, secrets, stack traces, or raw upstream responses.
      
 
      {
   "spec_version": "context-layer/0.2-draft",
   "type": "error",
@@ -435,98 +435,98 @@ 
      10.4 Status and error behavior10.5 CL-Core-Lite profile#
      
-
      CL-Core-Lite is the smallest v0.2 implementation profile intended for interoperable experiments. A conforming implementation MUST:
      
-
      • Validate the v0.2 context_request, policy_decision, scoped_context_bundle, memory_update_proposal, and receipt contracts
      • Support allow, allow_with_reductions, deny, and needs_approval
      • Authorize the exact registered or explicitly extended purpose_code; optional purpose text is never an authorization input
      • Require every scoped bundle to carry a finite expires_at and single_use: true, and reject expired or replayed bundles
      • Bind every decision to the exact policy snapshot and every bundle to its request, decision, and recipient
      • Keep raw vault objects and resolvable vault credentials outside consumer bundles
      • Accept consumer memory writeback only as a proposal
      • Produce the receipts required by the request and decision before reporting success
      
-
      Lite conformance does not imply production security, adoption as a standard, or conformance with the optional discovery, adapter, signature, or network deployment profiles.
      
-
      11. Security and privacy requirements#
      
-
      11.1 Authentication and authorization#
      
-
      Authentication proves a principal; policy authorizes a context use. Implementations MUST keep those decisions distinct.
      
-
      • Every network requester MUST be authenticated or explicitly assigned an untrusted_anonymous class.
      • Tokens MUST be validated for issuer, audience, expiry, and required scope.
      • A service MUST NOT pass a client token through to an unrelated downstream service.
      • Local HTTP servers SHOULD bind to loopback and require a per-launch authorization token or equivalent process boundary.
      • Browser endpoints MUST validate origin and CSRF defenses where credentials or session creation are involved.
      • Static public assets MUST be separated from credential-bearing session endpoints in production.
      
-
      11.2 Secret handling#
      
-
      • Long-lived provider credentials MUST remain server-side or in platform-appropriate secure storage.
      • Credentials MUST NOT be embedded in bundles, receipts, HTML, mobile binaries, source-control archives, logs, prompts, or query strings.
      • Client-facing realtime or model sessions SHOULD use short-lived, narrowly scoped client credentials when the provider supports them.
      • Credential rotation and revocation MUST be operationally documented.
      
-
      11.3 Data minimization#
      
-
      • Source payloads SHOULD remain inside the vault.
      • Bundles MUST contain only fields granted by the decision.
      • Provenance exposed outside the vault SHOULD use opaque handles.
      • Logs and metrics MUST avoid raw context unless separately authorized.
      • Receipts SHOULD use digests and categories rather than duplicate sensitive content.
      
-
      11.4 Prompt and content injection#
      
-
      Captured content is untrusted data, even when it came from a known account. Implementations MUST prevent source content from becoming executable agent instructions merely because it appears in retrieved context.
      
-
      Bundles SHOULD separate:
      
-
      • Facts and source quotations
      • System or policy instructions
      • User instructions
      • Tool manifests
      • Untrusted content
      
-
      Consumers MUST NOT allow a source document to expand its own permissions, tools, retention, or recipient list.
      
-
      11.5 Semantic transformation risk#
      
-
      Redaction and summarization can fail. High-risk deployments SHOULD combine deterministic field-level policy with semantic transforms and MUST test for under-redaction, indirect identifiers, reconstruction, and context leakage.
      
-
      The semantic proxy SHOULD report which transformations ran and their confidence. A policy MAY require human review when a transform cannot establish sufficient confidence.
      
-
      11.6 Discovery inference#
      
-
      Rate limiting by requester IP alone is insufficient. Discovery implementations SHOULD account for requester identity, semantic similarity, target subject, result pattern, time window, and coordinated clients.
      
-
      Negative responses can reveal information. Deployments MAY return uniform responses, add delay, batch approvals, or use privacy-preserving matching techniques according to threat model.
      
-
      11.7 Revocation and deletion#
      
-
      Bundle revocation cannot guarantee deletion by an already-compromised recipient. Implementations MUST state this limitation. Revocation MUST prevent future authorized retrieval and use within conforming components.
      
-
      Source deletion MUST propagate according to legal, user, and provenance requirements. Receipts MAY need to retain non-content evidence after source deletion, but such retention MUST be explicit and minimized.
      
-
      11.8 Receipt privacy#
      
-
      Receipts create a second sensitive dataset. They can reveal relationships, timing, tools, models, and behavior even when payloads are omitted. Receipt access MUST have independent policy, retention, export, and deletion rules.
      
-
      11.9 Availability and fail-closed behavior#
      
-
      When the policy engine, approval surface, key verifier, or required receipt store is unavailable before an operation, sensitive disclosure MUST fail closed. Implementations MAY permit explicitly defined low-risk offline operations using a cached, unexpired policy snapshot.
      
-
      If an irreversible external side effect succeeds but its completion receipt cannot be stored, the implementation MUST report the result as indeterminate, retry the receipt idempotently, and block dependent actions. It MUST NOT claim that the external side effect was rolled back merely because receipt persistence failed.
      
-
      12. Interoperability rules#
      
-
      Adapters MUST:
      
-
      • Declare the native protocol and adapter version
      • Preserve native identifiers or collision-resistant digests
      • Preserve original and capture timestamps
      • Preserve signatures, verification status, deletion markers, and authorization context when available
      • Map source trust and visibility explicitly
      • Avoid converting untrusted content into trusted instructions
      • Document lossy transformations
      • Support deterministic export fixtures for conformance testing
      
-
      Consumers MUST:
      
-
      • Validate bundle version, issuer, recipient, expiry, and integrity before use
      • Enforce capability and action allowlists
      • Treat missing permissions as denied
      • Isolate untrusted context from control instructions
      • Produce required receipts
      • Delete or make inaccessible expired context according to the retention contract
      • Submit proposed memory updates through the protocol rather than direct vault writes
      
-
      See Implementation and Interoperability Profiles for protocol-specific mappings.
      
-
      13. Conformance profiles#
      
-
      An implementation may claim one or more roles.
      
+
      CL-Core-Lite is the smallest v0.2 implementation profile intended for interoperable experiments. a conforming implementation MUST:
      
+
      • validate the v0.2 context_request, policy_decision, scoped_context_bundle, memory_update_proposal & receipt contracts
      • support allow, allow_with_reductions, deny & needs_approval
      • authorize the exact registered or explicitly extended purpose_code; optional purpose text is never an authorization input
      • require every scoped bundle to carry a finite expires_at & single_use: true & reject expired or replayed bundles
      • bind every decision to the exact policy snapshot & every bundle to its request, decision & recipient
      • keep raw vault objects & resolvable vault credentials outside consumer bundles
      • accept consumer memory writeback only as a proposal
      • produce the receipts required by the request & decision before reporting success
      
+
      lite conformance does not imply production security, adoption as a standard, or conformance with the optional discovery, adapter, signature, or network deployment profiles.
      
+
      11. security & privacy requirements#
      
+
      11.1 authentication & authorization#
      
+
      authentication proves a principal; policy authorizes a context use. implementations MUST keep those decisions distinct.
      
+
      • every network requester MUST be authenticated or explicitly assigned an untrusted_anonymous class.
      • tokens MUST be validated for issuer, audience, expiry & required scope.
      • a service MUST NOT pass a client token through to an unrelated downstream service.
      • local HTTP servers SHOULD bind to loopback & require a per-launch authorization token or equivalent process boundary.
      • browser endpoints MUST validate origin & CSRF defenses where credentials or session creation are involved.
      • static public assets MUST be separated from credential-bearing session endpoints in production.
      
+
      11.2 secret handling#
      
+
      • long-lived provider credentials MUST remain server-side or in platform-appropriate secure storage.
      • credentials MUST NOT be embedded in bundles, receipts, HTML, mobile binaries, source-control archives, logs, prompts, or query strings.
      • client-facing realtime or model sessions SHOULD use short-lived, narrowly scoped client credentials when the provider supports them.
      • credential rotation & revocation MUST be operationally documented.
      
+
      11.3 data minimization#
      
+
      • source payloads SHOULD remain inside the vault.
      • bundles MUST contain only fields granted by the decision.
      • provenance exposed outside the vault SHOULD use opaque handles.
      • logs & metrics MUST avoid raw context unless separately authorized.
      • receipts SHOULD use digests & categories rather than duplicate sensitive content.
      
+
      11.4 prompt & content injection#
      
+
      captured content is untrusted data, even when it came from a known account. implementations MUST prevent source content from becoming executable agent instructions merely because it appears in retrieved context.
      
+
      bundles SHOULD separate:
      
+
      • facts & source quotations
      • system or policy instructions
      • user instructions
      • tool manifests
      • untrusted content
      
+
      consumers MUST NOT allow a source document to expand its own permissions, tools, retention, or recipient list.
      
+
      11.5 semantic transformation risk#
      
+
      redaction & summarization can fail. high-risk deployments SHOULD combine deterministic field-level policy with semantic transforms & MUST test for under-redaction, indirect identifiers, reconstruction & context leakage.
      
+
      the semantic proxy SHOULD report which transformations ran & their confidence. a policy MAY require human review when a transform cannot establish sufficient confidence.
      
+
      11.6 discovery inference#
      
+
      rate limiting by requester IP alone is insufficient. discovery implementations SHOULD account for requester identity, semantic similarity, target subject, result pattern, time window & coordinated clients.
      
+
      negative responses can reveal information. deployments MAY return uniform responses, add delay, batch approvals, or use privacy-preserving matching techniques according to threat model.
      
+
      11.7 revocation & deletion#
      
+
      bundle revocation cannot guarantee deletion by an already-compromised recipient. implementations MUST state this limitation. revocation MUST prevent future authorized retrieval & use within conforming components.
      
+
      source deletion MUST propagate according to legal, user & provenance requirements. receipts MAY need to retain non-content evidence after source deletion, but such retention MUST be explicit & minimized.
      
+
      11.8 receipt privacy#
      
+
      receipts create a second sensitive dataset. they can reveal relationships, timing, tools, models & behavior even when payloads are omitted. receipt access MUST have independent policy, retention, export & deletion rules.
      
+
      11.9 availability & fail-closed behavior#
      
+
      when the policy engine, approval surface, key verifier, or required receipt store is unavailable before an operation, sensitive disclosure MUST fail closed. implementations MAY permit explicitly defined low-risk offline operations using a cached, unexpired policy snapshot.
      
+
      if an irreversible external side effect succeeds but its completion receipt cannot be stored, the implementation MUST report the result as indeterminate, retry the receipt idempotently & block dependent actions. it MUST NOT claim that the external side effect was rolled back merely because receipt persistence failed.
      
+
      12. interoperability rules#
      
+
      adapters MUST:
      
+
      • declare the native protocol & adapter version
      • preserve native identifiers or collision-resistant digests
      • preserve original & capture timestamps
      • preserve signatures, verification status, deletion markers & authorization context when available
      • map source trust & visibility explicitly
      • avoid converting untrusted content into trusted instructions
      • document lossy transformations
      • support deterministic export fixtures for conformance testing
      
+
      consumers MUST:
      
+
      • validate bundle version, issuer, recipient, expiry & integrity before use
      • enforce capability & action allowlists
      • treat missing permissions as denied
      • isolate untrusted context from control instructions
      • produce required receipts
      • delete or make inaccessible expired context according to the retention contract
      • submit proposed memory updates through the protocol rather than direct vault writes
      
+
      see implementation & interoperability profiles for protocol-specific mappings.
      
+
      13. conformance profiles#
      
+
      an implementation may claim one or more roles.
      
 
      13.1 CL-Core-Issuer#
      
-
      Must implement:
      
-
      • context_request validation
      • Versioned policy_decision
      • Scope reduction
      • scoped_context_bundle issuance
      • Expiry and recipient binding
      • Required receipt contract
      • Raw-vault isolation tests
      
+
      must implement:
      
+
      • context_request validation
      • versioned policy_decision
      • scope reduction
      • scoped_context_bundle issuance
      • expiry & recipient binding
      • required receipt contract
      • raw-vault isolation tests
      
 
      13.2 CL-Core-Consumer#
      
-
      Must implement:
      
-
      • Bundle validation
      • Capability and restriction enforcement
      • Expiry handling
      • Required receipts
      • Proposal-only memory writeback
      • Context deletion or inaccessibility after expiry
      
+
      must implement:
      
+
      • bundle validation
      • capability & restriction enforcement
      • expiry handling
      • required receipts
      • proposal-only memory writeback
      • context deletion or inaccessibility after expiry
      
 
      13.3 CL-Discovery#
      
-
      Must implement:
      
-
      • Authenticated or explicitly classified discovery requests
      • Query budgets and semantic probe correlation
      • Private evaluation
      • Minimum-reveal responses
      • Approval escalation
      • Discovery receipts
      
+
      must implement:
      
+
      • authenticated or explicitly classified discovery requests
      • query budgets & semantic probe correlation
      • private evaluation
      • minimum-reveal responses
      • approval escalation
      • discovery receipts
      
 
      13.4 CL-Memory#
      
-
      Must implement:
      
-
      • Source events and derived claims
      • Provenance continuity
      • Contradiction and supersession handling
      • Memory update proposals
      • Approval and commit receipts
      
+
      must implement:
      
+
      • source events & derived claims
      • provenance continuity
      • contradiction & supersession handling
      • memory update proposals
      • approval & commit receipts
      
 
      13.5 CL-Receipt-Store#
      
-
      Must implement:
      
-
      • Logical append-only semantics
      • Correction by supersession
      • Integrity and ordering strategy
      • Independent receipt access policy
      • Secret and payload minimization
      • Export and verification tooling
      
+
      must implement:
      
+
      • logical append-only semantics
      • correction by supersession
      • integrity & ordering strategy
      • independent receipt access policy
      • secret & payload minimization
      • export & verification tooling
      
 
      13.6 CL-Adapter#
      
-
      Must document:
      
-
      • Native protocol and version
      • Inbound and outbound mapping
      • Authentication boundary
      • Lossy fields
      • Trust and visibility mapping
      • Deletion and edit behavior
      • Test fixtures
      
-
      14. Required conformance tests#
      
-
      Every claimed role MUST publish machine-readable test results for applicable cases.
      
-
      Minimum tests include:
      
-
      1. Reject an expired request.
      2. Reject a bundle addressed to another recipient.
      3. Reduce a request containing one allowed and one denied selector.
      4. Prove that denied source payload text is absent from the serialized bundle.
      5. Preserve provenance for each disclosed derived claim.
      6. Reject an unauthorized action even when an instruction string asks for it.
      7. Fail closed when a required receipt path is unavailable before execution; report and recover an indeterminate outcome when an irreversible action succeeds but completion-receipt persistence fails.
      8. Reject replay of a single-use bundle.
      9. Keep a memory update as pending when required provenance is missing.
      10. Preserve contradictory claims rather than overwrite them silently.
      11. Rate-limit semantically equivalent discovery probes.
      12. Ensure errors and receipts contain no credentials or raw private payloads.
      13. Round-trip each adapter fixture without losing documented security-relevant fields.
      14. Verify that logs do not contain access tokens, API keys, or raw vault objects.
      
-
      A test that merely confirms valid JSON is insufficient evidence of policy or privacy conformance.
      
-
      15. Versioning#
      
-
      Objects carry an explicit spec_version. Implementations MUST reject unsupported major versions. A compatible minor version MUST NOT change the meaning of existing required fields or weaken an invariant.
      
-
      Draft identifiers are unstable. Production data SHOULD NOT be committed to 0.2-draft schemas without a migration plan.
      
-
      Schema evolution rules:
      
-
      • Additive optional fields MAY be introduced in a compatible minor version.
      • Required fields MUST NOT be added without a new major version or negotiated required extension.
      • Enum values MAY be added only where consumers are required to handle unknown values safely.
      • Security-sensitive default changes require a major version.
      • Deprecation MUST include an alternative and a migration window.
      
-
      16. Implementation status of this repository#
      
-
      As of 2026-08-21, the public project provides:
      
-
      • Five v0.2 JSON schemas for requests, decisions, bundles, memory proposals, and receipts
      • A dependency-free reference module with deterministic reduction, validation, transforms, and minimized receipts
      • An experimental single-user local core with an AES-256-GCM vault, four-state policy evaluation, HMAC-authenticated bundle envelopes, and an authenticated append-only receipt log
      • One narrow UTF-8 files adapter and one local-agent consumer as conformance evidence
      • Synthetic positive and negative fixtures, a minimized demo, and SHA-bound test vectors
      • A reviewed v0.2 technical specification and informative implementation profiles
      • An unsubmitted Nostr interoperability discussion draft
      
-
      It does not currently provide:
      
-
      • A production context vault
      • A production policy engine or approval service
      • A portable third-party signature suite, managed key custody, or hostile-administrator protection
      • Production source adapters or consumer integrations for the listed external protocols
      • An independent conformance program or security certification
      • A hardened multi-user network service
      • A completed iOS client
      
-
      The local HMAC envelope and receipt anchor demonstrate integrity inside the tested single-user profile; they are not portable signatures or a hardware-rooted audit system. The files adapter, local consumer, and HTML demo use synthetic data and MUST NOT be treated as production integrations.
      
-
      17. Open design questions#
      
-
      The next specification revision needs decisions on:
      
-
      • Canonical JSON and signature suite
      • Identifier and pseudonym rotation strategy
      • Standard sensitivity and purpose vocabularies
      • Policy language and delegation model
      • Receipt ordering, transparency, and selective disclosure
      • Bundle revocation and consumer attestation
      • Privacy-preserving discovery algorithms and leakage budgets
      • Portable encrypted provenance references
      • Cross-device vault sync and recovery
      • Deletion propagation across derived claims and receipts
      • User-readable consent and receipt UX requirements
      • Registration of media types and well-known metadata
      • Governance, change control, and an independent conformance process
      
-
      18. Normative and informative references#
      
-
      18.1 Normative foundations for this draft#
      
-
-
      18.2 Informative interoperability references#
      
-
      +

      must document:

      +
      • native protocol & version
      • inbound & outbound mapping
      • authentication boundary
      • lossy fields
      • trust & visibility mapping
      • deletion & edit behavior
      • test fixtures
      +

      14. required conformance tests#

      +

      every claimed role MUST publish machine-readable test results for applicable cases.

      +

      minimum tests include:

      +
      1. reject an expired request.
      2. reject a bundle addressed to another recipient.
      3. reduce a request containing one allowed & one denied selector.
      4. prove that denied source payload text is absent from the serialized bundle.
      5. preserve provenance for each disclosed derived claim.
      6. reject an unauthorized action even when an instruction string asks for it.
      7. fail closed when a required receipt path is unavailable before execution; report & recover an indeterminate outcome when an irreversible action succeeds but completion-receipt persistence fails.
      8. reject replay of a single-use bundle.
      9. keep a memory update as pending when required provenance is missing.
      10. preserve contradictory claims rather than overwrite them silently.
      11. rate-limit semantically equivalent discovery probes.
      12. ensure errors & receipts contain no credentials or raw private payloads.
      13. round-trip each adapter fixture without losing documented security-relevant fields.
      14. verify that logs do not contain access tokens, API keys, or raw vault objects.
      +

      a test that merely confirms valid JSON is insufficient evidence of policy or privacy conformance.

      +

      15. versioning#

      +

      objects carry an explicit spec_version. implementations MUST reject unsupported major versions. a compatible minor version MUST NOT change the meaning of existing required fields or weaken an invariant.

      +

      draft identifiers are unstable. production data SHOULD NOT be committed to 0.2-draft schemas without a migration plan.

      +

      schema evolution rules:

      +
      • additive optional fields MAY be introduced in a compatible minor version.
      • required fields MUST NOT be added without a new major version or negotiated required extension.
      • enum values MAY be added only where consumers are required to handle unknown values safely.
      • security-sensitive default changes require a major version.
      • deprecation MUST include an alternative & a migration window.
      +

      16. implementation status of this repository#

      +

      as of 2026-08-21, the public project provides:

      +
      • five v0.2 JSON schemas for requests, decisions, bundles, memory proposals & receipts
      • a dependency-free reference module with deterministic reduction, validation, transforms & minimized receipts
      • an experimental single-user local core with an AES-256-GCM vault, four-state policy evaluation, HMAC-authenticated bundle envelopes & an authenticated append-only receipt log
      • one narrow UTF-8 files adapter & one local-agent consumer as conformance evidence
      • synthetic positive & negative fixtures, a minimized demo & SHA-bound test vectors
      • a reviewed v0.2 technical specification & informative implementation profiles
      • an unsubmitted Nostr interoperability discussion draft
      +

      it does not currently provide:

      +
      • a production context vault
      • a production policy engine or approval service
      • a portable third-party signature suite, managed key custody, or hostile-administrator protection
      • production source adapters or consumer integrations for the listed external protocols
      • an independent conformance program or security certification
      • a hardened multi-user network service
      • a completed iOS client
      +

      the local HMAC envelope & receipt anchor demonstrate integrity inside the tested single-user profile; they are not portable signatures or a hardware-rooted audit system. the files adapter, local consumer & HTML demo use synthetic data & MUST NOT be treated as production integrations.

      +

      17. open design questions#

      +

      the next specification revision needs decisions on:

      +
      • canonical JSON & signature suite
      • identifier & pseudonym rotation strategy
      • standard sensitivity & purpose vocabularies
      • policy language & delegation model
      • receipt ordering, transparency & selective disclosure
      • bundle revocation & consumer attestation
      • privacy-preserving discovery algorithms & leakage budgets
      • portable encrypted provenance references
      • cross-device vault sync & recovery
      • deletion propagation across derived claims & receipts
      • user-readable consent & receipt UX requirements
      • registration of media types & well-known metadata
      • governance, change control & an independent conformance process
      +

      18. normative & informative references#

      +

      18.1 normative foundations for this draft#

      + +

      18.2 informative interoperability references#

      +
      -

      Context Layer / public working proposal

      +

      context layer / public working proposal

      sierra catalina / 2026

      diff --git a/site/context-layer/assets/context-layer-editorial.mjs b/site/context-layer/assets/context-layer-editorial.mjs new file mode 100644 index 0000000..f69006d --- /dev/null +++ b/site/context-layer/assets/context-layer-editorial.mjs @@ -0,0 +1,275 @@ +const canonicalIdentifiers = new Map([ + ["a2a", "A2A"], + ["aes", "AES"], + ["ai", "AI"], + ["api", "API"], + ["apis", "APIs"], + ["activitypub", "ActivityPub"], + ["activitystreams", "ActivityStreams"], + ["agent2agent", "Agent2Agent"], + ["anthropic", "Anthropic"], + ["cl-adapter", "CL-Adapter"], + ["cl-core-consumer", "CL-Core-Consumer"], + ["cl-core-issuer", "CL-Core-Issuer"], + ["cl-core-lite", "CL-Core-Lite"], + ["cl-discovery", "CL-Discovery"], + ["cl-memory", "CL-Memory"], + ["cl-receipt-store", "CL-Receipt-Store"], + ["css", "CSS"], + ["dags", "DAGs"], + ["datapart", "DataPart"], + ["dom", "DOM"], + ["dpop", "DPoP"], + ["gcm", "GCM"], + ["github", "GitHub"], + ["gmail", "Gmail"], + ["graphql", "GraphQL"], + ["html", "HTML"], + ["http", "HTTP"], + ["https", "HTTPS"], + ["ipfs", "IPFS"], + ["ios", "iOS"], + ["json", "JSON"], + ["jwt", "JWT"], + ["friday", "Friday"], + ["macos", "macOS"], + ["markdown", "Markdown"], + ["message-id", "Message-ID"], + ["mcp", "MCP"], + ["oauth", "OAuth"], + ["nostr", "Nostr"], + ["openai", "OpenAI"], + ["openid", "OpenID"], + ["openapi", "OpenAPI"], + ["postgresql", "PostgreSQL"], + ["thursday", "Thursday"], + ["rfc", "RFC"], + ["sqlite", "SQLite"], + ["swiftui", "SwiftUI"], + ["tls", "TLS"], + ["ui", "UI"], + ["uri", "URI"], + ["uris", "URIs"], + ["url", "URL"], + ["urls", "URLs"], + ["utf", "UTF"], + ["uuid", "UUID"], + ["uuids", "UUIDs"], + ["w3c", "W3C"], + ["webauthn", "WebAuthn"], + ["webrtc", "WebRTC"], + ["websocket", "WebSocket"], +]); + +const caseSensitiveIdentifiers = [ + "Bluetooth", + "Codex", + "Goose", + "Harbor", + "Linux", + "Matrix", + "Nostr", + "North", + "Planner", + "Postgres", + "React", + "Rekor", + "Saturday", + "Signal", + "Sigstore", + "Solid", + "Station", + "Unix", + "Windows", +]; + +const canonicalPhrases = new Map([ + ["harbor city", "Harbor City"], + ["harbor planner", "Harbor Planner"], + ["harbor street", "Harbor Street"], + ["north station", "North Station"], +]); + +const caseSensitiveTechnicalIdentifiers = [ + "AR", + "AT", + "BCP", + "CID", + "CSRF", + "DID", + "DIDs", + "HMAC", + "IANA", + "ID", + "IDs", + "IP", + "IPC", + "LE", + "MAY", + "MIME", + "MUST", + "NIP", + "NOT", + "NSID", + "OPTIONAL", + "OS", + "POST", + "PROV", + "PT2H", + "RECOMMENDED", + "REQUIRED", + "REST", + "SHA", + "SHALL", + "SHOULD", + "SVG", + "URN", + "US", + "UTC", + "UX", + "XRPC", + "XChaCha20-Poly1305", +]; + +export const editorialCaseExceptions = Object.freeze([ + "I", + ...new Set([ + ...canonicalIdentifiers.values(), + ...[...canonicalPhrases.values()].flatMap((phrase) => phrase.split(" ")), + ...caseSensitiveIdentifiers, + ...caseSensitiveTechnicalIdentifiers, + ]), +]); + +/** + * Apply Sierra's reader-facing editorial casing without altering technical + * identifiers. Pass { html: true } when the return value will be written into + * an HTML text node so the ampersand is encoded exactly once. Generated prose + * that was already asked to use lowercase ordinary casing can opt into + * preserveUnknownCase so unfamiliar proper names and acronyms survive. + */ +export function formatEditorialText( + value, + { html = false, preserveUnknownCase = false } = {}, +) { + if (typeof value !== "string" || value.length === 0) return value; + + const protectedValues = []; + const protect = (match) => { + const token = `\uE000${protectedValues.length}\uE001`; + protectedValues.push(match); + return token; + }; + + const ampersand = html ? "&" : "&"; + let text = protectMarkdownCode(value, protect) + .replace(/\b(?:https?:\/\/|www\.)[^\s<>"']+/gi, protect) + .replace(/\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b/gi, protect) + .replace(/\band\b/gi, ampersand); + + for (const [phrase, canonical] of canonicalPhrases) { + text = text.replace(new RegExp(`\\b${escapeRegExp(phrase)}\\b`, "gi"), () => protect(canonical)); + } + + text = text + .replace(/\bmatrix(?=\s+(?:defines|events?|rooms?|specification))\b/gi, () => protect("Matrix")) + .replace(/\bmatrix(?=,\s*ActivityPub\b)/gi, () => protect("Matrix")); + + for (const [identifier, canonical] of canonicalIdentifiers) { + text = text.replace( + new RegExp(`\\b${escapeRegExp(identifier)}\\b`, "gi"), + () => protect(canonical), + ); + } + + for (const identifier of [...caseSensitiveIdentifiers, ...caseSensitiveTechnicalIdentifiers]) { + text = text.replace(new RegExp(`\\b${escapeRegExp(identifier)}\\b`, "g"), protect); + } + + if (preserveUnknownCase) { + text = text.replace( + /\p{L}[\p{L}\p{M}'’\u2010-\u2015-]*/gu, + (word) => (/\p{Lu}/u.test(word) ? protect(word) : word), + ); + } + + text = text.replace(/\bat protocol\b/gi, () => `${protect("AT")} protocol`); + text = text + .replace(/\b[a-z]+(?:[A-Z][A-Za-z0-9]*)+\b/g, protect) + .replace( + /\b(?=[A-Za-z0-9]*[a-z])(?=(?:[A-Za-z0-9]*[A-Z]){2})[A-Z][A-Za-z0-9]*\b/g, + protect, + ) + .replace(/\bI\b/g, protect); + + text = text + .replace(/,\s+(?=&(?:amp;)?)/g, " ") + .toLowerCase(); + + return text.replace( + /\uE000(\d+)\uE001/g, + (_, index) => protectedValues[Number(index)], + ); +} + +function escapeRegExp(value) { + return value.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"); +} + +function protectMarkdownCode(value, protect) { + let result = ""; + let cursor = 0; + let index = 0; + + while (index < value.length) { + if (index === 0 || value[index - 1] === "\n") { + const opening = value.slice(index).match(/^( {0,3})(`{3,}|~{3,})([^\r\n]*)(?:\r?\n|$)/); + if (opening && !(opening[2][0] === "`" && opening[3].includes("`"))) { + const marker = opening[2]; + const closingFence = new RegExp( + `^ {0,3}${escapeRegExp(marker[0])}{${marker.length},}[\\t ]*(?:\\r?\\n|$)`, + "gm", + ); + closingFence.lastIndex = index + opening[0].length; + const closing = closingFence.exec(value); + const end = closing ? closingFence.lastIndex : value.length; + result += value.slice(cursor, index); + result += protect(value.slice(index, end)); + cursor = end; + index = end; + continue; + } + } + + if (value[index] !== "`") { + index += 1; + continue; + } + + const openingStart = index; + while (value[index] === "`") index += 1; + const delimiterLength = index - openingStart; + let searchIndex = index; + let closingEnd = -1; + + while (searchIndex < value.length) { + const closingStart = value.indexOf("`", searchIndex); + if (closingStart === -1) break; + let runEnd = closingStart; + while (value[runEnd] === "`") runEnd += 1; + if (runEnd - closingStart === delimiterLength) { + closingEnd = runEnd; + break; + } + searchIndex = runEnd; + } + + if (closingEnd === -1) continue; + result += value.slice(cursor, openingStart); + result += protect(value.slice(openingStart, closingEnd)); + cursor = closingEnd; + index = closingEnd; + } + + return result + value.slice(cursor); +} diff --git a/site/context-layer/assets/context-layer-native.js b/site/context-layer/assets/context-layer-native.js index 0795d1e..5e86312 100644 --- a/site/context-layer/assets/context-layer-native.js +++ b/site/context-layer/assets/context-layer-native.js @@ -82,7 +82,7 @@ function enhanceCodeCanvas(pre, index) { button.className = 'code-canvas__copy'; button.type = 'button'; button.textContent = 'copy'; - button.setAttribute('aria-label', `Copy code snippet ${index + 1} to clipboard`); + button.setAttribute('aria-label', `copy code snippet ${index + 1} to clipboard`); let resetTimer; let isCopying = false; diff --git a/site/context-layer/demo/assets/context-layer.css b/site/context-layer/demo/assets/context-layer.css index 7f2e59c..9cc4835 100644 --- a/site/context-layer/demo/assets/context-layer.css +++ b/site/context-layer/demo/assets/context-layer.css @@ -1034,7 +1034,6 @@ a { color: var(--brass-strong); font-family: var(--mono); font-size: 10px; - text-transform: uppercase; } .guide-transcript .is-user strong { diff --git a/site/context-layer/demo/assets/context-layer.js b/site/context-layer/demo/assets/context-layer.js index ae13fd4..4775269 100644 --- a/site/context-layer/demo/assets/context-layer.js +++ b/site/context-layer/demo/assets/context-layer.js @@ -1,3 +1,5 @@ +import { formatEditorialText } from "../../assets/context-layer-editorial.mjs"; + const demoStages = [ { kicker: "Context request", @@ -339,6 +341,8 @@ let heroTimer = null; const qs = (selector, root = document) => root.querySelector(selector); const qsa = (selector, root = document) => [...root.querySelectorAll(selector)]; +const editorial = (value) => formatEditorialText(String(value)); +const editorialGenerated = (value) => formatEditorialText(String(value), { preserveUnknownCase: true }); function setHeroStage(index) { qsa("[data-hero-stage]").forEach((item, itemIndex) => { @@ -370,9 +374,9 @@ function fieldList(target, fields) { const item = document.createElement("li"); item.dataset.state = state; const value = document.createElement("span"); - value.textContent = label; + value.textContent = editorial(label); const status = document.createElement("small"); - status.textContent = state; + status.textContent = editorial(state); item.append(value, status); return item; })); @@ -382,24 +386,24 @@ function setDemoStage(index, announce = true) { currentStage = Math.max(0, Math.min(index, demoStages.length - 1)); const stage = demoStages[currentStage]; - qs("[data-stage-kicker]").textContent = stage.kicker; - qs("[data-stage-title]").textContent = stage.title; - qs("[data-stage-summary]").textContent = stage.summary; + qs("[data-stage-kicker]").textContent = editorial(stage.kicker); + qs("[data-stage-title]").textContent = editorial(stage.title); + qs("[data-stage-summary]").textContent = editorial(stage.summary); qs("[data-stage-callout]").replaceChildren(); const tag = document.createElement("span"); tag.className = `status-tag status-tag--${stage.tag[1]}`; - tag.textContent = stage.tag[0]; + tag.textContent = editorial(stage.tag[0]); const callout = document.createElement("p"); - callout.textContent = stage.callout; + callout.textContent = editorial(stage.callout); qs("[data-stage-callout]").append(tag, callout); fieldList("[data-stage-input]", stage.input); fieldList("[data-stage-output]", stage.output); - qs("[data-input-count]").textContent = `${stage.input.length} ${stage.input.length === 1 ? "field" : "fields"}`; - qs("[data-output-count]").textContent = `${stage.output.length} ${stage.output.length === 1 ? "field" : "fields"}`; + qs("[data-input-count]").textContent = editorial(`${stage.input.length} ${stage.input.length === 1 ? "field" : "fields"}`); + qs("[data-output-count]").textContent = editorial(`${stage.output.length} ${stage.output.length === 1 ? "field" : "fields"}`); qs("[data-stage-code]").textContent = JSON.stringify(stage.data, null, 2); - qs("[data-progress-label]").textContent = `Step ${currentStage + 1} of ${demoStages.length}`; - qs("[data-disclosure-label]").textContent = stage.disclosureLabel; + qs("[data-progress-label]").textContent = editorial(`Step ${currentStage + 1} of ${demoStages.length}`); + qs("[data-disclosure-label]").textContent = editorial(stage.disclosureLabel); qs("[data-meter]").setAttribute("aria-valuenow", String(stage.disclosure)); qs("[data-meter-fill]").style.width = `${stage.disclosure}%`; qs("[data-meter-value]").textContent = `${stage.disclosure}%`; @@ -407,7 +411,7 @@ function setDemoStage(index, announce = true) { const prev = qs("[data-prev-stage]"); const next = qs("[data-next-stage]"); prev.disabled = currentStage === 0; - next.innerHTML = `${stage.next} `; + next.innerHTML = `${editorial(stage.next)} `; qsa("[data-stage-button]").forEach((button, buttonIndex) => { button.setAttribute("aria-selected", String(buttonIndex === currentStage)); @@ -416,7 +420,7 @@ function setDemoStage(index, announce = true) { }); setHeroStage(currentStage); - if (announce) qs("[data-announcer]").textContent = `Step ${currentStage + 1}: ${stage.kicker}. ${stage.title}`; + if (announce) qs("[data-announcer]").textContent = editorial(`Step ${currentStage + 1}: ${stage.kicker}. ${stage.title}`); } function setLayer(layerKey, moveFocus = false) { @@ -429,15 +433,15 @@ function setLayer(layerKey, moveFocus = false) { const heading = document.createElement("div"); const label = document.createElement("p"); label.className = "utility-label"; - label.textContent = `${layer.number} / ${layer.label}`; + label.textContent = editorial(`${layer.number} / ${layer.label}`); const title = document.createElement("h3"); - title.textContent = layer.title; + title.textContent = editorial(layer.title); heading.append(label, title); const copy = document.createElement("div"); const summary = document.createElement("p"); - summary.textContent = layer.summary; + summary.textContent = editorial(layer.summary); const examples = document.createElement("p"); - examples.textContent = layer.examples; + examples.textContent = editorial(layer.examples); examples.style.marginTop = "14px"; copy.append(summary, examples); intro.append(heading, copy); @@ -451,11 +455,11 @@ function setLayer(layerKey, moveFocus = false) { number.textContent = String(index + 1).padStart(2, "0"); const body = document.createElement("div"); const name = document.createElement("h4"); - name.textContent = node[0]; + name.textContent = editorial(node[0]); const description = document.createElement("p"); - description.textContent = node[1]; + description.textContent = editorial(node[1]); const currentExamples = document.createElement("small"); - currentExamples.textContent = `Examples: ${node[2]}`; + currentExamples.textContent = editorial(`Examples: ${node[2]}`); body.append(name, description, currentExamples); item.append(number, body); nodes.append(item); @@ -467,7 +471,7 @@ function setLayer(layerKey, moveFocus = false) { button.setAttribute("aria-selected", String(selected)); button.tabIndex = selected ? 0 : -1; }); - qs("[data-announcer]").textContent = `${layer.label} selected. ${layer.title}`; + qs("[data-announcer]").textContent = editorial(`${layer.label} selected. ${layer.title}`); if (moveFocus) panel.focus({ preventScroll: true }); } @@ -507,13 +511,13 @@ function navigateToTarget(target) { if (element) element.scrollIntoView({ behavior: window.matchMedia("(prefers-reduced-motion: reduce)").matches ? "auto" : "smooth", block: "start" }); } -function addTranscript(role, message) { +function addTranscript(role, message, formatter = editorial) { const transcript = qs("[data-guide-transcript]"); const row = document.createElement("p"); if (role === "You") row.className = "is-user"; const label = document.createElement("strong"); - label.textContent = role; - row.append(label, document.createTextNode(message)); + label.textContent = editorial(role); + row.append(label, document.createTextNode(formatter ? formatter(message) : message)); transcript.append(row); transcript.scrollTop = transcript.scrollHeight; } @@ -521,8 +525,9 @@ function addTranscript(role, message) { async function askGuide(question) { const status = qs("[data-guide-status]"); const mode = qs("[data-guide-mode]"); - status.textContent = "Thinking…"; + status.textContent = editorial("Thinking…"); let response = null; + let answerFormatter = editorialGenerated; if (location.protocol === "http:" || location.protocol === "https:") { try { @@ -535,7 +540,7 @@ async function askGuide(question) { const body = await result.json(); if (typeof body.answer === "string") { response = { answer: body.answer, target: body.action?.target_id }; - mode.textContent = "OpenAI guide"; + mode.textContent = editorial("OpenAI guide"); } } } catch { @@ -545,16 +550,18 @@ async function askGuide(question) { if (!response) { response = fallbackGuide(question); - mode.textContent = "Local guide"; + answerFormatter = editorial; + mode.textContent = editorial("Local guide"); } - addTranscript("Guide", response.answer); - status.textContent = response.target ? "Answering and navigating" : "Answered"; + const answer = answerFormatter(response.answer); + addTranscript("Guide", answer, null); + status.textContent = editorial(response.target ? "Answering and navigating" : "Answered"); if (response.target) window.setTimeout(() => navigateToTarget(response.target), 350); if (qs("[data-voice-output]").checked && "speechSynthesis" in window) { window.speechSynthesis.cancel(); - window.speechSynthesis.speak(new SpeechSynthesisUtterance(response.answer)); + window.speechSynthesis.speak(new SpeechSynthesisUtterance(answer)); } } @@ -563,7 +570,7 @@ function initializeVoice() { const Recognition = window.SpeechRecognition || window.webkitSpeechRecognition; if (!Recognition) { button.disabled = true; - button.textContent = "Voice input unavailable"; + button.textContent = editorial("Voice input unavailable"); return; } const recognition = new Recognition(); @@ -571,21 +578,21 @@ function initializeVoice() { recognition.interimResults = true; recognition.continuous = false; recognition.addEventListener("start", () => { - button.textContent = "Listening…"; - qs("[data-guide-status]").textContent = "Listening"; + button.textContent = editorial("Listening…"); + qs("[data-guide-status]").textContent = editorial("Listening"); }); recognition.addEventListener("result", (event) => { const transcript = [...event.results].map((result) => result[0].transcript).join(""); qs("#guide-input").value = transcript; }); recognition.addEventListener("end", () => { - button.textContent = "Voice input"; - qs("[data-guide-status]").textContent = "Ready"; + button.textContent = editorial("Voice input"); + qs("[data-guide-status]").textContent = editorial("Ready"); qs("#guide-input").focus(); }); recognition.addEventListener("error", () => { - button.textContent = "Voice input"; - qs("[data-guide-status]").textContent = "Voice input could not start"; + button.textContent = editorial("Voice input"); + qs("[data-guide-status]").textContent = editorial("Voice input could not start"); }); button.addEventListener("click", () => recognition.start()); } @@ -611,7 +618,7 @@ function initialize() { const input = qs("#guide-input"); const question = input.value.trim(); if (!question) return; - addTranscript("You", question); + addTranscript("You", question, null); input.value = ""; await askGuide(question); }); diff --git a/site/context-layer/demo/manifest.webmanifest b/site/context-layer/demo/manifest.webmanifest index d832b99..f39377a 100644 --- a/site/context-layer/demo/manifest.webmanifest +++ b/site/context-layer/demo/manifest.webmanifest @@ -1,7 +1,7 @@ { - "name": "Context Layer", - "short_name": "Context Layer", - "description": "A public interactive demonstration of the Context Layer working proposal.", + "name": "context layer", + "short_name": "context layer", + "description": "a public interactive demonstration of the context layer working proposal.", "start_url": "/context-layer/demo", "display": "standalone", "background_color": "#0d1117", diff --git a/site/context-layer/downloads/context-layer-architecture.svg b/site/context-layer/downloads/context-layer-architecture.svg index 51a7bac..e8faff9 100644 --- a/site/context-layer/downloads/context-layer-architecture.svg +++ b/site/context-layer/downloads/context-layer-architecture.svg @@ -1,6 +1,6 @@ - context layer one-screen architecture + context layer protocol architecture Six recorded steps move context from capture through normalization, the user-owned vault, a policy decision, a minimum bundle, and a bounded action. A receipt rail records outcomes and returns proposed writeback through policy. diff --git a/site/context-layer/source/agent-navigation-manifest.json b/site/context-layer/source/agent-navigation-manifest.json index e6ec01d..d7caa7a 100644 --- a/site/context-layer/source/agent-navigation-manifest.json +++ b/site/context-layer/source/agent-navigation-manifest.json @@ -26,10 +26,10 @@ "reference" ], "public_routes": [ - { "path": "/writing/context-layer", "label": "Published essay", "format": "text/html" }, - { "path": "/reference/architecture", "label": "Zoomable architecture", "format": "text/html" }, - { "path": "/reference/specification", "label": "Draft technical specification", "format": "text/html" }, - { "path": "/reference/implementation", "label": "Implementation profiles", "format": "text/html" } + { "path": "/signal/the-context-layer", "label": "Published essay", "format": "text/html" }, + { "path": "/context-layer/architecture", "label": "Zoomable architecture", "format": "text/html" }, + { "path": "/context-layer/specification", "label": "Draft technical specification", "format": "text/html" }, + { "path": "/context-layer/implementation", "label": "Implementation profiles", "format": "text/html" } ], "constraints": { "same_page_only": true, diff --git a/site/context-layer/source/context-layer-blog-post.md b/site/context-layer/source/context-layer-blog-post.md index 02aa97a..0e5d15c 100644 --- a/site/context-layer/source/context-layer-blog-post.md +++ b/site/context-layer/source/context-layer-blog-post.md @@ -287,8 +287,8 @@ The Context Layer is an attempt to make the better architecture portable. - [Context Layer interactive overview](/) - [Context Layer end-to-end demo](/#demo) -- [Draft technical specification](/reference/specification) -- [Implementation and interoperability profiles](/reference/implementation) +- [Draft technical specification](/context-layer/specification) +- [Implementation and interoperability profiles](/context-layer/implementation) - [HTTP Semantics, RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html) - [TLS 1.3, RFC 8446](https://www.rfc-editor.org/info/rfc8446/) - [ActivityPub, W3C Recommendation](https://www.w3.org/TR/activitypub/) diff --git a/site/context-layer/source/context-layer-implementation-and-interoperability.md b/site/context-layer/source/context-layer-implementation-and-interoperability.md index e15b137..2ee4649 100644 --- a/site/context-layer/source/context-layer-implementation-and-interoperability.md +++ b/site/context-layer/source/context-layer-implementation-and-interoperability.md @@ -17,7 +17,7 @@ It uses **adapter compatibility** as a precise term: Adapter compatibility does not imply that an adapter exists in this repository, that two vendors have tested interoperability, or that the Context Layer is part of the external protocol's official specification. -The current repository contains the draft specification, five schemas, a dependency-free reference runtime, and an experimental single-user local core with synthetic data. The profiles below define broader implementation targets; website publication and deployment source are maintained separately. +The current repository contains the draft specification, five schemas, a dependency-free reference runtime, and an experimental single-user local core with synthetic data. Broader adapter, platform, and interoperability profiles remain implementation targets. ## 2. Where the Context Layer fits @@ -127,7 +127,7 @@ This is the recommended first implementation profile because it keeps the trust | A2A | Agent-to-agent task transport | Bundle carried as structured task data or artifact; remote agent bound as recipient | Reference link only | Remote agent retention and onward disclosure must be explicit | | Local/cloud models | Context consumers | Prompt or model input assembled only from a scoped bundle | Illustrative runtime references | Provider retention and logging remain part of recipient policy | | OpenAI Realtime | Voice or multimodal consumer | WebRTC session receives scoped instructions and context through a backend | Informative profile only; no conforming implementation | Standard API keys must remain server-side and a demo is not hardened production infrastructure | -| Web UI | Approval and consumption surface | Show bundle provenance, permissions, expiry, actions, and receipts | Informative profile only; publication UI maintained separately | Static pages do not enforce policy | +| Web UI | Approval and consumption surface | Show bundle provenance, permissions, expiry, actions, and receipts | Static demonstrator only | Static pages do not enforce policy | | iOS/mobile | Approval and consumption surface | Native app consumes bundles and short-lived sessions; credentials use platform storage | Not implemented | Never embed provider API keys in an app binary | | x402 | Optional payment condition | Request or action can reference a payment requirement and payment receipt | Reference link only | Payment does not grant context permission | diff --git a/site/context-layer/source/context-layer-technical-specification.md b/site/context-layer/source/context-layer-technical-specification.md index 4306f6b..1396825 100644 --- a/site/context-layer/source/context-layer-technical-specification.md +++ b/site/context-layer/source/context-layer-technical-specification.md @@ -8,7 +8,6 @@ | Version identifier | `context-layer/0.2-draft` | | Date | 2026-08-17 | | Editors' target | Reviewable core contract for implementation and interoperability experiments | -| Canonical local context | [`../agent-navigation-manifest.json`](../agent-navigation-manifest.json) | ## Change log diff --git a/site/icon.svg b/site/icon.svg new file mode 100644 index 0000000..6c28b6c --- /dev/null +++ b/site/icon.svg @@ -0,0 +1,5 @@ + + + + + diff --git a/tests/editorial-formatting.test.mjs b/tests/editorial-formatting.test.mjs new file mode 100644 index 0000000..bc566e2 --- /dev/null +++ b/tests/editorial-formatting.test.mjs @@ -0,0 +1,35 @@ +import assert from "node:assert/strict"; +import test from "node:test"; +import { + contextLayerPageNames, + formatContextLayerHtml, + formatContextLayerPages, +} from "../scripts/format-context-layer-site.mjs"; +import { verifyContextLayerEditorial } from "../scripts/verify-context-layer-editorial.mjs"; + +test("editorial formatter is idempotent across all seven public pages", async () => { + assert.equal(contextLayerPageNames.length, 7); + assert.deepEqual(await formatContextLayerPages({ check: true }), []); +}); + +test("editorial formatter protects technical and user-authored boundaries", () => { + const source = [ + "

      USEFUL CONTEXT AND OpenAI APIs

      ", + "
      API AND UI
      ", + "", + '', + 'Link AND OpenAI', + ].join(""); + const once = formatContextLayerHtml(source); + + assert(once.includes("

      useful context & OpenAI APIs

      ")); + assert(once.includes("
      API AND UI
      ")); + assert(once.includes("")); + assert(once.includes('value="User AND API"')); + assert(once.includes('href="https://Example.com/Foo-and-Bar"')); + assert.equal(formatContextLayerHtml(once), once); +}); + +test("site editorial verifier covers static, runtime, and typography contracts", async () => { + await assert.doesNotReject(verifyContextLayerEditorial()); +}); diff --git a/tests/public-site.test.mjs b/tests/public-site.test.mjs index 3277dd0..1ca3535 100644 --- a/tests/public-site.test.mjs +++ b/tests/public-site.test.mjs @@ -29,12 +29,13 @@ test("standalone deployment maps every published route to versioned source", asy test("public dossier keeps the production identity and local asset contract", async () => { const index = await readFile(join(site, "context-layer/_pages/index.html"), "utf8"); - assert.match(index, /

      the Context Layer<\/em>\.<\/h1>/); + assert.match(index, /

      the context layer<\/em>\.<\/h1>/); assert.match(index, /one boundary\. six recorded steps\./); assert.match(index, /href="\/context-layer\/architecture"/); assert.match(index, /href="\/signal\/the-context-layer"/); for (const asset of [ + "icon.svg", "context-layer/assets/context-layer-native.css", "context-layer/assets/context-layer-native.js", "context-layer/downloads/context-layer-architecture.svg",