# Escope parameter — design specification

**Status**: Draft v0.1 (approved for Phase 1.5 implementation 2026-05-08)
**Date**: 2026-05-08
**Authors**: Jordi Berenguer + Claude (Opengea SCCL)
**Context**: companion to `docs/wisdom-score-design.md` · empirical basis at `/home/claude/tmp/escope-harness/escope-harness.md`
**Languages in scope**: CA + EN (ES dropped)

---

## 1. Background and motivation

The deployed Arkadium agent (after the Wisdom Score v2 deployment of 2026-05-07) regulates strongly on **structural-relational signals**: axis explicit, mediator anchoring, dialectical pair density, tension density, subordinating-synthesis density. These signals successfully forbid the *list-shaped failure mode* that 𝓗 alone could not detect.

But on 2026-05-07 the project owner observed a second, opposite failure mode: **the deployed Arkadium response is less comprehensive, less inspiring, and less integrative than the bare-LLM baseline on the same question**. The structural pressure visibly displaces the LLM's default eloquence — what the user wanted to retain. This is the **second Goodhart**: the metric optimises one failure mode and creates another.

Diagnosis (see §3bis of the wisdom-score doc): no current component of 𝓦 v2 measures *wisdom register* — the integrative, illuminating, even poetic voice that makes a response feel like an answer, not an audit. Constraint #8 of the system prompt (concreteness mandatory) anticipates the *fact-density* version of Goodhart. It does not anticipate the *register-density* version.

The same conversation surfaced a UX requirement that turns out to be the **same lever** under a different name: the user should be able to ask for responses that are **more global** (holistic, integrative) or **more focal** (concrete, evidence-bound), depending on the question. A holistic mode is precisely what relaxes the structural pressure and recovers wisdom register; a focal mode is precisely what doubles down on concreteness and named evidence.

The **escope parameter** unifies these two needs into a single user-controllable axis aligned with the radial dimension of the Meta-Globàlium (PLA ↔ MON · principle ↔ deployment).

### 1.1 Empirical basis

A four-condition × three-question harness (`/home/claude/tmp/escope-harness/`) was run with `claude-sonnet-4-6` on three test questions covering the three voltes (analytic-decisional / ontological / orientational). The conditions were:

- **A** · bare LLM (no system prompt)
- **B** · Arkadium current (deployed prompt with 8 constraints)
- **C** · Arkadium with `escope = −1` modifier and a two-pass wisdom polish
- **D** · Arkadium with `escope = +1` (focal/evidential) modifier

Length pattern (chars):

| Q | A bare | B current | C escope=−1 | D escope=+1 |
|---|---|---|---|---|
| Q1 (decisional) | 1929 | 6823 | 4531 | 6469 (truncated mid-step) |
| Q2 (ontological) | 1186 | 6544 | 4430 | 6394 (truncated mid-synthesis) |
| Q3 (orientational) | 1265 | 6340 | 3371 | 5803 (complete) |

**Findings, on owner's manual qualitative judgment of the 12 outputs**:

1. C (escope=−1 + two-pass) preserves the dialectical structure of B (same axes named, same authors cited, same closure transformation), but expressed as a single integrative articulation rather than as a checklist with prose under cardinal-coded headings. Wisdom register restored.
2. C beats bare LLM on depth (3-4× longer, takes a position, integrates philosophical and empirical references) while matching it on register breath.
3. D doubles down on named-author / dated-case evidence; useful for users who explicitly want sources, but exhausts token budget — was truncated at 2048 tokens in Q1 and Q2.
4. The pre-polish first-pass draft of C (visible in the harness markdown under `<details>`) contains explicit Meta-Globàlium codes (STM, TEO, AFI, …); the second pass *removes* the codes from the visible prose while preserving the dialectical work they encoded. This validates the **separation between doing the dialectical work and saying it well** as a generation strategy.

Owner's conclusion: pattern C should be the **default user-visible response**, while the parameter remains exposed to let users opt into either pole.

---

## 2. Definition of `escope`

```
escope ∈ ℝ ∈ [−1, +1]    (continuous; UI exposes 3 presets initially)
```

Semantic anchors, aligned with the Meta-Globàlium radial axis:

