psyclaw 0.27.22 → 0.28.0

package/vendor/ars/shared/references/human_subjects_authority_protocol.md

@@ -0,0 +1,274 @@
+# Human-Subjects Authority Selection and Resolution Protocol (#666)
+
+This protocol governs exact authority selection and deterministic applicability
+tracing. It is not a committee, legal opinion, authorization, compliance result,
+submission-readiness result, or review-pathway result.
+
+Canonical artifacts:
+
+- `shared/contracts/human_subjects/irb_context_record.schema.json`
+- `shared/contracts/human_subjects/authority_profile_registry.schema.json`
+- `shared/contracts/human_subjects/resolved_authority_context.schema.json`
+- `shared/human_subjects_authority_registry.json`
+- `scripts/resolve_human_subjects_authority.py`
+- `docs/design/2026-08-09-666-human-subjects-authority-contract-spec.md`
+
+The schemas are authoritative for field names and local shape. This protocol
+governs cross-artifact use.
+
+## Two axes and bounded profiles
+
+V1 has exactly two axes: `review_ethics` and `data_protection`. A study may select
+multiple profiles on either axis. Funder and institutional requirements are
+overlays, never axes.
+
+Every shipped profile carries `coverage_status=bounded_subset` and
+`no_completeness_claim=true`:
+
+- `us.hhs.45-cfr-46.subpart-a`
+- `tw.mohw.human-subjects-research-act`
+- `eu.gdpr.research-core-bounded`
+
+Profiles contain curator summaries and primary-source links, not a claim of
+complete law or legal advice. Do not vendor unlicensed normative text.
+
+## Author declaration
+
+The context record uses:
+
+- `context_record_id`
+- `confirmed_by=author`
+- `confirmed_at`
+- `applicability_as_of`
+- `scope_dimensions`
+- typed `declared_facts`
+- `profile_selection_state` and exact `selected_profiles`
+- `overlay_selection_state` and exact `selected_overlays`
+- `display_precedence`
+
+Do not infer any of these from locale, language, affiliation, filenames,
+manuscript text, or model memory.
+
+Each selected profile pins axis, id, version, digest, and authority scope ids.
+Each selected overlay pins kind, axis, id, version, and digest. Unknown or
+mismatched pointers fail; never choose a latest version automatically.
+
+An empty scope-dimension list is unknown, not confirmed absence. A missing fact or
+a fact with `state=unknown` and `value=null` is `unknown`, never false.
+`overlay_selection_state=not_provided` is distinct from
+`none_declared_by_author`.
+
+## Predicate evaluation
+
+Registry predicates are a closed recursive AST with only:
+
+- `fact_equals`
+- `fact_in`
+- `fact_contains`
+- `all`
+- `any`
+- `not`
+
+Facts must resolve through `fact_definitions`, and declared value types must agree
+with the catalogue. Do not execute string expressions or add profile-specific
+branches.
+
+`fact_equals` and `fact_in` accept scalar boolean, string, string-enum, or date
+facts only, and every date operand must be a real ISO 8601 calendar date.
+`fact_contains` means exact membership in a `string_set`; it never performs
+substring matching on a string. V1 has no string-set equality operator.
+
+Use Strong Kleene logic:
+
+- missing or unknown fact leaf → `unknown`;
+- `all`: false if any false, true if all true, otherwise unknown;
+- `any`: true if any true, false if all false, otherwise unknown;
+- `not(true)=false`, `not(false)=true`, `not(unknown)=unknown`.
+
+A selected profile whose predicate is false emits `PROFILE_SCOPE_CONFLICT`; an
+unknown predicate emits `APPLICABILITY_UNRESOLVED`. Both block the downstream
+gate, and the resolver does not assert legal non-applicability.
+Requirement predicate results remain `true | false | unknown` and never become a
+compliance conclusion.
+
+## Authority provenance
+
+Source records separately record `canonical_url`, `snapshot_url`,
+`provision_locator`, closed `allowed_provisions`, `effective_from`, `effective_until`,
+`source_amended_or_published_date`, `retrieved_at`, `verified_at`,
+`source_language`, `controlling_language`, `authenticity_status`,
+`content_digest`, `digest_scope`, `rights_status`, and `freshness`. Row-local
+`authority_anchor` records use their schema-defined counterparts, including
+`authority_url`, `provision`, and `effective_date`.
+
+The anchor source must occur in its profile or overlay `source_ids`; its
+`provision` must occur in that source's `allowed_provisions`; and its
+`effective_date` must equal the source's provision-specific `effective_from`.
+
+Never infer an effective date from an amendment date. For Taiwan, the page's
+amendment date belongs in `source_amended_or_published_date`; it is not, without a
+separate controlling-authority basis, the profile's `effective_from` or a
+requirement's `effective_date`. Keep the controlling Chinese source distinct from
+the official English reference translation.
+
+Future-effective, expired, stale, unverified, superseded, or
+non-controlling-translation-only authority produces
+`AUTHORITY_SOURCE_NOT_CURRENT`. Runtime resolution is offline; it never refreshes
+these records from the network.
+
+## Requirements and overlays
+
+Every requirement identifies its axis, obligated actor, consumer scopes,
+applicability AST, structured expectations, expected evidence and holder,
+waiver/exception route, authoritative decision maker, collision metadata, and
+full authority anchor.
+
+Consumers must respect `obligated_actor` and `consumer_scopes`. Committee
+composition evidence held by an IRB is not an investigator packet requirement.
+A profiled exception route records only that a route exists; it never means the
+route was applicable, requested, or granted.
+
+Overlays use exact `target_profiles` id/version/digest pointers. Their operation is
+`add`, `supplement`, or `conflict`, and `requirements_removed` is always false.
+They cannot replace a base profile, delete a base row, fill an unresolved axis, or
+introduce a funder axis.
+
+Every target profile must be selected exactly. An overlay inherits the Strong
+Kleene `all` of all target-profile applicability results; each overlay requirement
+combines that inherited result with its own predicate using Strong Kleene `all`.
+If any target is false or unknown, emit `OVERLAY_BASE_UNRESOLVED`, preserve that
+tri-state result on the overlay requirements, and keep the downstream gate closed.
+
+## Display-only precedence and collisions
+
+`display_precedence` and resolved `trace_order` are presentation order only.
+Every precedence entry says `display_only_no_suppression`.
+
+Changing display order must not change selected authorities, predicate results,
+unresolved reasons, downstream gates, collision membership, or requirement
+accounting. Every requirement result appears exactly once in `trace_order`.
+
+Requirements sharing a collision key remain parallel with
+`parallel_authorities_require_human_resolution` and
+`requirements_removed=false`. Never average or deduplicate different
+jurisdictions or the two independent axes.
+
+## Resolver procedure
+
+1. Read only the explicitly supplied context and registry JSON files.
+2. Reject duplicate JSON keys, non-finite values, and unknown fields.
+3. Validate the context and registry schemas.
+4. Recompute and match every selected profile/overlay id, version, and digest.
+5. Resolve authority scopes and exact overlay targets without fallback.
+6. Require selected base profiles on both axes.
+7. Validate source interval, freshness, language, authenticity, digest, and rights
+   metadata at `applicability_as_of`.
+8. Evaluate every profile and requirement AST using Strong Kleene logic.
+9. Account for every selected requirement exactly once.
+10. Preserve all collisions and build display-only `trace_order`.
+11. Emit the pointer-only resolved artifact and canonical digests; compute
+    `resolved_digest` with its own field excluded.
+
+The resolver does not read manuscripts, scan sibling files, access the network,
+judge prose, decide legal applicability, or render a user-facing brief.
+
+## Pointer-only result and gate
+
+The resolved artifact carries a `context_pointer` and `registry_pointer`; it does
+not embed either input. Profile, overlay, requirement, and authority-anchor data
+are represented through schema-defined pointers and digests.
+
+Its states are `resolved`, `jurisdiction_unresolved`, and
+`applicability_unresolved`. Its closed unresolved codes are:
+
+- `JURISDICTION_UNRESOLVED`
+- `APPLICABILITY_UNRESOLVED`
+- `OVERLAY_BASE_UNRESOLVED`
+- `AUTHORITY_SOURCE_NOT_CURRENT`
+- `PROFILE_SCOPE_CONFLICT`
+
+Each unresolved reason contains exactly `code`, `axis`, nullable `authority_id`,
+and nullable `requirement_id`. It contains no prose or free-text detail. A
+requirement-level reason identifies its requirement; profile-, overlay-, and
+missing-axis reasons use `requirement_id=null`.
+
+The downstream gate contains exactly:
+
+```json
+{
+  "both_axes_selected": true,
+  "exact_selection_resolved": true,
+  "all_applicability_resolved": true,
+  "profile_dependent_result_allowed": true
+}
+```
+
+Only `resolution_state=resolved` may set all four true. A resolved result contains
+at least one selected profile on each axis, every selected profile has
+`applicability=true` and `source_state=current`, and no requirement applicability
+is unknown. Either unresolved state requires an unresolved reason and forces
+`profile_dependent_result_allowed=false`. A profile or overlay on one axis never
+cures a missing base profile on the other.
+
+Before consuming a serialized result, call
+`validate_resolved_context(result, context, registry)`. It validates the bound
+inputs, deterministically replays resolution, recomputes `resolved_digest` with
+that field excluded, and requires exact object equality. The replay checker—not
+JSON Schema alone—owns semantic uniqueness across rows, JSON Pointer resolution,
+digest-to-input binding, and gate derivation.
+
+## Consumer boundary
+
+- #667 consumes a serialized authority result only after
+  `validate_resolved_context(result, context, registry)` succeeds and the
+  profile-dependent gate is open. It filters to `submission_packet`, preserves
+  exact requirement and authority-anchor pointers, and then uses only the
+  closed `evidence_expected` fields `evidence_id`, `held_by`, and
+  `artifact_type` for status derivation. It never interprets, evaluates, or copies
+  `structured_expectations` or an evidence description; exact whole-row bytes are
+  canonical-hashed only for replay integrity. Content-coverage questions belong
+  to #681.
+- #681 consumes authority rows only through a #667 manifest that has first been
+  replay-validated against this same context/registry/resolved triplet and its
+  exact packet inventory/root. It may then dereference exact
+  `structured_expectations[]` pointers and join separately session-held content
+  through `shared/references/authority_content_coverage_advisory_protocol.md`.
+  Its carrier is always `LLM-ADVISORY` and `UNMEASURED`; it cannot alter
+  applicability, deterministic packet status, readiness, caller authorization,
+  institutional acceptance, or any authority pointer/digest.
+- #668 remains valid in `artifact_agnostic` mode and no profile may rewrite its
+  source correspondence or committee authority.
+- #669 consumes every selected-profile requirement scoped to `pathway_trace`
+  only after exact #666 replay, then projects exact fact occurrences,
+  authoritative-decision-maker role ids, and authority anchors under
+  `shared/references/review_pathway_rule_trace_protocol.md`. Its caller-owned
+  candidate names and ordering are display-only; the trace never determines,
+  predicts, ranks, approves, clears, exempts, authorizes, or gates. A missing
+  profile preserves `JURISDICTION_UNRESOLVED`. The protocol's narrow display of
+  requirement-level unknown predicates does not open or alter this resolver's
+  `profile_dependent_result_allowed` gate.
+- #680 owns correction and migration of mixed-jurisdiction reference prose.
+
+#666 itself changes no user-facing output. It emits no verdict, pathway,
+readiness, authorization, conformance result, or timeline. The #665 independent
+status grammar and fixed non-authorization footer remain unchanged.
+
+## #667 capability-envelope facts
+
+The registry also catalogs seven author-declared booleans used only to decide
+whether the deterministic submission-packet checker is within its V1 technical
+capability envelope:
+
+- `packet_v1.non_clinical=true`
+- `packet_v1.single_institution=true`
+- `packet_v1.competent_adults_only=true`
+- `packet_v1.biospecimens_involved=false`
+- `packet_v1.regulated_clinical_trial=false`
+- `packet_v1.cross_border_material_transfer=false`
+- `packet_v1.multisite_reliance=false`
+
+These facts are not legal characterizations and cannot select an authority,
+satisfy an axis, or change a profile or requirement digest. A missing, unknown,
+or non-matching value makes #667 return `APPLICABILITY_UNRESOLVED`; it never
+means that an authority is legally inapplicable. The complete #667 contract is
+`shared/references/submission_packet_manifest_protocol.md`.

