From d1d3254edb45a0557709b95010965f5a8e383ba5 Mon Sep 17 00:00:00 2001 From: LKSNDRTMLKV Date: Thu, 20 Aug 2026 23:00:33 +0200 Subject: [PATCH 1/2] docs: move licensing out of the engine section into orientation, and stop restating the licence split on the introduction --- site/dpp-docs/astro.config.mjs | 9 +++++++-- site/dpp-docs/src/content/docs/core-concepts.mdx | 2 +- .../docs/{engine => getting-started}/licensing.mdx | 0 site/dpp-docs/src/content/docs/introduction.mdx | 12 ++++++------ 4 files changed, 14 insertions(+), 9 deletions(-) rename site/dpp-docs/src/content/docs/{engine => getting-started}/licensing.mdx (100%) diff --git a/site/dpp-docs/astro.config.mjs b/site/dpp-docs/astro.config.mjs index 567939b..88b0843 100644 --- a/site/dpp-docs/astro.config.mjs +++ b/site/dpp-docs/astro.config.mjs @@ -8,7 +8,10 @@ export default defineConfig({ // Design pages removed; redirect to the closest living equivalent. '/design/no-touch-data': '/getting-started/what-odal-can-and-cannot-see', '/design/proof-bound': '/getting-started/what-odal-can-and-cannot-see', - '/design/open-core': '/engine/licensing', + '/design/open-core': '/getting-started/licensing', + // Licensing moved out of the engine section; the open-core split describes + // both parts, so it belongs with orientation rather than with the service. + '/engine/licensing': '/getting-started/licensing', '/design/adr': '/core-concepts', '/design/why-no-capability-gating': '/core-concepts', // Core consolidated from per-crate/type pages into three concept pages. @@ -56,6 +59,9 @@ export default defineConfig({ { label: 'Quick Start', link: '/quick-start' }, { label: 'Core Concepts', link: '/core-concepts' }, { label: 'What Odal can and cannot see', link: '/getting-started/what-odal-can-and-cannot-see' }, + // Last in orientation rather than under The Engine: the open-core + // split covers both parts, so it is not an engine-specific topic. + { label: 'Licensing', link: '/getting-started/licensing' }, ], }, { @@ -78,7 +84,6 @@ export default defineConfig({ { label: 'Operating securely', link: '/engine/security' }, { label: 'Self-Hosting', link: '/engine/self-hosted' }, { label: 'The CLI', link: '/engine/cli' }, - { label: 'Licensing', link: '/engine/licensing' }, ], }, { diff --git a/site/dpp-docs/src/content/docs/core-concepts.mdx b/site/dpp-docs/src/content/docs/core-concepts.mdx index a685422..cd56c0f 100644 --- a/site/dpp-docs/src/content/docs/core-concepts.mdx +++ b/site/dpp-docs/src/content/docs/core-concepts.mdx @@ -21,7 +21,7 @@ Odal Node is two parts with two licences. The **core** is the regulatory standar One rule decides which side any change belongs on: *if it changes because an EU regulation changed, it belongs in the core; if it changes because of how the system is deployed or operated, it belongs in the engine.* The dependency only ever points one way — the engine uses the core; the core knows nothing of the engine. -The licence table is on the [Introduction](/introduction). +The terms are set out in [Licensing](/getting-started/licensing). ## One seam for new regulation diff --git a/site/dpp-docs/src/content/docs/engine/licensing.mdx b/site/dpp-docs/src/content/docs/getting-started/licensing.mdx similarity index 100% rename from site/dpp-docs/src/content/docs/engine/licensing.mdx rename to site/dpp-docs/src/content/docs/getting-started/licensing.mdx diff --git a/site/dpp-docs/src/content/docs/introduction.mdx b/site/dpp-docs/src/content/docs/introduction.mdx index 36b5755..c7211ed 100644 --- a/site/dpp-docs/src/content/docs/introduction.mdx +++ b/site/dpp-docs/src/content/docs/introduction.mdx @@ -15,16 +15,16 @@ The promise runs deeper than a signature. Every passport's history — publicati ## How it's organised -Odal Node is two parts with two licences: +Odal Node is two parts: -| Part | Licence | What it is | -|---|---|---| -| [`dpp-core`](https://github.com/odal-node/dpp-core) | Apache‑2.0 | The regulatory standard — the rules a compliant passport must satisfy. | -| [`dpp-engine`](https://github.com/odal-node/dpp-engine) | BSL‑1.1 | The service that runs those rules in production. | +| Part | What it is | +|---|---| +| [`dpp-core`](https://github.com/odal-node/dpp-core) | The regulatory standard — the rules a compliant passport must satisfy. | +| [`dpp-engine`](https://github.com/odal-node/dpp-engine) | The service that runs those rules in production. | > The core is the rulebook. The engine is the service that uses the rulebook. -The split is deliberate, and it is the subject of [Core Concepts](/core-concepts): the standard stays open and free, while the operational layer around it is what sustains the project. +The split is deliberate, and it is the subject of [Core Concepts](/core-concepts): the standard stays open and free, while the operational layer around it is what sustains the project. The two parts ship under different licences, and [Licensing](/getting-started/licensing) is where those terms are set out. ## Next steps From 054865f56abf0bc54ac2f9d6e8ca755552cf4431 Mon Sep 17 00:00:00 2001 From: LKSNDRTMLKV Date: Thu, 20 Aug 2026 23:04:06 +0200 Subject: [PATCH 2/2] docs: disclose scan telemetry on the data-boundary page, fix the pointer to a design section that no longer exists, and restore the trust-page link now that the page is published --- site/dpp-docs/astro.config.mjs | 1 - site/dpp-docs/src/content/docs/core-concepts.mdx | 4 +++- .../docs/getting-started/what-odal-can-and-cannot-see.mdx | 6 ++++++ site/dpp-landing/src/pages/index.astro | 2 +- 4 files changed, 10 insertions(+), 3 deletions(-) diff --git a/site/dpp-docs/astro.config.mjs b/site/dpp-docs/astro.config.mjs index 88b0843..8544f55 100644 --- a/site/dpp-docs/astro.config.mjs +++ b/site/dpp-docs/astro.config.mjs @@ -69,7 +69,6 @@ export default defineConfig({ collapsed: true, items: [ { label: 'What the core does', link: '/core/overview' }, - // { label: 'Verify a passport yourself', link: '/core/verify' }, { label: 'Standards & interoperability', link: '/core/standards' }, { label: 'Security & cryptography', link: '/core/security' }, { label: 'Extending: sectors & plugins', link: '/core/sectors' }, diff --git a/site/dpp-docs/src/content/docs/core-concepts.mdx b/site/dpp-docs/src/content/docs/core-concepts.mdx index cd56c0f..dcd546b 100644 --- a/site/dpp-docs/src/content/docs/core-concepts.mdx +++ b/site/dpp-docs/src/content/docs/core-concepts.mdx @@ -5,7 +5,7 @@ description: The three ideas behind Odal Node — the proof-bound architecture, import { Aside } from "@astrojs/starlight/components"; -Three ideas explain almost everything about how Odal Node is built and why. Understand these and the rest of the documentation — and the code — reads easily. This page is the synthesis; each idea has a fuller treatment under Design Principles. +Three ideas explain almost everything about how Odal Node is built and why. Understand these and the rest of the documentation — and the code — reads easily. This page is the synthesis; each idea is treated fully elsewhere, and each section below says where. ## Proof-bound: the data stays yours @@ -27,6 +27,8 @@ The terms are set out in [Licensing](/getting-started/licensing). Regulation arrives sector by sector, and it keeps moving. So the core is built around a single extension point: each sector's compliance logic plugs in through one seam, and new sectors and revised rules enter there without changing anything around them. +A fuller treatment of the seam is in [Extending: sectors & plugins](/core/sectors). + diff --git a/site/dpp-docs/src/content/docs/getting-started/what-odal-can-and-cannot-see.mdx b/site/dpp-docs/src/content/docs/getting-started/what-odal-can-and-cannot-see.mdx index 8476520..ca77012 100644 --- a/site/dpp-docs/src/content/docs/getting-started/what-odal-can-and-cannot-see.mdx +++ b/site/dpp-docs/src/content/docs/getting-started/what-odal-can-and-cannot-see.mdx @@ -31,6 +31,12 @@ The signed passport published to a resolver we operate, and the metadata require The contents of your import files. The software reads them once, validates the data, signs the passport, and discards the input. There is no setting, configuration, or internal code path that retains the uploaded file after signing — it is not a choice made per customer; it is how the software works. Be precise about what that covers: the *file* is not kept, while records *derived* from it during the import — the passport, and a job record carrying per-row validation findings — are. +## What the node records about resolution + +One thing is recorded rather than discarded, and it belongs on this page for that reason: when a published passport is resolved, the node can count that it happened. + +That count is an aggregate — per passport, per day, per surface — and it is the whole of it. Nothing about the person who scanned is recorded: no IP address, no device, no location, no identity, no session. This is a property of the schema rather than a policy: there is no column in which any of it could be stored, so there is nothing to leak and nothing that could quietly grow into tracking. Producing a QR-code image is counted separately and is never added to the scan total — a render measures label production, not people. + ## The mechanism 1. **Import** — product data arrives at your node (CSV, Excel, ERP export) on infrastructure you control. diff --git a/site/dpp-landing/src/pages/index.astro b/site/dpp-landing/src/pages/index.astro index cce5194..b96c01f 100644 --- a/site/dpp-landing/src/pages/index.astro +++ b/site/dpp-landing/src/pages/index.astro @@ -176,7 +176,7 @@ const steps = [

- + Read the full breakdown →