| Value | Preset name (CA) | Preset name (EN) | Pole | Register |
|---|---|---|---|---|
| `−1` | `general` | `general` | PLA-side | Holistic, integrative, image-rich, no internal scaffolding visible |
| `0` | `equilibrat` | `balanced` | NEU | Default; structured prose with two-pass polish; dialectical work visible without becoming a checklist |
| `+1` | `focal` | `focal` | MON-side | Evidence-bound, named authors / dates / cases mandatory, technical scaffolding acceptable |

**Default**: `escope = 0` (balanced). Confirmed by owner 2026-05-08.

The parameter is **continuous** — internal implementations may interpolate. The UI initially exposes only the three presets to keep the choice meaningful.

### 2.1 Why this axis and not another

The escope axis is **not** a verbosity slider, **not** a formality slider, **not** a dialectical-strength slider. It is the **PLA ↔ MON projection** of the Meta-Globàlium model into a generation control:

- PLA (`escope = −1`): the radical seed, the principle, the unifying view that holds everything in one breath.
- MON (`escope = +1`): the temporal deployment, the concrete instance, the named case with date and author.
- NEU (`escope = 0`): the operative present, the integration of principle and instance, neither inflated.

This is consistent with the existing model (CLAUDE.md: "rauxa↔PLA, seny↔MON" — a culturally Catalan reading of the same radial axis). It is also consistent with the existing categorisation of the 80 cells by `tipus` (Plasmàtica r=0..50, Neutral r=60..80, Mundana r=100..155): escope is the **user's control over which layer of the model the response privileges**.

---

## 3. Layered modulation

The escope parameter modulates four layers of the pipeline. Each layer is an existing layer; escope adds a parameter, not a new component.