package/vendor/ars/shared/references/intent_clarification_protocol.md

@@ -0,0 +1,168 @@
+# Intent Clarification Protocol (v3.9.2)
+
+**Spec:** v3.9.2 hot-fix per `docs/design/2026-05-18-ars-v3.9.2-phase-boundary-spec.md`
+**Issue:** #133 (phase scope inflation hot-fix)
+**Forward note:** v3.10 active conductor (#134) will replace this clarification gate with structured intake + task envelope dispatch. v3.9.2 ships clarification-only as interim.
+
+## Purpose
+
+When ARS receives input that does not unambiguously identify the intended workflow, the main session **clarifies before dispatching any agent**. Auto-routing to a single-phase agent on cross-phase materials caused #133 (silent scope inflation).
+
+This protocol defines:
+
+1. When clarification fires (3 trigger classes)
+2. How the clarification message is structured (a-d options in markdown body, NOT AskUserQuestion tool)
+3. How the `[direct-mode]` escape hatch works
+4. Worked examples
+
+## Trigger condition table
+
+| Condition | Routing class | Action |
+|---|---|---|
+| User invokes `/ars-*` slash command | Explicit | Route directly to named skill; no clarification |
+| User uses unambiguous trigger keyword (e.g., "lit-review this", "review my paper") | Explicit | Route directly to matching skill; no clarification |
+| User provides materials spanning ≥ 2 pipeline phases (e.g., abstract + literature, draft + reviewer comments + bibliography) | Cross-phase ambiguous | **Clarify** with a-d options |
+| User provides no materials and no clear request | No materials ambiguous | **Clarify** with a-d options |
+| User's first message begins with `[direct-mode]` (byte-0, case-insensitive) | Escape hatch | Strip prefix, skip clarification, route to whatever single agent matches the literal trigger; if no match, fall back to Explicit handling on the stripped message |
+
+## Pipeline phase reference (for "cross-phase materials" detection)
+
+| Phase | Typical artifact | File markers (heuristic) |
+|---|---|---|
+| 1 — Scoping | Research Question Brief, Methodology Blueprint | `phase1_*/` directory; `rq_brief.md`; `methodology.md` |
+| 2 — Investigation | Annotated Bibliography, source list, literature_corpus passport entries | `phase2_*/`; `annotated_bib.md`; `literature.{yaml,json}`; `references.bib`; folders of PDFs |
+| 3 — Analysis / Synthesis | Synthesis Report, claim-evidence mapping | `phase3_*/`; `synthesis.md` |
+| 4 — Composition | Full draft, abstract, report body | `phase4_*/`; `draft.md`; `abstract.md` (or 5b for academic-paper) |
+| 5 — Review | Editorial decision letter, reviewer comments, ethics report | `phase5_*/`; `review_*.md`; `editorial_decision.md` |
+| 6 — Revision | Revision Roadmap, R&R response letter, revised draft | `phase6_*/`; `revision_roadmap.md`; `response_letter.md` |
+| 0 / 7 / Plan | Intake config, format conversion, Socratic plan | `phase0_*/`; `phase7_*/`; Plan mode mid-conversation |
+
+"Cross-phase" = the user-provided materials, taken together, would correspond to artifacts from ≥ 2 of these phases. Examples:
+
+- Abstract + literature = Phase 4 + Phase 2 → cross-phase, clarify
+- Draft + reviewer comments = Phase 4 + Phase 5 → cross-phase, clarify
+- Literature only = Phase 2 → single-phase, no clarification needed
+- Reviewer comments only = Phase 5 → single-phase, no clarification needed
+
+## Clarification message template
+
+When clarification fires, the main session emits a message in this shape (markdown body, multi-select a-d format per `feedback_telegram_conversation_style.md` discipline):
+
+```markdown
+I see you've provided <summary of materials>. To route correctly, could you confirm which workflow you want?
+
+(a) **Full pipeline** — go from materials through to a complete deliverable (research + write + review + revise). Use `academic-pipeline` orchestrator (`/ars-full`).
+(b) **<phase-specific workflow 1>** — <one-line description>. Use `<skill>` (`/ars-<mode>`).
+(c) **<phase-specific workflow 2>** — <one-line description>. Use `<skill>` (`/ars-<mode>`).
+(d) **Something else** — let me know what you're trying to do.
+
+Pick a-d, or describe the target deliverable. If you want me to dispatch a specific agent directly without this clarification, prefix your message with `[direct-mode]`.
+```
+
+**Discipline rules:**
+
+- 3-4 candidate options + open "something else"; never more than 4 (avoid choice paralysis)
+- Each option names the destination skill / command so the user sees what gets invoked
+- Last sentence mentions `[direct-mode]` so the user knows the escape hatch exists
+- Do NOT call `AskUserQuestion` tool — options live in the markdown body of the chat response (per `feedback_no_askuserquestion_use_brainstorm.md`)
+
+## `[direct-mode]` escape hatch
+
+**Behavior:**
+
+- **Position:** Token must be the first non-whitespace token of the user's first message. Leading whitespace (spaces, tabs, newlines) is stripped on parse — `[direct-mode] ...`, `  [direct-mode] ...`, and `\n[direct-mode] ...` all qualify. Token appearing mid-message (after any non-whitespace character) does NOT qualify.
+- **Case:** Case-insensitive. `[direct-mode]`, `[Direct-Mode]`, `[DIRECT-MODE]` all accepted.
+- **Bracket form:** Only the literal `[direct-mode]` (square brackets, hyphen between words) is recognized. Variants like `(direct-mode)`, `<direct-mode>`, `[direct mode]` (space instead of hyphen), or `[directmode]` (no separator) are NOT recognized.
+- **Strip:** The literal `[direct-mode]` token (with surrounding whitespace) is stripped before any downstream agent sees the message. Dispatched agents receive only the post-strip content.
+- **Effect:** Bypasses Routing Discipline Step 2 (cross-phase clarification). Main session routes the stripped message via Step 1 (explicit-intent handling).
+- **Fallback:** If the stripped message itself has no clear skill named, Step 1 falls through to Step 3 clarification. (`[direct-mode]` is NOT a magic "always dispatch" flag — it bypasses cross-phase clarification, not all routing. If you want to bypass even ambiguous-intent clarification, you must name a specific skill or agent in the stripped message.)
+
+**Examples:**
+
+- `[direct-mode] /ars-lit-review on these papers` → dispatches academic-paper lit-review mode on the provided papers, no clarification
+- `[direct-mode] run bibliography_agent` → dispatches bibliography_agent directly
+- `[DIRECT-MODE] write me an abstract` → case-insensitive accepted; routes to abstract workflow without clarification
+
+**Anti-patterns (escape hatch NOT honored):**
+
+- `Please [direct-mode] dispatch X` — token not at byte-0 → ignored, clarification fires normally
+- `[direct mode] ...` — missing hyphen, not the literal token → ignored
+- `[direct-mode]` in second or later message of conversation — only first-message position counts
+
+## Worked examples
+
+### Example 1: cross-phase materials → clarify
+
+**User input:**
+> Here's an abstract and some literature, see what you can do.
+
+**Materials detected:** Abstract (Phase 4) + literature (Phase 2) → cross-phase.
+
+**Main session response:**
+> I see you've provided an abstract and a literature collection. To route correctly, could you confirm which workflow you want?
+>
+> (a) **Full paper from existing scaffolding** — use your abstract as paper seed, expand literature into bibliography, draft full paper, then review/revise. Use `academic-pipeline` (`/ars-full`).
+> (b) **Lit-review only** — produce an annotated bibliography matrix from the literature; don't touch your abstract. Use `academic-paper` (`/ars-lit-review`).
+> (c) **Quality-check the abstract against the literature** — verify abstract claims are supported by the cited sources. Use `academic-paper-reviewer` (`/ars-citation-check`).
+> (d) **Something else** — let me know what you're trying to do.
+>
+> Pick a-d, or describe the target deliverable. If you want me to dispatch a specific agent directly without this clarification, prefix your message with `[direct-mode]`.
+
+### Example 2: single-phase material → proceed
+
+**User input:**
+> Here's a folder of 30 PDF papers. Build me a lit-review on AI in medical imaging.
+
+**Materials detected:** Literature only (Phase 2). Explicit intent: lit-review.
+
+**Main session response:** Routes directly to `academic-paper /ars-lit-review` on the provided PDFs. No clarification fires (explicit intent overrides materials check).
+
+### Example 3: no materials + ambiguous → clarify
+
+**User input:**
+> Can you help me with my paper?
+
+**Materials detected:** None. Intent: ambiguous.
+
+**Main session response:**
+> Of course. To route correctly, could you tell me what stage you're at?
+>
+> (a) **I have an idea but no clear research question** — Socratic mode to clarify direction. Use `deep-research` (`/ars-plan`).
+> (b) **I have a question and need to do the research** — full research pipeline. Use `academic-pipeline` (`/ars-full`).
+> (c) **I have research notes and need to write the paper** — drafting pipeline. Use `academic-paper`.
+> (d) **I have a draft and want feedback** — peer-review simulation. Use `academic-paper-reviewer` (`/ars-review` equivalent).
+>
+> Pick a-d, or paste what you have so I can suggest a path.
+
+### Example 4: `[direct-mode]` honored
+
+**User input:**
+> [direct-mode] run bibliography_agent on these 30 PDFs
+
+**Stripped message:** `run bibliography_agent on these 30 PDFs`
+
+**Main session response:** Dispatches `bibliography_agent` directly with the PDFs as input. No clarification fires.
+
+### Example 5: `[direct-mode]` mid-message → NOT honored
+
+**User input:**
+> Hi, can you [direct-mode] just run bibliography_agent?
+
+**Token position:** Not byte-0. Escape hatch ignored.
+
+**Main session response:** Cross-phase or ambiguous check fires normally. May respond with clarification options.
+
+## When this protocol does NOT apply
+
+- **Within a skill that has already been routed.** If `academic-pipeline` is already running and the orchestrator is dispatching Phase 3 → Phase 4 internally, this protocol does not fire on every internal dispatch. It governs the **entry point** of an ARS session, not in-pipeline transitions.
+- **In-conversation follow-up.** After clarification resolves and a workflow starts, subsequent user messages within that workflow are interpreted by the active skill, not re-classified at the routing level. To re-route, the user starts a new session or uses `[direct-mode]` at the start of a new message.
+
+## v3.10 carry-over
+
+When the active conductor architecture (#134) ships, this protocol's logic moves into the conductor's intake stage with structured task envelope dispatch. The conductor will:
+
+- Classify intent deterministically with envelope schema rather than prompt-driven LLM judgment
+- Hold pipeline state across turns (so cross-phase materials in workspace are treated as ongoing project state, not "user-provided ambiguous input")
+- Eliminate the `[direct-mode]` escape hatch in favor of envelope-declared intent
+
+Until v3.10 ships, v3.9.2's prompt-driven clarification gate is the source of truth.

package/vendor/ars/shared/references/irb_terminology_glossary.md

@@ -0,0 +1,229 @@
+# IRB Terminology Glossary — Convention-Bound Data-Handling Language
+
+**Spec:** v3.6.7 §7.1 — pattern-protection reference for
+`research_architect_agent` (survey designer mode), Pattern B1.
+
+**Audience:** Agents drafting participant-facing consent/privacy language and
+human authors reviewing instrument drafts.
+
+**Status:** This is an ARS operational drafting convention. It is not a legal
+definition set, an authority-selection rule, or a review determination. A term
+is usable only with its named governing authority/convention, actor boundary,
+data state, and lifecycle. Different regimes can classify the same retained
+re-link key differently.
+
+**Why this exists:** Survey drafts often use Anonymity, Confidentiality,
+De-identification, and Pseudonymization as if they were interchangeable. That
+can make participant-facing statements inaccurate. This glossary keeps the
+facts visible while exact authority requirements remain in
+`shared/human_subjects_authority_registry.json`.
+
+---
+
+## Record the Operational Facts First
+
+Before choosing a term, record:
+
+1. every actor that collects, receives, stores, or can access the data,
+   including the survey platform, institution, research team, processors, and
+   recipients;
+2. direct identifiers, quasi-identifiers, free text, IP addresses, cookies,
+   device identifiers, timestamps, contact fields, and other metadata;
+3. whether a linkage/re-link key or other additional information is created,
+   who holds it, who can access both sides, and when it is destroyed or becomes
+   inaccessible;
+4. the purpose, disclosure boundary, security controls, retention, deletion,
+   reuse, transfer, publication, and withdrawal/deletion feasibility;
+5. the exact governing authority, institutional rule, or technical release
+   convention and the test it applies.
+
+Before describing an IP address or other metadata as absent from the collected
+record, verify the platform settings and actual data export/log behavior. If a
+platform collects metadata that researchers cannot access, say both facts; do
+not silently upgrade that scoped boundary to absolute anonymity.
+
+---
+
+## The Four Terms
+
+### Anonymity
+
+**ARS drafting convention (not a universal legal definition):** Within the
+explicitly named actor and lifecycle boundary, no identity-response link is
+created, retained, or reasonably recoverable. Use an absolute claim such as
+"anonymous to everyone" only when the platform/provider and every downstream
+actor are included in, and satisfy, that verified boundary.
+
+**Operational facts to support the wording:**
+
+- no direct identifier or respondent-specific contact field within the stated
+  boundary;
+- platform metadata collection and researcher access are stated accurately;
+- no code, token, or key available within the boundary can reconnect identity
+  and response;
+- quasi-identifier and free-text re-identification risks have been assessed
+  under a named project or institutional method.
+
+**Illustrative drafting template — populate only verified facts:**
+
+> "The research team does not ask for your name or contact details and cannot
+> link the exported response to you. The survey platform [does/does not/has not
+> been verified to] log IP addresses or device metadata; [state access,
+> retention, and recipient details]."
+
+**Drift to flag:** Calling a survey absolutely anonymous while collecting a
+follow-up email, retaining a researcher-accessible response code, or leaving
+platform metadata behavior unstated.
+
+### Confidentiality
+
+**ARS drafting convention (not a universal legal definition):** An identity or
+identity-response link may exist, while one or more named actors commit to
+bounded access, use, and disclosure. Confidentiality is a handling promise; it
+does not mean identifiers were never collected.
+
+**Operational facts to support the wording:**
+
+- identity/linkage holders and access roles are named;
+- purposes, recipients, exceptions/limits, and publication treatment are stated;
+- security, retention, deletion, reuse, and incident procedures match the
+  participant-facing promise.
+
+**Illustrative drafting template — populate only verified facts:**
+
+> "The research team will receive [identity/contact/linkage data]. Access is
+> limited to [roles] for [purposes]. Identified data will be retained until
+> [event/date] and then [verified disposition]. Reports will [describe actual
+> aggregation, quotation, or identification practice]."
+
+**Drift to flag:** Promising confidentiality without naming the actual
+collectors/access roles or while the planned publication and retention behavior
+contradicts the promise.
+
+### De-identification
+
+**Convention-bound working use:** Data has been transformed and evaluated under
+a **named** authority, institutional standard, or technical release test. This
+glossary does not define a universal point at which data becomes de-identified,
+and key destruction is not a cross-regime definition.
+
+**Operational facts to record:**
+
+- the named convention/test and the dataset/lifecycle stage to which it applies;
+- identifiers removed, transformed, retained, or separately held;
+- quasi-identifier and auxiliary-data attack assumptions;
+- any linkage/re-link code, custodian, access boundary, derivation, disclosure,
+  and destruction/inaccessibility state;
+- the method, evaluator, threshold, date, and residual-risk statement.
+
+**Illustrative unprofiled authority example:** Under the U.S. HIPAA Privacy Rule,
+[45 CFR 164.514(b)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514)
+describes Expert Determination and Safe Harbor routes, while
+[45 CFR 164.514(c)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514)
+permits a covered entity to assign a re-identification code subject to stated
+conditions. The effect of retaining a re-link key is therefore
+convention-specific and cannot be classified portably. HIPAA is not a profile
+in the current #666 registry; applicability and full requirements are
+`unprofiled` here.
+
+**Illustrative drafting template — populate the named convention and facts:**
+
+> "For [dataset/lifecycle stage], the team applied [named de-identification
+> convention/test] on [date]. [Identifiers and transformations]. A re-link code
+> [does/does not] remain; it is held by [actor] under [access/disclosure
+> conditions]. Residual risk was evaluated by [method/role] as [bounded result]."
+
+**Drift to flag:** Saying only "identifiers were removed," omitting the governing
+test, or assuming that the presence/absence of a key has the same legal effect
+under every regime.
+
+### Pseudonymization
+
+**GDPR authority-specific definition:**
+[GDPR Article 4(5)](https://eur-lex.europa.eu/eli/reg/2016/679/2016-05-04/eng)
+defines pseudonymisation for personal data by reference to processing that
+prevents attribution to a specific data subject without additional information,
+provided that additional information is kept separately and protected by
+technical and organisational measures. Because the definition concerns
+personal data, pseudonymised data is not treated as anonymous merely because a
+code replaced direct identifiers.
+
+Article 4(5) is a definitional anchor, not a separate requirement row in the
+current bounded registry. When the exact GDPR profile is selected and the
+applicability facts resolve true,
+`eu.gdpr.article-89.1.research-safeguards` points to the bounded Article 89(1)
+research-safeguards row, which records that pseudonymisation is assessed where
+the research purposes can be fulfilled that way. It does not assert that every
+study or every other regime uses the GDPR definition.
+
+**Operational facts to support GDPR-specific wording:**
+
+- the pseudonym/substitution method and the additional information needed for
+  attribution;
+- separate holders, storage, and access controls;
+- who can combine the dataset and additional information and for which purposes;
+- retention/destruction state and technical/organisational safeguards.
+
+**Illustrative drafting template — populate only verified facts:**
+
+> "For the selected GDPR context, the working dataset is pseudonymised. Direct
+> identifiers are replaced by [method]. The additional information needed to
+> reconnect the code to a participant is held separately by [actor], accessible
+> to [roles] for [purposes], and retained until [event/date]."
+
+**Drift to flag:** Calling GDPR-pseudonymised data anonymous, or applying the
+GDPR term to another authority without naming that authority's own convention.
+
+---
+
+## Quick Distinction Table
+
+| Term | Identity/re-link state under the stated boundary | What the wording communicates | Authority/convention status |
+|---|---|---|---|
+| **Anonymity** | No identity-response link within a precisely named and verified actor/lifecycle boundary | inability to link within that boundary | ARS drafting convention unless a selected authority defines it |
+| **Confidentiality** | Link may exist | limits on access, use, and disclosure | ARS drafting convention plus any selected authority/institutional terms |
+| **De-identification** | Depends on the named test; retained-key effect is convention-specific | transformation and bounded residual-risk result | name the governing authority or technical release convention |
+| **Pseudonymization** | Under GDPR, attribution requires separately kept additional information | a controlled but still personal-data state in the GDPR context | GDPR Article 4(5); other regimes must be named separately |
+
+---
+
+## Exact #666 Pointers for Participant/Data Language
+
+These identifiers are navigation pointers only. Use them only from an exactly
+selected, resolved profile and read the full row, obligated actor, predicate,
+consumer scopes, and authority anchor.
+
+| Drafting question | Exact bounded requirement pointer(s) |
+|---|---|
+| U.S. Common Rule participant consent | `us.45cfr46.116.informed-consent` |
+| Taiwan Human Subjects Research Act participant information | `tw.hsra.article-14.consent-information` |
+| GDPR lawful-basis record | `eu.gdpr.article-6.lawful-basis` |
+| GDPR special-category condition/safeguards | `eu.gdpr.article-9.special-category-research` |
+| GDPR information for direct collection | `eu.gdpr.article-13.direct-collection-information` |
+| GDPR information for collection elsewhere | `eu.gdpr.article-14.indirect-collection-information` |
+| GDPR scientific-research safeguards | `eu.gdpr.article-89.1.research-safeguards` |
+
+The registry does not currently profile HIPAA de-identification, a universal
+anonymity test, a universal confidentiality promise, or institution-specific
+release thresholds. Mark those bases `unprofiled` rather than fabricating a row
+or verdict.
+
+---
+
+## Where This Glossary Is Enforced
+
+The `research_architect_agent` survey designer mode requires consent/privacy
+language to pass through this glossary before output. The pattern-protection
+clause lives in `deep-research/agents/research_architect_agent.md` under
+`PATTERN PROTECTION (v3.6.7)`. Passing through the glossary means checking actual
+data flow and attaching the named convention; it does not establish legal
+applicability, compliance, review pathway, readiness, or authorization.
+
+---
+
+## Primary Sources and Local Authority Contract
+
+- `shared/references/human_subjects_authority_protocol.md` ([local protocol](human_subjects_authority_protocol.md)) — exact-selection, bounded-profile, pointer-only, and no-verdict contract.
+- [Curated #666 authority registry](../human_subjects_authority_registry.json) — requirement ids and row-local primary-source anchors.
+- [45 CFR 164.514](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514) — HIPAA de-identification and re-identification-code provisions; illustrative and unprofiled in #666.
+- [GDPR Articles 4(5) and 89](https://eur-lex.europa.eu/eli/reg/2016/679/2016-05-04/eng) — pseudonymisation definition and research-safeguards source; only the bounded Article 89(1) requirement is represented by `eu.gdpr.article-89.1.research-safeguards`.