docs: move licensing into orientation, and close three navigation inconsistencies

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,14 +59,16 @@ 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' },
           ],
         },
         {
           label: 'The Core',
           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' },
@@ -78,7 +83,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' },
           ],
         },
         {

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
 
@@ -21,12 +21,14 @@ 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
 
 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).
+
 <Aside type="note" title="The seam is technical, not commercial">
 That extension point is an architectural boundary, never a paywall. The built-in sectors and any added later use the same mechanism, and all of it is open — new regulatory coverage is never a paid unlock.
 </Aside>

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.

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
 

site/dpp-landing/src/pages/index.astro

@@ -176,7 +176,7 @@ const steps = [
       </div>
     </div>
     <p class="mt-8 text-sm">
-      <!-- <a href="/trust" class="font-medium">Read the full breakdown →</a> -->
+      <a href="/trust" class="font-medium">Read the full breakdown →</a>
     </p>
   </Section>