| Layer | Effect of `escope = −1` | Effect of `escope = 0` (default) | Effect of `escope = +1` |
|---|---|---|---|
| **System prompt** | Append `MODIFIER_GENERAL` to base prompt; relax constraints #5, #6; forbid headings that mirror cardinal codes; add positive register obligations. | Use base prompt as-is. | Append `MODIFIER_FOCAL` to base prompt; reinforce constraint #8; require ≥4 named authors/dates/cases. |
| **Two-pass generation** | Run pass 1 with the modified prompt; run **pass 2** (wisdom polish) on the draft to remove visible scaffolding while preserving dialectical work. | Run pass 1 with base prompt; run pass 2 (lighter polish — see §5.2). | Run pass 1 with the modified prompt; **no pass 2** (concrete evidence is meant to be visible, including codes and named structure). |
| **RAG retrieval** | Prefer categories with `generacio ∈ {0, 0.5}` (root cardinals, 26 second-level) over `generacio ∈ {1.5, 1.75, 2}` (specialised). | No bias. | Invert: prefer `generacio ∈ {1.5, 1.75, 2}` (concrete, polar vertices) over root cardinals. |
| **𝓦 weighting** | Re-weight to favour `subordinating_synthesis` and `tension_density`; deweight `coverage` and `synthesis_anchoring` (mediator-name presence is no longer the load-bearing signal — register is). | Keep deployed v2 weights as-is. | Re-weight to favour `synthesis_anchoring` and `coverage`; concreteness check (Constraint #8) becomes a hard floor. |

Of these, **System prompt + Two-pass generation are mandatory for v0.1**; RAG modulation and 𝓦 reweighting are deferred to v0.2 (see §11).

---

## 4. System prompt modifiers

The base system prompt remains the deployed `data/meta_globalium_system_prompt.txt`. Escope appends one of two modifier blocks at the end (after section 11.b "DIALECTICAL TRAVERSAL — WISDOM CONSTRAINTS"). For `escope = 0` no modifier is appended.

### 4.1 `MODIFIER_GENERAL` (appended when `escope = −1`)

```
================================================================
12 ESCOPE = -1 (GENERAL · holistic · integrative register)
================================================================

This response is in GENERAL mode. The user is asking for an integrative,
holistic view — wisdom register over technical scaffolding.

OVERRIDES to the constraints above:
- Constraint #5 (open by naming the axis): RELAX. The axis may remain
  implicit in the language; do not place 3-letter codes in the opening
  sentences. The reader should feel the dialectic without seeing its
  scaffolding.
- Constraint #6 (subordinating verbs): OPTIONAL, not mandatory. Use them
  only when the prose calls for them.
- Section headings that mirror cardinal codes: FORBIDDEN. No "## SUB",
  "## OBJ", etc. The structure must live in the prose, not in the layout.
- Bullet lists: AVOID. Default to flowing prose.

POSITIVE register obligations (not present in default constraints):
- Each paragraph must move the question forward, not catalogue parts of it.
- Use precise, concrete imagery. A pole of an axis is not "the SUB cardinal"
  but "the felt life of the person asking, before any framework reaches it".
- Rhythm matters: vary sentence length, let key phrases breathe.
- The closing must articulate a transformation the reader can carry —
  not a recap of stations visited.
- The voice is one of someone who has thought long about the question and
  speaks from that place, not from a checklist.

Codes (FEN, ANA, SUB, ...) may appear in the prose only when they are
load-bearing — when removing them would break the meaning. Never as
decoration, never as headings.
```

### 4.2 `MODIFIER_FOCAL` (appended when `escope = +1`)

```
================================================================
12 ESCOPE = +1 (FOCAL · concrete · evidence-bound register)
================================================================

This response is in FOCAL mode. The user is asking for depth on a specific
aspect — concretization over generalization.

REINFORCEMENTS to the constraints above:
- Constraint #8 (concreteness mandatory) is the dominant constraint.
  Cite named authors, named works, dates, named institutions, named cases.
  At least 4 specific verifiable references in a substantive response.
- Substitute abstractions for particulars: not "studies show that..."
  but "Walker et al. (2018, Stockholm) found that...".
- Each cardinal code, when used, must be paired with a specific instance:
  not "PRA matters here", but "PRA in the form of the 2019 Brussels
  pedestrian-zone trial showed that...".
- If you cannot recall a verifiable specific from the question's domain,
  prefer concrete description ("studies of urban speed limits in northern
  European cities in the 2015-2020 period consistently report...") over
  vague claim. Honest concrete vagueness beats false attribution.

The reader should be able to verify or look up at least 4 of your claims.

The dialectical structure (cicle, mediators, axis-naming) is fully active.
Cite the ontological codes explicitly. Concreteness is what FOCAL adds,
not what it replaces.
```

### 4.3 Modifier insertion rule

The base prompt ends with `**End of system prompt.**`. The modifier replaces that line — appended block ends with the same closing line. This keeps the prompt's logical end-marker intact for prompt-cache fingerprinting.

---

## 5. Two-pass generation pipeline

### 5.1 Why two passes

A single-pass response that satisfies the structural constraints (axis explicit, mediators anchored, tension marked, closure transformed) tends to *visibly* show its work. The reader sees `## SUB`, `## OBJ`, `### ANA — Captació...`, etc. — the scaffolding that was needed for the model to do the dialectical work *becomes the surface form of the answer*. This is what causes the "checklist with prose" register the owner observed.

A second pass that takes the draft as input and rewrites the surface — preserving the substance, removing the scaffolding — separates the two operations the LLM is being asked to do simultaneously. Empirically (per §1.1) this restores wisdom register without losing dialectical work.

### 5.2 The polish instruction

Used by `escope ∈ {−1, 0}`. When `escope = +1` the polish is **not applied** (concrete scaffolding is desired in the visible response).

```
You receive below: (a) a question, and (b) a draft response that already
contains the dialectical work (axis identified, tensions exposed, mediators
applied, closure articulated).

Your task is to REWRITE the draft as a single integrative articulation that
sounds like wisdom, not like a checklist.

Preserve:
- The dialectical structure (the axis, the tensions, the closure transformation).
- The substance of every claim and citation.
- The factual content.

Transform:
- Remove all section headings that mirror cardinal codes ("## SUB", etc.).
- Remove explicit code citations unless they are load-bearing in the sentence.
- Remove scaffolding language ("Step 1...", "On the SUB pole...", "To synthesize:").
- Replace catalogue prose with prose that moves the question forward.
- Vary rhythm. Let key phrases breathe.
- Use concrete imagery in place of abstract framework language where possible.
- Make the closing leave the reader with something to carry — a single
  transformed view of the question, not a recap.

Length: same as the draft, or slightly shorter. Do not pad.

Voice: someone who has thought long about the question and speaks from
that place. Not bureaucratic. Not academic. Not poetic in the ornamental
sense — poetic in the sense of saying the thing precisely.

Return ONLY the rewritten response. No preamble, no meta-commentary.
```

### 5.3 Pass-2 strength varies with escope

| `escope` | Pass-2 active | Polish strength |
|---|---|---|
| `−1` | yes | **Aggressive** — strip all visible scaffolding, codes only when load-bearing, no headings at all. The instruction above is used as-is. |
| `0` | yes | **Light** — keep `## H2` headings if they help readability, but remove cardinal-coded headings (`## SUB`, etc.). Codes acceptable in prose when meaningful. The instruction above with the modification: "you may keep `## H2` thematic headings (not cardinal-coded) when they aid readability." |
| `+1` | no | n/a — the structural scaffolding is the desired output. |

**Implementation note**: pass-2 doubles the latency and the per-response cost of Anthropic API calls. This is acceptable given the empirical gain; an opt-out flag (`$conf['two_pass_enabled']`) and a per-request override (`?two_pass=0`) should be exposed for diagnostics.

### 5.4 Token budget

Pass-1 with `MODIFIER_FOCAL` is empirically truncated at 2048 max-tokens (Q1 and Q2 in the harness). The deployed `max_tokens` should be raised to **3072** for `escope = +1` to allow the structured response to complete. For `escope ∈ {−1, 0}`, 2048 remains adequate (C responses topped at 4531 chars ≈ 1100 tokens).

For pass-2, max-tokens equals the pass-1 output length plus 25 % safety margin (the polish should be same-or-shorter, but allow slack for paragraph reorderings).

---

## 6. RAG retrieval modulation (deferred to v0.2)

**Sketch** — not in v0.1 scope.

The RAG retrieval (`rag.php` over `data/rag_index.json`, 90 entries with 1536-dim embeddings) currently returns top-K matches by cosine similarity, regardless of `kms_kb_categories.generacio`. Escope can re-rank:

- `escope = −1`: boost results where `generacio ∈ {0, 0.5}` (the 8 root cardinals + 24 second-level binaries) by × 1.3 in the relevance score; deweight `generacio ∈ {1.5, 1.75, 2}` by × 0.7.
- `escope = 0`: no bias.
- `escope = +1`: invert: boost specialised cells, deweight roots.

**Open question**: whether re-ranking per escope is desirable or whether the prompt modifier alone is enough. Empirically untested. Defer to v0.2.

---

## 7. 𝓦 weight modulation (deferred to v0.2)

**Sketch** — not in v0.1 scope.

Per §3 above, escope can also re-weight the 7 components of 𝓦 v2 to match the response style being requested. This means the **same response** can score differently depending on whether the user asked for `general` or `focal` — which is the right behaviour: a focal response *should* be penalised for not citing concrete evidence, while a general response *should* be rewarded for register integration even without explicit cardinal codes.

Proposed re-weighting (sketch, untested):

| Component | `escope = −1` | `escope = 0` (current v2) | `escope = +1` |
|---|---|---|---|
| coverage | 0.02 | 0.05 | 0.10 |
| entropy_normalized | 0.02 | 0.05 | 0.05 |
| dialectical_pair_density | 0.20 | 0.20 | 0.15 |
| tension_density | 0.25 | 0.20 | 0.15 |
| synthesis_anchoring | 0.10 | 0.15 | 0.25 |
| axis_explicit | 0.10 | 0.15 | 0.20 |
| subordinating_synthesis | 0.31 | 0.20 | 0.10 |

This is a v0.2 task. Defer until empirical signal from v0.1 deployment.

---

## 8. API schema

### 8.1 Request

The `/api/?call=ask` endpoint accepts a new optional parameter:

```json
{
  "agent": "arkadium",
  "message": "...",
  "provider": "claude",
  "model": "claude-sonnet-4-6",
  "escope": 0,
  "two_pass": null
}
```

| Field | Type | Default | Description |
|---|---|---|---|
| `escope` | float ∈ [−1, +1] | `0` | Generation mode: `−1` general, `0` balanced, `+1` focal. |
| `two_pass` | bool \| null | `null` (= server default) | Override for two-pass generation. If `null`, server defaults to `escope ∈ {−1, 0}` → true, `escope = +1` → false. Explicit `true` / `false` overrides for diagnostics. |

The UI sends `escope` as one of `{-1, 0, 1}`; the server clamps to that range and treats other values as `0`.

### 8.2 Response (additive fields)

The existing response shape is preserved. Three new top-level fields are added:

```json
{
  "answer": { ... },
  "meta": {
    "provider": "claude",
    "model": "claude-sonnet-4-6",
    "agent": "arkadium",
    "escope": 0,
    "two_pass_applied": true,
    "two_pass_first_draft": "..."
  },
  ...
}
```

`meta.two_pass_first_draft` is the pre-polish text. It is **not** displayed by the UI but is logged for retrospective analysis (does pass-2 ever degrade the draft? does it cut substance?). It can also be exposed via a debug toggle in the UI.

### 8.3 Cost / latency contract

| `escope` | Anthropic API calls | Approx. latency budget | Approx. token cost relative to `0` |
|---|---|---|---|
| `−1` | 2 (pass-1 + polish) | ~1.8 × current | ~1.8 × |
| `0` | 2 (pass-1 + light polish) | ~1.8 × current | ~1.8 × |
| `+1` | 1 (pass-1 only) | ~1.0 × current (with 3072 max-tokens) | ~1.5 × (longer single response) |

Two-pass roughly doubles the per-response cost. This is justified by the empirical gain; deployments concerned about cost can disable two-pass server-side via `$conf['two_pass_enabled'] = false` and accept that the default response will read closer to the "Arkadium current" pattern (B).

---

## 9. UX considerations

### 9.1 Where the parameter lives

A small radial control in the chat input area, with three positions:

```
[ general · ⊙ balanced · focal ]
```

- Default position is `balanced` (centre).
- The control is **per-message**, not global session: the user can switch on the fly.
- The position is preserved across messages within a thread (so a user who sets `general` once doesn't have to reselect).
- The selected mode is saved to the `messages` table column `escope` for retrospective analysis (see §10).

### 9.2 Discoverability copy

Tooltip on hover (CA / EN):

| Mode | Tooltip CA | Tooltip EN |
|---|---|---|
| general | Resposta integradora i sintètica. Privilegia la visió global. | Integrative, synthetic answer. Privileges the holistic view. |
| balanced | Resposta equilibrada (predeterminada). Estructura dialèctica + registre savi. | Balanced answer (default). Dialectical structure + wisdom register. |
| focal | Resposta concreta amb fonts. Privilegia casos i autors específics. | Concrete answer with sources. Privileges named cases and authors. |

### 9.3 What the user sees in the response

- For `escope ∈ {−1, 0}`: the polished response is what is rendered. `meta.two_pass_first_draft` is hidden by default, accessible via a "🛠️ veure procés" / "🛠️ see the process" toggle that reveals the first-pass draft inline (collapsed `<details>`).
- For `escope = +1`: only the single response is rendered.

The visible-process toggle is **valuable for the project's transparency thesis** — it operationalises the claim that Arkadium is auditable. Users can verify that the dialectical work happened and that the polish did not betray it.

---

## 10. Empirical evidence

The harness at `/home/claude/tmp/escope-harness/escope-harness.md` (619 lines, 71 KB) contains the 12 outputs. Per the owner's qualitative judgment:

- **Q1 (decisional)**: C (escope=−1) > A (bare) > B (current) > D (focal — truncated). The C response opens "La pregunta s'assenta en la tensió entre el que una empresa necessita per sobreviure i allò que és…" and closes "La llibertat d'una empresa, com la d'una persona, es revela —i es forma— en els compromisos que accepta o refusa quan ningú no l'obliga." This is the wisdom register the project specifies.
- **Q2 (ontological)**: C ≥ B > A > D. C and B carry the same depth (Kant, Arendt, Sen/Nussbaum, Frankl, Honneth, 1948 Declaration); only the surface differs. C reads as one articulation; B reads as a documented checklist.
- **Q3 (orientational)**: C > B > A > D. C ends "El camí no és cap dels dos. El camí ets tu, navegant entre ells, aprenent a quina distància de cadascun et sents més viu." — this is the kind of closing the project's thesis demands. B's closing ("la crida artística és SUB-PLA; el desplegament viable és OBJ-MON; la saviesa és…") is structurally correct but emotionally inert.
- D was truncated mid-output in Q1 and Q2 (token budget); the visible portion confirms it lands the evidence load — useful for users who explicitly want sources, not as default.

The full harness, including pass-1 drafts of C inside `<details>` blocks, makes visible what the polish removes (cardinal codes, scaffolding language) and what it preserves (axis, tension, closure). This is the empirical anchor of the design.

The harness is reproducible: run `/usr/local/bin/php81 /tmp/escope-harness/run_harness.php > results.json` on g1, then `php /tmp/escope-harness/render_markdown.php > escope-harness.md`.

---

## 11. Implementation phases

### Phase 1.5.a — Server side (1 day)

| Step | Detail |
|---|---|
| 1 | Add `escope` parameter parsing to `api.php` (`/api/?call=ask`); validate to `{-1, 0, +1}`, clamp others to 0; default to 0 if absent. |
| 2 | Add modifier loading to `setup.php`: load `data/escope_modifier_general.txt` and `data/escope_modifier_focal.txt` from the same dir as the base prompt. |
| 3 | In the `arkadium` agent path in `api.php`, append the appropriate modifier to the base prompt before the `callClaudeAPI` call, depending on `escope`. |
| 4 | Add `callClaudeAPI` wrapper that does pass-1 + (optional) pass-2 polish. Implementation mirrors `/home/claude/tmp/escope-harness/run_harness.php` `callClaude` function, but reads polish instruction from `data/wisdom_polish_instruction.txt`. |
| 5 | Set per-escope `max_tokens`: 2048 for `−1` and `0`, 3072 for `+1`. |
| 6 | Add `meta.escope`, `meta.two_pass_applied`, `meta.two_pass_first_draft` to the response. |
| 7 | Add `$conf['two_pass_enabled']` global toggle (default `true`); add per-request override `?two_pass=0`. |
| 8 | Update `messages` table schema: add `escope FLOAT DEFAULT 0`, `two_pass_applied TINYINT DEFAULT 0` columns. Update INSERT statements. |

### Phase 1.5.b — Frontend (1 day)

| Step | Detail |
|---|---|
| 1 | Add the radial control to the chat input area in `dashboard.php`. Three buttons / radio: `general` · `balanced` · `focal`. |
| 2 | Persist selected escope in the local thread state (sessionStorage); re-apply on reload. |
| 3 | Add `escope` to the request payload sent to `/api/?call=ask`. |
| 4 | Add the "veure procés" / "see the process" toggle that reveals `meta.two_pass_first_draft` inline as a collapsed `<details>`. |
| 5 | Update tooltips per §9.2 (CA + EN). |
| 6 | Update the system prompt fingerprint shown in debug mode to include the active modifier. |

### Phase 1.5.c — Documentation and demo (0.5 day)

| Step | Detail |
|---|---|
| 1 | Update `arkadium.ai/docs/agent.md` (public API doc) with the `escope` parameter. |
| 2 | Update OpenAPI schema (`arkadium.ai/subdomains/api/httpdocs/openapi.json`) and Redoc / Swagger views. |
| 3 | Add a fourth column to the demo at `arkadium.ai/demo/`: `escope=−1` (general). The current B / D columns can stay or be replaced — owner decides during Phase 3 visual review. |

### Phase 1.5.d — Empirical validation (1-2 days post-deployment)

| Step | Detail |
|---|---|
| 1 | Run the harness in production for 5 escope-tagged queries from real users (after at least 24 h of usage). |
| 2 | Compute `wisdom_score_v2` on each response and on its first-pass draft (when applicable). Confirm that the polished response does not regress on 𝓦. |
| 3 | If 𝓦(polished) < 𝓦(draft) − 0.10 in any case, investigate whether the polish is removing load-bearing dialectical signal. |

---

## 12. Open questions

1. **Polish removing dialectical signal**. The polish instruction explicitly tells the model to remove codes and scaffolding. There is a risk that it also removes the *substance* the codes were proxying. The harness's first-pass / second-pass diff should be inspected by an annotator who reads only the second pass and rates whether the dialectical work feels present. If not, the polish instruction needs to be tightened.

   **Update 2026-05-08 (post-deployment of Phase 1.5.a)**: live tests confirmed that re-verifying 𝓦 on the polished response drops the score to ~0 — the polish removes by design the visible cardinal codes, mediator names and section headings that 𝓦 v2 is built to detect. The deployed implementation therefore exposes the **draft** wisdom score as the user-facing 𝓦, and the polished score under `meta.polished_wisdom_score` for analysis. This is the right call: 𝓦 is meant to verify that the dialectical work *happened*, not that it is *visible* on the surface. The first-draft is where the work happens; the polish is rendering. The next step (separate from this work) is an embedding-based 𝓦 successor that can detect the dialectical work in scaffolding-free prose; documented at §7.3 of the wisdom-score-design doc and at §11.2 of the paper.

2. **𝓦 v2 mismatch with `escope = −1`**. The `MODIFIER_GENERAL` block forbids cardinal-coded headings and demotes explicit code citations. As a result the *draft* itself for `escope = −1` already lacks the visible signals 𝓦 v2 measures, so even the draft score is low (live test 2026-05-08: Q "Què és la dignitat humana?" → 𝓦_draft = 0.20 for `escope = −1` vs 𝓦_draft = 0.74 for `escope = 0`). This is **not a bug of the metric or the modifier individually** — they are simply mismatched: 𝓦 v2 trains the LLM to make scaffolding visible; `escope = −1` trains it to keep the scaffolding invisible. The honest reading is: for `escope = −1`, 𝓦 v2 is not the right verifier. Phases 4–5 of the wisdom-score roadmap (re-prompt threshold tuning + human eval) need to **disable 𝓦-driven re-prompt for escope = −1** until an embedding-based 𝓦 successor exists. Logged for Phase 4.
2. **Threshold for re-prompt loop on `escope = +1`**. The re-prompt loop currently fires on `𝓦 < 0.6` with v2 weights. Under focal mode, `coverage` and `synthesis_anchoring` are weighted higher (per §7); the threshold may need re-tuning. Defer to Phase 4 of wisdom-score-design.
3. **Per-escope embedding direction in RAG**. §6 sketches a re-ranking by `generacio`; the right answer may instead be **per-escope query expansion** (general mode → expand the query toward the principle level via category-arrow walking; focal mode → expand toward specific cases). Defer to v0.2.
4. **UI footprint**. Three buttons add visual weight to the input. An alternative is an inline marker the user can type (`/general`, `/focal`) that defaults to balanced. Two-button toolbar on hover may be cleaner. Owner decides during Phase 1.5.b.
5. **Mode persistence per thread vs per message**. §9.1 proposes per-thread persistence (last-used wins). An alternative is **mode per message** with explicit reselection each time. Defer empirical answer to post-deployment.
6. **Multilingual coverage**. CA + EN are in scope. The polish instruction itself works in any language the LLM speaks well; the modifier blocks are written in English but instruct the LLM to *respond in the user's language*. This needs verification: a CA response with an EN-encoded modifier should remain in CA register, including idiom. To test in the harness expansion of §1.1.

---

## 13. Decision required

Before Phase 1.5.a begins, the project owner (Jordi) should confirm:

- [x] **escope parameter with 3 presets `{-1, 0, +1}`** as defined: confirmed 2026-05-08.
- [x] **default `escope = 0`** with two-pass active: confirmed 2026-05-08.
- [x] **scope CA + EN only** (ES dropped): confirmed 2026-05-08 (matches wisdom-score-design §3.4 decision).
- [ ] **Token budget per escope**: 2048 for `−1` and `0`, 3072 for `+1`. Accept / propose alternative.
- [ ] **UI mode persistence**: per-thread vs per-message. Default proposed: per-thread.
- [ ] **`meta.two_pass_first_draft` exposed via `<details>` toggle**: yes / hide entirely / dev-only.
- [ ] **Implementation order**: Phase 1.5.a (server) → Phase 1.5.b (frontend) → Phase 1.5.c (docs) → Phase 1.5.d (validation). Accept / re-order.
- [ ] **Defer §6 (RAG modulation) and §7 (𝓦 reweighting) to v0.2**: yes / fold into v0.1.

Once confirmed, Phase 1.5.a can start the same day. Estimated time to user-visible deployment (Phase 1.5.b complete): 2-3 working days.

---

## 14. Relation to the Arkadium paper and to wisdom-score-design

**To wisdom-score-design**: this doc adds a **modulator** above the existing v2 metric and prompt, not a replacement. The `wisdom-score-design.md` §5.2 (replacement prompt) becomes the **`escope = 0`** behaviour; §3bis (v2 components) remain valid; §6 implementation phases gain a Phase 1.5 between Phase 1 and Phase 4.

**To the Arkadium paper**: escope is the user-facing operationalisation of the radial axis (PLA-MON) of the Meta-Globàlium model. Until now, the paper described the radial axis as ontological structure. With escope, it becomes a control surface — the user adjusts which layer of the model their query is privileged in. This is a small but real strengthening of the paper's "model-as-interface" claim and should be added to §5 (canonical ontological directions) and §9.5 (live demonstration).

---

*End of design v0.1. Next revision: post Phase 1.5 deployment data.*