',
+ seeded_db["public_post_id"],
+ ),
+ )
finally:
admin_conn.close()
@@ -1598,6 +2120,44 @@ def test_stale_summary_is_returned_labeled_when_orchestrator_is_unavailable(
assert body["korean_summary"] == "보관된 이전 계약 요약입니다."
+def test_stale_text_summary_refreshes_when_orchestrator_is_available(
+ client, demo_analyst_token, seeded_db, monkeypatch
+) -> None:
+ """A stale summary is continuity evidence, not a permanent cache entry."""
+ from lineageweave.post_summary import PostSummary
+
+ class _FakeSummaryClient:
+ available = True
+
+ def summarize(self, post_title: str, post_body: str) -> PostSummary:
+ return PostSummary(korean_summary="새 계약으로 갱신된 요약입니다.")
+
+ monkeypatch.setattr("backend.app.main._post_summary_client", lambda: _FakeSummaryClient())
+ admin_conn = psycopg2.connect(seeded_db["dsn"])
+ admin_conn.autocommit = True
+ try:
+ with admin_conn.cursor() as cur:
+ cur.execute(
+ "insert into post_summary_result "
+ "(post_id, korean_summary, summary_contract_version) values (%s, %s, %s)",
+ (
+ seeded_db["public_post_id"],
+ "보관된 이전 계약 요약입니다.",
+ POST_SUMMARY_CONTRACT_VERSION - 1,
+ ),
+ )
+ finally:
+ admin_conn.close()
+
+ response = client.get(
+ f"/api/posts/{seeded_db['public_post_id']}/summary",
+ headers={"Authorization": f"Bearer {demo_analyst_token}"},
+ )
+ assert response.status_code == 200, response.text
+ assert response.json()["korean_summary"] == "새 계약으로 갱신된 요약입니다."
+ assert response.json()["summary_status"] == "current"
+
+
def test_seed_demo_summary_surfaces_on_get_summary(client, demo_analyst_token, seeded_db) -> None:
"""The same helper `make seed` calls must produce a row GET summary
returns -- even with the orchestrator unset.
@@ -2141,7 +2701,7 @@ def test_related_keymen_includes_chronological_role_history(client, demo_analyst
)
cur.execute(
"insert into post_summary_role "
- "(post_id, actor_name, responsibility, actor_type_code, affiliated_organization_name, cataloged_person_id) "
+ "(post_id, actor_name, responsibility_text, actor_type_code, affiliated_organization_name, cataloged_person_id) "
"values (%s, %s, %s, %s, %s, %s)",
(
seeded_db["own_private_post_id"],
@@ -2154,7 +2714,7 @@ def test_related_keymen_includes_chronological_role_history(client, demo_analyst
)
cur.execute(
"insert into post_summary_role "
- "(post_id, actor_name, responsibility, actor_type_code, affiliated_organization_name, cataloged_person_id) "
+ "(post_id, actor_name, responsibility_text, actor_type_code, affiliated_organization_name, cataloged_person_id) "
"values (%s, %s, %s, %s, %s, %s)",
(
seeded_db["public_post_id"],
@@ -3338,6 +3898,150 @@ def answer(self, question: str, sources) -> ChatAnswer:
assert "What happened here that no seed already answers?" in events[0]["summary"]
+def test_live_chat_provider_error_does_not_leak_raw_error(
+ client, demo_analyst_token, seeded_db, monkeypatch
+) -> None:
+ """A provider exception becomes a stable 503 without its raw message."""
+ class _FailingChatClient:
+ available = True
+
+ def answer(self, question: str, sources) -> object:
+ raise Exception("raw-provider-secret")
+
+ monkeypatch.setattr("backend.app.main._post_chat_client", lambda: _FailingChatClient())
+
+ response = client.post(
+ f"/api/posts/{seeded_db['own_private_post_id']}/chat",
+ json={"question": "What happened in this provider failure case?"},
+ headers={"Authorization": f"Bearer {demo_analyst_token}"},
+ )
+
+ assert response.status_code == 503
+ assert "raw-provider-secret" not in response.text
+
+
+def test_global_ask_provider_error_does_not_leak_raw_error(
+ client, demo_analyst_token, seeded_db, monkeypatch
+) -> None:
+ """The cross-post Ask boundary also returns a stable provider failure."""
+ class _FailingAskClient:
+ available = True
+
+ def answer(self, question: str, sources) -> object:
+ raise Exception("raw-global-provider-secret")
+
+ monkeypatch.setattr("backend.app.main._post_chat_client", lambda: _FailingAskClient())
+
+ response = client.post(
+ "/api/ask",
+ json={"question": "What happened in this global failure case?"},
+ headers={"Authorization": f"Bearer {demo_analyst_token}"},
+ )
+
+ assert response.status_code == 503
+ assert "raw-global-provider-secret" not in response.text
+
+
+def test_keymen_provider_error_does_not_leak_raw_error(
+ client, demo_analyst_token, seeded_db, monkeypatch
+) -> None:
+ """Keymen provider failures become a stable 503 at the API boundary."""
+ _grant_post_admin(seeded_db["dsn"])
+
+ class _FailingKeymanClient:
+ available = True
+
+ def extract(self, post_title: str, post_body: str) -> object:
+ raise Exception("raw-keyman-provider-secret")
+
+ monkeypatch.setattr("backend.app.main._keyman_extraction_client", lambda: _FailingKeymanClient())
+
+ response = client.post(
+ f"/api/posts/{seeded_db['own_private_post_id']}/extract-keymen",
+ headers={"Authorization": f"Bearer {demo_analyst_token}"},
+ )
+
+ assert response.status_code == 503
+ assert "raw-keyman-provider-secret" not in response.text
+
+
+def test_evaluation_provider_error_does_not_leak_raw_error(
+ client, demo_analyst_token, seeded_db, monkeypatch
+) -> None:
+ """Evaluation provider failures become a stable 503 at the API boundary."""
+ _grant_post_admin(seeded_db["dsn"])
+
+ class _FailingEvaluationClient:
+ available = True
+
+ def evaluate(self, post_title: str, post_body: str) -> object:
+ raise Exception("raw-evaluation-provider-secret")
+
+ monkeypatch.setattr(
+ "backend.app.main._post_evaluation_client", lambda: _FailingEvaluationClient()
+ )
+
+ response = client.post(
+ f"/api/posts/{seeded_db['own_private_post_id']}/evaluate",
+ headers={"Authorization": f"Bearer {demo_analyst_token}"},
+ )
+
+ assert response.status_code == 503
+ assert "raw-evaluation-provider-secret" not in response.text
+
+
+def test_commitment_provider_error_does_not_leak_raw_error(
+ client, demo_analyst_token, seeded_db, monkeypatch
+) -> None:
+ """Commitment provider failures become a stable 503 at the API boundary."""
+ _grant_post_admin(seeded_db["dsn"])
+
+ class _FailingCommitmentClient:
+ available = True
+
+ def extract(self, post_title: str, post_body: str, reference_date: str) -> object:
+ raise Exception("raw-commitment-provider-secret")
+
+ monkeypatch.setattr(
+ "backend.app.main._commitment_extraction_client", lambda: _FailingCommitmentClient()
+ )
+
+ response = client.post(
+ f"/api/posts/{seeded_db['own_private_post_id']}/derive-commitment",
+ headers={"Authorization": f"Bearer {demo_analyst_token}"},
+ )
+
+ assert response.status_code == 503
+ assert "raw-commitment-provider-secret" not in response.text
+
+
+def test_summary_enrichment_provider_error_does_not_leak_raw_error(
+ client, demo_analyst_token, seeded_db, monkeypatch
+) -> None:
+ """Summary enrichment failures stay a stable 503 at the API boundary."""
+ from lineageweave.post_summary import PostSummary
+
+ class _FakeSummaryClient:
+ available = True
+
+ def summarize(self, post_title: str, post_body: str) -> PostSummary:
+ return PostSummary(korean_summary="합성 요약")
+
+ async def _fail_persist(*args, **kwargs):
+ raise Exception("raw-summary-provider-secret")
+
+ monkeypatch.setattr("backend.app.main._post_summary_client", lambda: _FakeSummaryClient())
+ monkeypatch.setattr("backend.app.main.persist_post_summary", _fail_persist)
+
+ response = client.get(
+ f"/api/posts/{seeded_db['own_private_post_id']}/summary",
+ headers={"Authorization": f"Bearer {demo_analyst_token}"},
+ )
+
+ assert response.status_code == 503
+ assert "raw-summary-provider-secret" not in response.text
+
+
def test_evaluate_is_unavailable_without_orchestrator(client, demo_analyst_token, seeded_db) -> None:
os.environ.pop("ORCHESTRATOR_BASE_URL", None)
os.environ.pop("ORCHESTRATOR_API_KEY", None)
@@ -4022,6 +4726,8 @@ def test_calendar_hides_other_corp_private_commitments_and_sorts_by_due_date(
assert commitments[0]["commitment_summary"] == "Send the revised quote"
assert "visibility_code" not in commitments[0]
assert "corporate_entity_id" not in commitments[0]
+ assert "author_account_id" not in commitments[0]
+ assert "source_detail_state_code" not in commitments[0]
def test_calendar_keeps_real_ticket_when_demo_code_is_shared(
@@ -4633,7 +5339,7 @@ def test_seed_period_report_member_click_lands_on_decorated_fixture(
client, demo_analyst_token, seeded_db
) -> None:
"""The first W02 report member must already have Event Lineage,
- Keyman, and evaluation -- otherwise the buyer click opens a dummy
+ Keyman, and evaluation -- otherwise the reader click opens a dummy
high/low band row.
"""
from lineageweave.fixtures import fixture_thread_cast, fixture_titles_in_iso_week
@@ -4688,6 +5394,21 @@ def test_seed_period_report_member_click_lands_on_decorated_fixture(
first = report["members"][0]
assert first["post_title"] in decorated, first["post_title"]
assert not first["post_title"].startswith(("High-band", "Low-band"))
+ assert not {
+ "visibility_code",
+ "corporate_entity_id",
+ "author_account_id",
+ "source_detail_state_code",
+ "has_real_source_context",
+ } & first.keys()
+ for pair in report.get("leftover_pairs", []):
+ assert not {
+ "visibility_code",
+ "corporate_entity_id",
+ "author_account_id",
+ "source_detail_state_code",
+ "has_real_source_context",
+ } & pair.keys()
threads = client.get("/api/reports/thread_group/2026-W02", headers=headers)
a100 = next(report for report in threads.json()["reports"] if report["grouping_key"] == "A-100")
diff --git a/backend/tests/test_auth_jwks.py b/backend/tests/test_auth_jwks.py
index 709d2c16e..b452f79e1 100644
--- a/backend/tests/test_auth_jwks.py
+++ b/backend/tests/test_auth_jwks.py
@@ -173,3 +173,50 @@ def test_decode_rejects_missing_subject(monkeypatch: pytest.MonkeyPatch) -> None
with pytest.raises(HTTPException) as error:
auth._decode_access_token("token", settings)
assert error.value.status_code == 401
+
+
+def test_oidc_provider_failure_does_not_cross_the_auth_boundary(
+ monkeypatch: pytest.MonkeyPatch,
+) -> None:
+ """Identity-provider transport details stay out of the HTTP response."""
+ def fail(*_args: object, **_kwargs: object) -> dict:
+ raise auth.HttpClientError("synthetic-provider-response")
+
+ monkeypatch.setattr(auth, "get_json", fail)
+ settings = SimpleNamespace(
+ oidc_issuer="https://id.example",
+ oidc_discovery_uri="https://id.example/.well-known/openid-configuration",
+ oidc_jwks_uri_override="",
+ )
+
+ with pytest.raises(HTTPException) as error:
+ auth._jwks(settings)
+
+ assert error.value.status_code == 503
+ assert error.value.detail == "could not fetch OIDC JWKS from the configured identity provider"
+ assert "synthetic-provider-response" not in str(error.value.detail)
+
+
+def test_invalid_token_detail_does_not_cross_the_auth_boundary(
+ monkeypatch: pytest.MonkeyPatch,
+) -> None:
+ """JWT library diagnostics stay server-side through exception chaining."""
+ monkeypatch.setattr(auth, "_signing_key", lambda settings, token: "signing-key")
+ monkeypatch.setattr(
+ auth.jwt,
+ "decode",
+ lambda *_args, **_kwargs: (_ for _ in ()).throw(
+ auth.jwt.InvalidTokenError("synthetic-token-diagnostic")
+ ),
+ )
+ settings = SimpleNamespace(
+ oidc_issuer="https://id.example",
+ oidc_audience="lineageweave-api",
+ oidc_clock_skew_seconds=5,
+ )
+
+ with pytest.raises(HTTPException) as error:
+ auth._decode_access_token("token", settings)
+
+ assert error.value.status_code == 401
+ assert error.value.detail == "invalid access token"
diff --git a/docker-compose.yml b/docker-compose.yml
index 96ec0b89a..c48783a3b 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -112,7 +112,7 @@ services:
# Gateway credentials and URL are supplied only by env_file (${HOME}/.env).
# Do not repeat them under environment:, where Compose interpolation can
# overwrite env_file values with an empty host-shell value.
- # The upstream default remains 64 KiB for ordinary text APIs. Buyer
+ # The upstream default remains 64 KiB for ordinary text APIs. Post
# image blocks are base64 data URIs, so the multimodal boundary gets an
# explicit bounded 8 MiB limit rather than an unbounded request size.
CONTEXTUAL_ORCHESTRATOR_MAX_BODY_BYTES: ${CONTEXTUAL_ORCHESTRATOR_MAX_BODY_BYTES:-8388608}
diff --git a/docker/keycloak/Dockerfile b/docker/keycloak/Dockerfile
index 69ebd26c5..049b0e975 100644
--- a/docker/keycloak/Dockerfile
+++ b/docker/keycloak/Dockerfile
@@ -1,5 +1,6 @@
FROM quay.io/keycloak/keycloak:26.0@sha256:09a381c715ab0b111835b70f2905955274843a219c6f27efb348e4d9f4086858
COPY realm-export.json /opt/keycloak/data/import/realm-export.json
+COPY themes/lineageweave /opt/keycloak/themes/lineageweave
# Official image's default non-root account (uid 1000). Declared so the
# Dockerfile itself satisfies DS-0002 (explicit non-root USER).
USER 1000
diff --git a/docker/keycloak/realm-export.json b/docker/keycloak/realm-export.json
index be9826ea4..4f1920575 100644
--- a/docker/keycloak/realm-export.json
+++ b/docker/keycloak/realm-export.json
@@ -1,6 +1,8 @@
{
"realm": "lineageweave-demo",
"enabled": true,
+ "displayName": "LineageWeave",
+ "loginTheme": "lineageweave",
"sslRequired": "none",
"registrationAllowed": false,
"accessTokenLifespan": 900,
diff --git a/docker/keycloak/themes/lineageweave/login/resources/css/lineageweave.css b/docker/keycloak/themes/lineageweave/login/resources/css/lineageweave.css
new file mode 100644
index 000000000..0ef285933
--- /dev/null
+++ b/docker/keycloak/themes/lineageweave/login/resources/css/lineageweave.css
@@ -0,0 +1,77 @@
+/*
+ * LineageWeave brand overrides for the stock keycloak.v2 login theme.
+ * Loaded after the parent's css/styles.css (see theme.properties), so
+ * these rules win the cascade without needing !important.
+ * Values mirror frontend/src/styles/tokens.css so the OIDC redirect stays
+ * visually continuous with the app's own pre-redirect login card
+ * (UI/UX Standard Guide Ver.3.0 SS3.2).
+ */
+
+.login-pf body {
+ background: #fff;
+ font-family:
+ "Noto Sans KR",
+ "Noto Sans",
+ "Nanum Gothic",
+ system-ui,
+ -apple-system,
+ BlinkMacSystemFont,
+ "Segoe UI",
+ Roboto,
+ sans-serif;
+}
+
+.pf-v5-c-login,
+.pf-v5-c-login__main {
+ font-family: inherit;
+}
+
+/*
+ * Parent styles.css sets #kc-header-wrapper's color with !important
+ * (a light/white token meant to sit on the dark polygon background we
+ * just removed). Match it with !important so the brand text is legible
+ * on our white background instead of rendering white-on-white.
+ */
+#kc-header-wrapper {
+ color: #034ea2 !important;
+ font-weight: 700;
+ text-transform: none;
+ letter-spacing: normal;
+}
+
+.pf-v5-c-login__main-body,
+.card-pf {
+ background: #fff;
+ border: 1px solid #e5e4e7;
+ border-radius: 12px;
+ box-shadow: 0 1px 4px rgba(0, 0, 0, 0.08);
+}
+
+.pf-v5-c-button.pf-m-primary {
+ background-color: #034ea2;
+ border-color: #034ea2;
+}
+
+.pf-v5-c-button.pf-m-primary:hover,
+.pf-v5-c-button.pf-m-primary:focus {
+ background-color: #0047bb;
+ border-color: #0047bb;
+}
+
+a,
+a:visited {
+ color: #034ea2;
+}
+
+div.kc-logo-text {
+ background-image: none;
+ height: auto;
+ width: auto;
+}
+
+div.kc-logo-text span {
+ display: inline;
+ color: #034ea2;
+ font-weight: 700;
+ font-size: 1.5rem;
+}
diff --git a/docker/keycloak/themes/lineageweave/login/theme.properties b/docker/keycloak/themes/lineageweave/login/theme.properties
new file mode 100644
index 000000000..442ab2fde
--- /dev/null
+++ b/docker/keycloak/themes/lineageweave/login/theme.properties
@@ -0,0 +1,4 @@
+parent=keycloak.v2
+import=common/keycloak
+
+styles=css/styles.css css/lineageweave.css
diff --git a/docker/postgres-init/migrate.sh b/docker/postgres-init/migrate.sh
index f329117d6..c7194e1b3 100644
--- a/docker/postgres-init/migrate.sh
+++ b/docker/postgres-init/migrate.sh
@@ -18,7 +18,7 @@ for migration in /opt/lineageweave/migrations/*.sql; do
migration_name=${migration##*/}
case "$migration_name" in
0012_*|0013_*|0014_*|0015_*|0016_*|0017_*|0018_*|0019_*|0020_*|0021_*|0022_*|0023_*|0024_*|0025_*|0026_*|0027_*|0028_*|0029_*|0030_*|0031_*|0032_*|0033_*|0034_*|0035_*|0036_*|0037_*|0038_*|0039_*|0040_*|0041_*|0042_*|0043_*|0044_*|0045_*|0046_*|0047_*|0048_*|0049_*|0050_*) ;;
- 0060_*|0100_*|0101_*|0102_*) ;;
+ 0060_*|0100_*|0101_*|0102_*|0103_*|0104_*|0105_*|0106_*|0107_*|0108_*|0109_*|0110_*|0111_*|0112_*|0113_*|0114_*|0130_*|0131_*|0132_*) ;;
*) continue ;;
esac
printf 'Applying %s\n' "$migration_name"
diff --git a/docs/adr/0002-figma-access-boundary.md b/docs/adr/0002-figma-access-boundary.md
index 90c213390..4d850afb3 100644
--- a/docs/adr/0002-figma-access-boundary.md
+++ b/docs/adr/0002-figma-access-boundary.md
@@ -4,6 +4,8 @@
**Date:** 2026-08-13
**Figma File ID:** `1Su3lDRmiZdcUs47t1QwIX`
**Figma File URL:** https://www.figma.com/design/1Su3lDRmiZdcUs47t1QwIX
+**Event Lineage desktop frame:** `5:14`
+**Event Lineage mobile frame:** `5:15`
## Context
@@ -40,9 +42,11 @@ statistic, or internal identifier observed while checking the file's
metadata is repeated anywhere in this repository, in code, in docs, or
in commit history.
-The newly created file identified above is the safe design-system boundary
-for LineageWeave's buyer surface. It currently contains no copied source
-organization content; future token or component work must keep that boundary.
+The separate Figma file identified above is the safe design-system boundary
+for LineageWeave's buyer surface. It contains only sanitized, synthetic
+LineageWeave content. Its local `LineageWeave / Buyer Surface Tokens`
+collection mirrors the checked-in light/dark CSS tokens rather than copying
+confidential source styles or values.
## Rationale
@@ -55,23 +59,66 @@ organization content; future token or component work must keep that boundary.
-- structurally mimicking it would risk reintroducing exactly the kind
of identification this project has otherwise been careful to avoid.
- Separately and independently of the confidentiality question: there is
- currently no actual popup/Event-Lineage frame in the file to build
+ currently no actual popup/Event-Lineage frame in the source file to build
against even if that concern didn't apply -- only a cover page exists.
-- Guessing a "close enough" layout and *calling it* Figma-matched would
- misrepresent a source that was neither consulted for its content nor
- (yet) contains the relevant screen.
+- Guessing a "close enough" layout and *calling it* source-Figma-matched would
+ misrepresent a source that was neither consulted for its content nor (yet)
+ contains the relevant screen. Sanitized LineageWeave-owned frames avoid that
+ claim while still providing an editable product design contract.
## Consequences
- The popup UI ships and is tested (both backend contract and frontend
- render logic) against the textual spec, not any Figma file content.
-- If the organization later adds the actual popup frame to a Figma file
- and wants a real design-to-code pass, that is a distinct, explicit
- follow-up -- likely still needing the same care ADR 0001 already
- established for identity/content (build the *mechanism* faithfully,
- keep any organization-identifying specifics out of the public repo).
-- This is consistent with, not an exception to, ADR 0001's reasoning --
- both ADRs name a real gap explicitly rather than fake or stall.
+ render logic) against the textual spec, not confidential source-file content.
+- The sanitized LineageWeave Figma file may hold buyer-surface tokens,
+ interaction states, and synthetic frames whose IDs are recorded in ADRs.
+- If the organization later adds the actual popup frame to the source Figma
+ file and wants a real design-to-code pass, that is a distinct, explicit
+ follow-up -- likely still needing the same care ADR 0001 already established
+ for identity/content.
+- This is consistent with, not an exception to, ADR 0001's reasoning -- both
+ ADRs name a real gap explicitly rather than fake or stall.
+
+## 2026-08-21 Event Lineage DAG refinement
+
+The buyer DAG remains a **reconstructed record/Event Lineage view**, not a
+complete OWL class/property explorer. Its horizontal position represents
+lineage depth, not elapsed time. The safe buyer-surface refinement therefore
+makes the existing meaning explicit instead of implying a different ontology
+product:
+
+- parent-to-child edges have visible arrowheads and stop outside node circles;
+- every node shows its source event date without pretending that X distance is
+ a duration scale;
+- deep graphs keep their deterministic layout width inside a keyboard-focusable
+ horizontal region rather than shrinking labels into unreadability;
+- the SVG is an accessible group, not an ARIA image that hides its interactive
+ descendant node controls;
+- an open-by-default, collapsible exact-value table preserves each visible
+ relation, source/target date, and fused reconstruction score for keyboard,
+ touch, print, and audit use;
+- a zero-edge group keeps its isolated root interactive without rendering an
+ empty evidence table; and
+- branching, selected-node, isolated-root, and empty states are represented
+ with synthetic fixtures in Storybook.
+
+The editable Figma contract uses the same synthetic `DEMO-PROJECT` thread as
+the product fixture and records two direct targets:
+
+- desktop: https://www.figma.com/design/1Su3lDRmiZdcUs47t1QwIX?node-id=5-14
+- mobile: https://www.figma.com/design/1Su3lDRmiZdcUs47t1QwIX?node-id=5-15
+
+Both frames show direction, visible dates, a non-causal inference notice, and
+the same exact `fused_score` evidence available in the implementation. The
+mobile frame makes horizontal inspection explicit and changes the table into
+stacked exact-value cards rather than shrinking the graph or clipping scores.
+No confidential frame or production record is copied.
+
+A future graph that renders `Post`, `Person`, `CorporateEntity`, `Project`,
+OWL properties, SKOS relations, provenance status, and temporal validity as
+heterogeneous nodes and edges is a separate ontology-explorer capability and
+must not be implied by this Event Lineage renderer. Buyer Gap #341 tracks that
+separate product slice.
## Related
diff --git a/docs/adr/0040-source-state-provenance.md b/docs/adr/0040-source-state-provenance.md
index 33c70e923..1bf743154 100644
--- a/docs/adr/0040-source-state-provenance.md
+++ b/docs/adr/0040-source-state-provenance.md
@@ -33,3 +33,30 @@ The product can inspect original state evidence without losing distinctions
between lifecycle dimensions. Until a source codebook is provided, users see
codes rather than invented labels and the Board remains complete rather than
silently excluding records.
+
+## Product display mapping
+
+For the current Board workflow, the product owner supplied a display
+interpretation for the observed detail-state codes:
+
+- `W` — Writing in progress (`작성 중`)
+- `D` — Pending approval (`결재 중`)
+- `A` — Approved (`결재 완료`)
+
+This is a reader-facing explanation, not a rewrite of the raw source field or
+an assertion that the source system's full codebook has been verified. The API
+continues to return the raw code, unknown codes remain visible as unmapped, and
+`source_draft_code` remains a separate signal. The Board may filter by the raw
+detail-state code while showing this mapping beside it.
+
+## Writing-state access and derivation boundary
+
+W is an original-source record that is still being written. It is not a
+service target. The author account and post_admin may open the raw source
+record so the author can continue reviewing their own work, but W is excluded
+from all derived reads and writes: summaries, 5W1H, ontology/Keyman and
+relationship extraction, knowledge-graph projections, lineage, rankings,
+reports, calendar commitments, chat/Ask sources, and content-analysis
+projections. A persisted summary does not make W eligible; the API refuses
+analysis requests and the summary backfill query excludes W. D and A remain
+the service summary targets.
diff --git a/docs/adr/0063-third-normal-form-bookmarks.md b/docs/adr/0063-third-normal-form-bookmarks.md
index 4ba2f5b4f..95a83fea7 100644
--- a/docs/adr/0063-third-normal-form-bookmarks.md
+++ b/docs/adr/0063-third-normal-form-bookmarks.md
@@ -14,7 +14,7 @@ attributes.
## Decision
-Use a `bookmark` table with:
+Use a `post_bookmark` table with:
- `bookmark_id` as the independent surrogate primary key;
- `user_account_id` as a foreign key to `user_account`;
@@ -25,10 +25,15 @@ Use a `bookmark` table with:
The composite account/post pair is therefore a business invariant only, never
the primary identity of the bookmark entity. No display name, post title, or
-authorization scope is duplicated in `bookmark`; those values remain in their
+authorization scope is duplicated in `post_bookmark`; those values remain in their
normalized source tables. Every read and write still performs the normal
visible-post ABAC check for the requesting account.
+The historical migration introduced this entity as `bookmark`; ADR 0120
+renames the persistent relation to `post_bookmark` to enforce the repository's
+two-word database-identifier rule. The entity and authorization decision stay
+unchanged.
+
## Consequences
- A bookmark has a stable identifier and remains in third normal form: every
diff --git a/docs/adr/0105-mathematical-script-semantic-normalization.md b/docs/adr/0105-mathematical-script-semantic-normalization.md
new file mode 100644
index 000000000..839c3c98c
--- /dev/null
+++ b/docs/adr/0105-mathematical-script-semantic-normalization.md
@@ -0,0 +1,29 @@
+# ADR 0105: Preserve explicit metric scripts in semantic text
+
+- Status: Accepted
+- Date: 2026-08-21
+
+## Context
+
+Source posts may encode a metric unit such as `m3` or an indexed
+quantity such as `m3`. Removing the script element loses searchable
+and buyer-visible mathematical meaning, while treating every numeric
+superscript as mathematics would break the existing footnote contract.
+
+## Decision
+
+1. Preserve the original source body unchanged.
+2. In derived semantic text, normalize only an explicit bounded metric base
+ (`m`, `cm`, `mm`, `km`, or `kg`, optionally preceded by a number) followed
+ by one-to-three numeric `sup` or `sub` elements into Unicode
+ superscript/subscript digits. For example, `5m3` becomes `5m³`.
+3. Leave ordinary numeric superscripts on prose under the existing footnote
+ role contract.
+4. Apply the same normalization in backend chunks and frontend rendering.
+
+## Consequences
+
+Metric exponents remain searchable and readable without inventing formula
+semantics. Arbitrary mathematical markup beyond this bounded case remains an
+explicit open gap and must be covered by a later ADR and fixture before being
+normalized.
diff --git a/docs/adr/0119-retire-buyer-terminology.md b/docs/adr/0119-retire-buyer-terminology.md
new file mode 100644
index 000000000..4124e1e0a
--- /dev/null
+++ b/docs/adr/0119-retire-buyer-terminology.md
@@ -0,0 +1,56 @@
+# ADR 0119: Retire "Buyer" as the reader-facing terminology
+
+**Status:** Accepted
+**Date:** 2026-08-21
+
+**Context:** ADR 0037 named the four-destination frontend shell the "Buyer
+GNB" and the term spread into component names (`BuyerNav`,
+`BuyerDestination`), CSS classes (`.buyer-gnb`), i18n keys ("Buyer
+navigation"), a visible legend label ("BUYER EVIDENCE"), Python identifiers
+(`_buyer_evidence_kind`), and prose across `AGENTS.md`, `ARCHITECTURE.md`,
+and docstrings. LineageWeave has no explicit buyer actor — it is an internal
+analyst/marketing-intelligence workspace, not a storefront with a buyer
+role. "Buyer" was a leftover label from early drafting, not a modeled
+domain entity, and reads as confusing or inaccurate to anyone reading the
+code or product surface.
+
+**Decision:**
+1. Rename the frontend navigation shell: `BuyerNav` → `WorkspaceNav`,
+ `BuyerDestination` → `WorkspaceDestination`, `.buyer-gnb*` CSS →
+ `.workspace-gnb*`, `.buyer-destination*` → `.workspace-destination*`,
+ the "Buyer navigation" i18n key/aria-label → "Workspace navigation", and
+ the `#mobile-buyer-navigation` id → `#mobile-workspace-navigation`.
+2. Rename the Event Lineage legend label "BUYER EVIDENCE" → "LINEAGE
+ EVIDENCE".
+3. Rename backend/Python identifiers that described the same concept:
+ `_buyer_evidence_kind` → `_cited_evidence_kind`,
+ `_buyer_evidence_text` → `_cited_evidence_text`.
+4. Replace prose that referred to "the buyer" as the person reading the
+ product with "the reader" (docstrings, comments, `AGENTS.md`,
+ `ARCHITECTURE.md`, living docs under `docs/`) or with "workspace" where
+ the prose named the navigation shell itself.
+5. Do not rewrite historical ADRs (0002–0118) or `CHANGELOG.md` /
+ `CHANGELOG.d/*.md` entries — those are point-in-time records of the
+ decisions and releases made under the terminology that existed then.
+ This ADR documents the rename going forward; historical documents keep
+ their original wording for an accurate record.
+6. Leave "buyer" where it appears as ordinary English inside simulated
+ post/table content (`lineageweave/fixtures.py`,
+ `tests/test_chunking.py`) — that is domain content a real sales note
+ could plausibly contain, not this project's own naming.
+
+**Consequences:**
+- No source, test, or living-doc identifier or user-facing string uses
+ "Buyer" going forward; `grep -ri buyer` outside historical ADRs,
+ `CHANGELOG*`, and fixture/test content returns nothing.
+- Historical ADRs and changelog entries remain internally consistent with
+ the PRs they describe; readers encountering "Buyer GNB" in ADR 0037 or
+ CHANGELOG 2.13.0 know it is the old name for what this ADR renames.
+- Component/file rename (`BuyerNav.tsx` → `WorkspaceNav.tsx`) is a breaking
+ change for any external Storybook story or import path that referenced
+ the old name; none exist outside this repo at the time of this ADR.
+
+**References:**
+- ADR 0037 (Buyer GNB and product-facing frontend surface) — superseded
+ terminology only, decision content unchanged.
+- ADR 0118 (UI·UX Standard Guide Ver.3.0 Design Overhaul)
diff --git a/docs/adr/0120-two-word-database-identifiers.md b/docs/adr/0120-two-word-database-identifiers.md
new file mode 100644
index 000000000..1849fe1c1
--- /dev/null
+++ b/docs/adr/0120-two-word-database-identifiers.md
@@ -0,0 +1,58 @@
+# ADR 0120: Normalize persistent database identifiers to two-word snake_case
+
+- Status: Accepted
+- Date: 2026-08-21
+- Supersedes: the single-token naming exception in ADR 0063 and the
+ single-token column names inherited by the analysis/report/content slices
+
+## Context
+
+The product standard requires every persistent database object name to use at
+least two lowercase `snake_case` words. The live schema still contains the
+legacy `bookmark` relation and several single-token columns. Keeping those
+names would make the database itself contradict the current product contract,
+even though the surrounding application and ADRs describe a normalized model.
+
+## Decision
+
+Migration `0104_two_word_database_identifiers.sql` renames only persistent
+database identifiers; it does not change payload semantics or public JSON
+field names:
+
+| Existing identifier | Canonical identifier |
+| --- | --- |
+| `bookmark` | `post_bookmark` |
+| `analysis_run_status_event.retryable` | `analysis_run_status_event.is_retryable` |
+| `post_content_image.caption` | `post_content_image.image_caption` |
+| `post_content_image_region.caption` | `post_content_image_region.image_caption` |
+| `post_content_unit_structure.confidence` | `post_content_unit_structure.structure_confidence` |
+| `post_project_mention.confidence` | `post_project_mention.mention_confidence` |
+| `post_summary_role.responsibility` | `post_summary_role.responsibility_text` |
+| `report_item_information.information` | `report_item_information.information_value` |
+| `report_item_parameter.slope` | `report_item_parameter.item_slope` |
+| `tenant_settings.id` | `tenant_settings.tenant_settings_id` |
+
+The `analysis_run_current_status` view is recreated with
+`is_retryable`. Application-facing JSON continues to use established names
+such as `information`, `caption`, and `responsibility`; those are translation
+boundaries, not persistent database identifiers. The migration is idempotent
+for fresh and already-initialized Compose volumes and has a matching rollback.
+
+ADR 0063 remains the source of the bookmark entity's third-normal-form and
+authorization decisions; this ADR changes only its table identifier.
+
+## Consequences
+
+- Schema audits can enforce the two-word naming rule without exceptions.
+- SQL, migrations, and database integration tests must use the canonical names.
+- Public API compatibility is preserved at the application serialization
+ boundary.
+- Historical migration files remain immutable; replay reaches the canonical
+ schema through the additive rename migration.
+
+## Verification
+
+Acceptance requires applying the migration to a real PostgreSQL volume,
+replaying it twice, checking that no public table/view/column violates the
+two-word rule, and exercising bookmark, image evidence, summaries, reports,
+tenant settings, and analysis-run status queries.
diff --git a/docs/adr/0121-mhtml-source-body-resolution.md b/docs/adr/0121-mhtml-source-body-resolution.md
new file mode 100644
index 000000000..ece8670d4
--- /dev/null
+++ b/docs/adr/0121-mhtml-source-body-resolution.md
@@ -0,0 +1,46 @@
+# ADR 0121: Resolve source bodies from governed MHTML artifacts
+
+## Status
+
+Accepted
+
+## Context
+
+The authorized export used by the private runtime contains post metadata and
+MHTML artifact provenance, but some rows do not contain a body column. ADR
+0056/0057 prohibit turning a title, summary, or inferred content into a
+source body. The importer therefore needs an explicit, auditable path from a
+source row to its separately stored MHTML artifact.
+
+## Decision
+
+- A body-bearing import uses exactly one of two mappings: an explicit body
+ column, or an artifact path column plus an artifact SHA-256 column and an
+ operator-supplied artifact root.
+- Artifact paths must resolve beneath the configured root after symlink
+ resolution. Missing files, traversal outside the root, non-regular files,
+ malformed hashes, and digest mismatches fail preflight before any target
+ mutation.
+- The resolver accepts RFC 2557 `multipart/related` messages and selects the
+ first leaf `text/html` part as the source body. It never falls back to a
+ title, plain-text summary, generated content, or an unrelated MIME part.
+- Every non-excluded source row is resolved and validated before the target
+ scope or any `source_post` row is written. The artifact bytes remain
+ operator-local; only the source body and existing provenance-bearing target
+ fields are persisted.
+- The source UUID/record-key mapping remains explicit and independent from
+ the artifact path. An artifact match cannot repair a missing immutable
+ source identity.
+
+## Consequences
+
+The private runtime can consume an authorized MHTML export without weakening
+the fail-closed source-body contract. A missing or incorrect artifact is an
+actionable import error rather than a silently incomplete post. The public
+repository continues to contain only synthetic artifact fixtures.
+
+## References
+
+Palme, J., Hopmann, A., & Shelness, N. (1999). *MIME encapsulation of
+aggregate documents, such as HTML (MHTML)* (RFC 2557). RFC Editor.
+https://www.rfc-editor.org/rfc/rfc2557.html
diff --git a/docs/adr/0123-provider-error-boundary.md b/docs/adr/0123-provider-error-boundary.md
new file mode 100644
index 000000000..48610ebeb
--- /dev/null
+++ b/docs/adr/0123-provider-error-boundary.md
@@ -0,0 +1,57 @@
+# ADR 0123: Provider failures never become product error payloads
+
+- Status: Accepted
+- Date: 2026-08-21
+
+## Context
+
+Provider responses and exception messages can contain credentials, gateway
+diagnostics, prompts, model output, or other internal transport detail. A
+provider outage is not buyer evidence and must not be returned as an API error
+or persisted as a durable ingestion detail.
+
+## Decision
+
+Every contextual-orchestrator, VISION, search, RankWeave, and TEPP boundary
+returns a stable product-level unavailable message. Route handlers catch both
+known transport/parse failures and unexpected provider exceptions, while
+retaining the original exception only as an in-process chained cause for
+operator logging. Provider response parsers use generic validation errors and
+never interpolate the raw response into an exception message. All
+OpenAI-compatible chat-completion consumers use the shared
+``chat_completion_content`` validator, so malformed ``choices`` envelopes
+cannot escape as raw ``KeyError`` or type-error payloads from a library
+boundary.
+
+The browser API client is a second trust boundary: HTTP 5xx details are
+discarded, and transport failures become a stable status-0 client error
+before any UI handler can render them. Client-error details remain available
+only for actionable validation or authorization responses.
+
+Missing or malformed evidence remains unavailable; it is never converted into
+a fabricated negative result. Existing input-validation errors outside a
+provider boundary retain their client-actionable 422 detail.
+
+## Consequences
+
+- API clients receive a safe retry/configuration action rather than provider
+ internals.
+- Browser clients cannot turn an upstream 5xx detail or transport exception
+ into buyer-visible provider diagnostics.
+- Server-side debugging keeps exception chaining without exposing it to buyers.
+- Malformed provider success envelopes fail closed with a stable validation
+ error before any channel parser sees them.
+- Regression tests exercise unexpected exceptions, not only known transport
+ subclasses, and assert that provider secrets do not appear in responses.
+
+## References — APA 7th
+
+National Institute of Standards and Technology. (2020). *Security and privacy
+controls for information systems and organizations* (NIST Special Publication
+800-53 Rev. 5). https://doi.org/10.6028/NIST.SP.800-53r5
+
+OWASP Foundation. (2025). *Improper error handling*. OWASP Application
+Security Verification Standard. https://owasp.org/www-project-application-security-verification-standard/
+
+MITRE. (2026). *CWE-209: Generation of error message containing sensitive
+information*. https://cwe.mitre.org/data/definitions/209.html
diff --git a/docs/adr/0124-operational-controlled-vocabulary-semantic-layer.md b/docs/adr/0124-operational-controlled-vocabulary-semantic-layer.md
new file mode 100644
index 000000000..2b1ddbe08
--- /dev/null
+++ b/docs/adr/0124-operational-controlled-vocabulary-semantic-layer.md
@@ -0,0 +1,72 @@
+# ADR 0124: Model operational controlled vocabularies as SKOS concepts
+
+## Status
+
+Accepted
+
+## Context
+
+`common_lookup_value` already centralizes configuration-like values used by
+post visibility, VOC type, permissions, and issue-ticket state. The existing
+OWL/RDFS vocabulary modeled the knowledge-graph predicates and actor types,
+but left these operational codes as untyped strings. That weakened the
+semantic layer exactly where the product exposes public/private access,
+VOC/VOM/VOP classification, RBAC permissions, and ticket/calendar workflow.
+
+## Decision
+
+Represent these four lookup categories as SKOS concept schemes in
+`docs/ontology/lineageweave-kg.ttl`:
+
+- `post_visibility`: public and private post visibility concepts;
+- `voc_type`: VOC, VOCC, VOCO, VOM, and VOP concepts;
+- `permission`: post-read and post-admin concepts;
+- `ticket_status`: open, in-progress, and closed concepts.
+
+The relational lookup code remains the stable `:lookupCode` annotation and
+PostgreSQL remains the source of record. OWL object properties describe the
+semantic use of a concept (`Post -> hasPostVisibility`, `Post -> hasVocType`,
+`AccessRole -> hasPermission`, and `IssueTicket -> hasTicketStatus`) without
+turning workflow state into a knowledge-graph edge predicate.
+
+The ontology round-trip test now includes these categories. A code is not
+considered semantically available merely because it exists in the database;
+it must resolve to a SKOS concept with a scheme and label.
+
+## Options considered
+
+1. Keep operational values as database-only strings. Rejected: this leaves
+ authorization, filtering, and workflow semantics outside the governed
+ ontology.
+2. Add a second runtime taxonomy database. Rejected: it duplicates the
+ existing normalized lookup source and creates synchronization risk.
+3. Publish the existing lookup values as SKOS concepts over the current
+ relational source. Selected: it adds machine-readable semantics without a
+ second store or a change to the API wire codes.
+
+## Consequences
+
+Positive:
+
+- public/private, VOC classification, RBAC permissions, and ticket state have
+ stable IRIs, labels, schemes, and domain/range semantics;
+- drift between seeded lookup values and the published ontology fails tests;
+- consumers can use SKOS alongside the existing OWL/RDFS and PROV-O profile.
+
+Negative:
+
+- adding a new operational lookup value now requires an ontology term and a
+ round-trip test update;
+- the current profile still does not model every analysis-run and content
+ processing status as a semantic concept, so those remain explicitly tracked
+ gaps rather than being silently treated as complete.
+
+## References (APA 7th)
+
+Miles, A., & Bechhofer, S. (Eds.). (2009). *SKOS Simple Knowledge
+Organization System reference*. World Wide Web Consortium.
+https://www.w3.org/TR/skos-reference/
+
+World Wide Web Consortium. (2017). *Shapes Constraint Language (SHACL)*.
+https://www.w3.org/TR/shacl/
+
diff --git a/docs/adr/0125-customer-master-scope-facets.md b/docs/adr/0125-customer-master-scope-facets.md
new file mode 100644
index 000000000..3099448be
--- /dev/null
+++ b/docs/adr/0125-customer-master-scope-facets.md
@@ -0,0 +1,106 @@
+# ADR 0125 — Customer Master separates authorization scope from observed relationship facets
+
+**Decision status:** Proposed
+**Date:** 2026-08-21
+
+## Context
+
+`/api/customer-master` currently reads its `corporate_entities` list only from
+`account_affiliation`. That is a valid authorization boundary, but it is not a
+customer hierarchy: verified organization mentions and counterparty entities
+created by ADR 0010 are not necessarily account affiliations. The resulting UI
+can show an authorized employer while hiding an observed customer or affiliate,
+and it cannot distinguish an account's own company from an explicitly granted
+company because the current affiliation row has no such attribute.
+
+The fix must preserve the existing ABAC decision. A visible relationship in a
+public or authorized post is evidence for navigation, not permission to read a
+private post. An unresolved counterparty name is a hint, not a catalog entity.
+
+## Decision
+
+1. Keep `account_affiliation` as the authorization source. Every post and
+ entity returned by Customer Master remains subject to the existing
+ per-request visibility and source-post eligibility predicates.
+2. Add an explicit, nullable `affiliation_scope_code` to
+ `account_affiliation`, backed by `common_lookup_value`, with the controlled
+ values `scope_own_entity`, `scope_granted_entity`, and
+ `scope_unclassified`. Existing rows are migrated to `scope_unclassified`;
+ no own/customer identity is inferred from a login token, a PU, a post title,
+ or a corporate name. Authentication continues to authorize every existing
+ affiliation row regardless of this display facet.
+3. Extend the Customer Master entity contract with repeatable, provenance-bearing
+ `scope_facets`: `authorized_own`, `authorized_granted`,
+ `scope_unclassified`, `observed_organization`, and `observed_hierarchy`.
+ Multiple facets are
+ allowed because one organization may be both an authorized entity and an
+ observed counterparty in different evidence.
+4. Build `observed_organization` only from a visible, eligible post's resolved
+ `post_organization_mention` (or an equivalently persisted, verified catalog
+ binding). `post_counterparty_entity` names that remain unresolved or
+ uncorroborated stay in the existing `source_customer_hints` / relationship
+ evidence surfaces and do not become tree nodes.
+5. Traverse `parent_entity_id` only across entities already admitted by an
+ authorization or visible evidence path. If a parent is not admitted, render
+ the admitted child as a root; never widen access merely to complete a tree.
+6. The UI's own-company/customer filters consume these facets and expose
+ `scope_unclassified` as an honest third state. No confirmation dialog or
+ guessed label is introduced. The API remains the single place that applies
+ authorization and provenance rules.
+
+## Implementation sequence
+
+The implementation is intentionally split so an ABAC regression cannot hide in
+a large customer-tree change:
+
+1. Add the lookup values and nullable affiliation column with a migration and
+ update provisioning paths to write an explicit value.
+2. Add an API integration test with own, granted, unclassified, visible
+ organization-mention, and private-post cases. Assert that private evidence
+ never adds a node and unresolved names remain hints.
+3. Add the API contract and frontend filter/tree tests, then implement the
+ query projection and UI facets.
+4. Backfill only from an authoritative account-scope source. Until that source
+ exists, retain `scope_unclassified`; do not infer it from the corpus.
+
+## Consequences
+
+- The tree can become useful without weakening ABAC: observed nodes are bounded
+ by visible evidence and do not authorize unrelated reads.
+- Existing deployments will initially show an explicit unknown scope instead of
+ a misleading own/customer label. This is preferable to a silent false fact.
+- `account_affiliation` remains a normalized authorization relation; the facet
+ is an attribute of that relation, not a second account-to-entity authority
+ table. A later need for time-bounded grants requires a separate ADR rather
+ than overloading this column.
+- The entity query needs an entity-first index on persisted organization
+ mentions if live corpus size requires it. Add that index with the same
+ migration after measuring the query plan; do not pre-emptively shard a small
+ table.
+
+## Related decisions
+
+- [ADR 0004](0004-knowledge-graph-ontology.md) — ontology and semantic layer.
+- [ADR 0010](0010-corporate-hierarchy-auto-creation.md) — verified counterparty
+ hierarchy creation.
+- [ADR 0041](0041-source-context-vs-authorization-scope.md) — source context
+ must not be confused with authorization scope.
+- [ADR 0042](0042-source-hints-before-customer-binding.md) — unresolved source
+ customer values remain hints.
+- [ADR 0052](0052-plain-orchestrator-semantic-evidence.md) — semantic evidence
+ must retain provenance and uncertainty.
+
+## References (APA 7th)
+
+Hu, V. C., Ferraiolo, D., Kuhn, R., Schnitzer, A., Sandlin, K., Miller, R., &
+ Scarfone, K. (2019). *Guide to attribute based access control (ABAC)
+ definition and considerations* (NIST Special Publication 800-162, updated
+ 2019). National Institute of Standards and Technology.
+ https://doi.org/10.6028/NIST.SP.800-162
+
+Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). *Zero trust
+ architecture* (NIST Special Publication 800-207). National Institute of
+ Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207
+
+World Wide Web Consortium. (2009). *SKOS simple knowledge organization system
+ reference*. https://www.w3.org/TR/skos-reference/
diff --git a/docs/adr/0126-global-ask-conversation-history.md b/docs/adr/0126-global-ask-conversation-history.md
new file mode 100644
index 000000000..cf0ad2e0c
--- /dev/null
+++ b/docs/adr/0126-global-ask-conversation-history.md
@@ -0,0 +1,42 @@
+# ADR 0126: Persisted Global Ask Conversation History
+
+* Status: Accepted
+* Date: 2026-08-21
+* Supersedes: the non-persistence consequence in ADR 0090
+
+## Context
+
+Global Ask currently keeps its rendered turns only in the browser. Leaving the
+Ask destination loses the question history, which makes the product behave
+differently from the conversation surface it presents. ADR 0090 deliberately
+left persisted multi-turn state for a later phase; the reader surface now
+explicitly requires that state.
+
+## Decision
+
+Persist Global Ask conversations and completed turns under the authenticated
+`user_account`. Store the question, answer, next action, retrieved source-post
+ids, cited post ids, and reader-safe evidence facts in normalized tables. A
+conversation id is explicit API state; it is never represented as a fake
+post-scoped orchestrator session id.
+
+The existing evidence retrieval and contextual-orchestrator boundary remain
+unchanged. A turn is written only after the orchestrator returns a complete
+answer object (including the authorized-no-source result). The history read
+path owns only the requesting account's conversations and re-applies the
+current post visibility rule before returning source titles, citations, or
+evidence.
+
+This is transcript persistence, not a new long-context prompt contract. The
+orchestrator continues to receive the current question and its bounded,
+authorized evidence set. Conversation summarization or cross-turn reasoning
+requires a separate ADR and upstream orchestrator contract.
+
+## Consequences
+
+* Ask history survives navigation and a new authenticated browser session.
+* A user cannot read another account's conversation by changing a UUID.
+* Revoked post visibility removes that post's source/citation projection from
+ history; the stored answer remains account-owned transcript data.
+* The UI can select an existing conversation or start a new one without
+ changing the existing `/api/ask` evidence contract.
diff --git a/docs/adr/0127-role-affiliation-catalog-identity.md b/docs/adr/0127-role-affiliation-catalog-identity.md
new file mode 100644
index 000000000..ddb288a85
--- /dev/null
+++ b/docs/adr/0127-role-affiliation-catalog-identity.md
@@ -0,0 +1,47 @@
+# ADR 0127: R&R affiliations become separate catalog-backed organization evidence
+
+- Status: Accepted
+- Date: 2026-08-21
+
+## Context
+
+R&R already preserved a person's or team's extracted
+`affiliated_organization_name`, but only an organization actor could receive
+the `post_summary_role` corporate-entity identity. A person such as a member
+of a named company therefore remained free text, so the company could not
+enter the post-scoped organization mention or Knowledge Graph projection.
+
+The same extraction also allowed a generic label such as `사업부` to become a
+cataloged team without a named unit or affiliation. That is not an ontology
+identity: a source process-unit code/name is source context and must not be
+silently promoted into a team actor.
+
+## Decision
+
+- Add `cataloged_affiliated_corporate_entity_id` to `post_summary_role`.
+ It is separate from the actor's own catalog identity, so a person/team can
+ retain its own identity and its organization affiliation at the same time.
+- Resolve an extracted R&R affiliation through the existing organization
+ name-resolution, hierarchy, and verification clients. Preserve the raw
+ extracted name; only a unique or verified catalog result receives the FK.
+ A miss, tie, or unavailable enrichment channel remains visibly unresolved.
+- Write every resolved R&R affiliation to `post_organization_mention` so the
+ existing Knowledge Graph edge projection can expose the organization.
+- Do not catalog generic team labels (`사업부`, `부서`, `팀`, `business unit`,
+ `department`, or `division`) without a specific named unit. Keep the source
+ process-unit code/name as separately labeled source evidence.
+- Increase the summary contract version so existing summaries are regenerated
+ under the corrected extraction contract.
+
+## Consequences
+
+The popup can make a resolved affiliation clickable while still showing the
+wording extracted from the source. It can also explain that an unnamed
+business-unit label is not a resolved organization or team. Existing rows are
+not guessed during migration; they receive the new identity when their
+summary is regenerated with source evidence.
+
+## Related
+
+Extends ADR 0006, ADR 0009, ADR 0010, and ADR 0019. Source process-unit
+display remains subject to ADR 0051: it is a hint, not a catalog binding.
diff --git a/docs/adr/0128-source-grounded-quantitative-observations.md b/docs/adr/0128-source-grounded-quantitative-observations.md
new file mode 100644
index 000000000..8b841cdba
--- /dev/null
+++ b/docs/adr/0128-source-grounded-quantitative-observations.md
@@ -0,0 +1,42 @@
+# ADR 0128: Source-grounded quantitative observations
+
+- Status: Accepted
+- Date: 2026-08-21
+
+## Context
+
+The summary projection preserves some evidence as free text, but a budget,
+capacity, or counted asset cannot be reliably searched or displayed as an
+independent semantic fact from that text alone. Numeric normalization must
+also preserve what the source actually said: units, qualifiers, and the exact
+supporting phrase.
+
+## Decision
+
+Store each source-grounded quantitative fact as one
+`post_summary_quantitative_observation` row linked to its post. A row keeps:
+
+- a controlled measurement type and unit;
+- the normalized numeric value, and an optional counted quantity such as
+ `2 tractors`;
+- the source label, raw value text, qualifier text, and exact evidence text;
+- the ontology IRI and extraction method.
+
+The contextual orchestrator must return these observations as part of the
+summary semantic contract. The application does not create observations by a
+local regex or by guessing from a filing timestamp. Missing orchestrator
+output remains unavailable, while an existing stale summary remains clearly
+stale. The source phrase remains the reader-facing evidence and the numeric
+value is a search/filter projection, not a newly inferred business fact.
+
+The post list search and post detail API read the same normalized projection.
+The ontology describes the observation class and controlled measurement/unit
+terms, but observations are not promoted to a new polymorphic knowledge-graph
+node until a graph edge contract is needed.
+
+## Consequences
+
+One fact with two capacities is represented by two observations, while the
+count of each asset is retained on its corresponding capacity observation.
+Regenerating a summary replaces the post-owned observation rows atomically
+with the other summary projections.
diff --git a/docs/adr/0129-standards-aligned-event-clue-ontology-profile.md b/docs/adr/0129-standards-aligned-event-clue-ontology-profile.md
new file mode 100644
index 000000000..eaad8ebae
--- /dev/null
+++ b/docs/adr/0129-standards-aligned-event-clue-ontology-profile.md
@@ -0,0 +1,146 @@
+# ADR 0129: Standards-aligned event and clue ontology profile
+
+- Status: Accepted
+- Date: 2026-08-21
+
+## Context
+
+The product must answer questions such as `왜?` from a connected graph, not
+from a body-text keyword hit. A key event therefore needs explicit, searchable
+clues for its actors, action, time, place, cause, goal, object, result,
+condition, quantity, and next step. A clue must retain the source evidence and
+the assertion state; a guessed relationship must never look like an observed
+fact.
+
+The existing `knowledge_graph_edge` table is a compact navigation projection.
+It cannot represent the qualified evidence, literal values, selectors, or
+inference provenance required by this use case. The semantic assertions and
+event clues remain normalized source projections and can be joined into KG
+rendering without pretending that every semantic row is already a polymorphic
+KG node.
+
+## Decision
+
+Publish a standards-aligned ontology profile in
+`docs/ontology/lineageweave-kg.ttl` and a validation profile in
+`docs/ontology/lineageweave-shapes.ttl`.
+
+### Standard mappings
+
+- W3C PROV-O is the provenance backbone. Extracted assertions use
+ `prov:Entity`; extraction is a `prov:Activity`; qualified influence,
+ derivation, attribution, usage, association, delegation, and time remain
+ available through the existing `lineageweave.prov_o` registry.
+- W3C Organization Ontology supplies organization, organizational-unit,
+ membership, role, reporting, and sub-organization patterns. A generic
+ `사업부` is not bound to a concrete unit without source evidence.
+- OWL 2/RDFS supply class inheritance, inverse properties, property chains,
+ equivalence/disjointness, and restrictions. These are ontology axioms, not
+ rows in `knowledge_graph_edge`.
+- OWL-Time supplies instant/interval and before/after/during relations. A
+ normalized date is retained with precision and normalization evidence.
+- SOSA/SSN supplies the observation/result distinction. A
+ `QuantitativeObservation` or `EventObservation` in this product is an
+ extracted source assertion, not an asserted physical sensor act; it is
+ therefore aligned through `rdfs:seeAlso` and does not claim `sosa:Observation`
+ without an actual procedure, feature of interest, phenomenon time, and
+ result.
+- Web Annotation supplies the evidence-target and selector pattern. A clue
+ may target an event, an assertion, or a source content unit. Exact source
+ text and position remain private runtime evidence and are not copied into
+ repository fixtures.
+- SHACL supplies the machine-readable graph contract. It validates minimum
+ evidence, value types, and the distinction between extracted and inferred
+ assertions; it is also usable for UI generation and data integration.
+- ODRL supplies normative rule vocabulary. A source condition such as “not
+ commercial” is a fact/condition only. It becomes a prohibition, permission,
+ or duty only when the source expresses a normative modality and action.
+- QUDT is the external quantity/unit reference vocabulary. Local measurement
+ codes remain the application-controlled vocabulary and use conservative
+ `rdfs:seeAlso`/mapping annotations until an exact unit identity is verified.
+- DCMI Terms supplies general metadata relations such as provenance,
+ references, and conformance for export-facing metadata.
+- ISO/IEC 21838 BFO, ISO/IEC 19510 BPMN, and ISO 21127 CIDOC CRM are mapping
+ references for upper-level entity, process/event, and actor/event patterns.
+ ISO 14224, ISA-95/IEC 62264, OPC UA Events/Alarms, and ISO 31000 extend the
+ industrial asset, process, condition, maintenance, and risk vocabulary.
+ They are not imported as runtime axioms because their domain commitments are
+ broader than this product's evidence contract.
+
+### Profile extensions for meanings no single standard covers
+
+The profile may add a local term when no adopted vocabulary has the exact
+meaning needed for source-grounded business correspondence. Every extension
+must have:
+
+1. a precise definition and domain/range;
+2. source evidence and assertion status requirements;
+3. a nearest standard mapping (`rdfs:seeAlso`, `skos:closeMatch`, or a
+ qualified PROV relation), without overstating equivalence;
+4. a declared inference policy; and
+5. a decision on whether it is only a semantic-layer resource or is hydrated
+ into the compact KG projection.
+
+The first such extensions cover the whole source-to-question path:
+`ObservationRecord`, `EventObservation`, `EvidenceClue`, `TemporalClaim`,
+`OrganizationContext`, `IndustrialAsset`, `IndustrialProcess`,
+`NormativeStatement`, `QualityAssessment`, `RiskStatement`,
+`clueSupports`, `clueFor`, `hasCause`, `hasGoal`, `hasConsequence`,
+`hasNextStep`, `assertionStatus`, and `inferenceRule`. They are not aliases
+for W3C PROV properties: provenance uses the canonical PROV direction, while
+these terms express the product's evidence and question-answering semantics.
+
+The source-facing dimensions are deliberately explicit: time, place, actor,
+cause, purpose/goal, result, next step, quantity, condition, quality, risk,
+and source segment. Organization and industrial context are modeled as
+separate entities so a plant, team, equipment item, process, and company are
+not collapsed into one actor label. Normative statements are separate from
+descriptive conditions.
+
+### Assertion and inference boundary
+
+The graph renderer may show asserted, derived, and inferred paths, but must
+label them separately. A standard inverse, subclass, subproperty, or property
+chain is deterministic entailment. A business conclusion such as “this event
+was caused by X” is not entailed merely because X appears nearby; it needs a
+source clue or a qualified inference record. No local heuristic may silently
+upgrade a clue into a fact.
+
+### Hydration rule
+
+Declaring a class or relation in the profile does not create a database node.
+New `knowledge_graph_edge` node/edge lookup codes require a relational source,
+authorization-aware hydration, evidence rows, and a graph regression test.
+Until then, the semantic layer exposes the resource and the Ask retriever may
+join it as a provenance-bearing fact.
+
+## Consequences
+
+- Event-centered retrieval can traverse `event -> clue -> source unit ->
+ post -> KG neighbor`, then answer `why` with a visible evidence path.
+- Numeric, temporal, conditional, and role clues remain independently
+ searchable without copying private source values into repository artifacts.
+- The profile is broad enough for future event/entity classes while refusing
+ false certainty where a standard does not define the business meaning.
+- Shapes are a contract and regression guard; they do not replace the
+ orchestrator's source-grounded extraction or database authorization.
+
+## References
+
+- W3C PROV-O: https://www.w3.org/TR/prov-o/
+- W3C Organization Ontology: https://www.w3.org/TR/vocab-org/
+- W3C OWL-Time: https://www.w3.org/TR/owl-time/
+- W3C SOSA/SSN 2023: https://www.w3.org/TR/vocab-ssn-2023/
+- W3C Web Annotation Data Model: https://www.w3.org/TR/annotation-model/
+- W3C SHACL: https://www.w3.org/TR/shacl/
+- W3C ODRL Information Model: https://www.w3.org/TR/odrl-model/
+- QUDT Schema: https://www.qudt.org/doc/2025/03/DOC_SCHEMA-QUDT.html
+- ISO/IEC 21838-2:2021 BFO: https://www.iso.org/standard/74572.html
+- OMG BPMN 2.0: https://www.omg.org/spec/BPMN/2.0
+- CIDOC CRM / ISO 21127:2023: https://cidoc-crm.org/Event/iso-211272023-has-been-released
+- DCMI Metadata Terms: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/
+- ISO 14224: https://www.iso.org/standard/64076.html
+- ISA-95 / IEC 62264: https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
+- OPC UA Event Model: https://reference.opcfoundation.org/specs/OPC-10000-3/4.7
+- OPC UA Alarms and Conditions: https://reference.opcfoundation.org/Core/Part9/v105/docs/4.1
+- ISO 31000: https://committee.iso.org/sites/tc262/home/projects/published/iso-31000-2009-risk-management.html
diff --git a/docs/adr/0130-source-commercial-context-hints.md b/docs/adr/0130-source-commercial-context-hints.md
new file mode 100644
index 000000000..b972342f2
--- /dev/null
+++ b/docs/adr/0130-source-commercial-context-hints.md
@@ -0,0 +1,33 @@
+# ADR 0130: Source commercial-context combination hints
+
+## Status
+
+Accepted
+
+## Decision
+
+The import boundary accepts explicit mappings for source customer, order-pool,
+sales-order, sales-order-item, and inspection/status-point fields. Raw values
+are retained on `source_post` with their source-state fields; the importer does
+not infer a catalog identity or a lifecycle label from a code.
+
+The product computes a small combination code from field presence. For the
+sales-order-item field, a positive numeric value is present and the source
+zero sentinel is absent. Combination labels such as
+`customer_only_candidate` and `no_sales_identifier_candidate` are explicitly
+inferred candidates, not facts. The exact raw lifecycle vector remains visible
+alongside the inference.
+
+The same bounded hint is passed to contextual-orchestrator, Ask Agent evidence,
+and the post knowledge-graph view. Customer-name resolution continues through
+the existing corroborated customer-hint path; a raw customer code never creates
+a catalog entity by itself.
+
+## Rationale
+
+Independent null rates cannot distinguish a customer-only record from an
+order-pool record or an order item. The current source distribution shows that
+the four presence bits form multiple materially different populations. Keeping
+the combination deterministic, provenance-bearing, and weakly labeled gives
+lineage reconstruction and readers the useful distinction without turning
+unknown SAP codes into invented semantics.
diff --git a/docs/adr/0131-explicit-organization-project-relations.md b/docs/adr/0131-explicit-organization-project-relations.md
new file mode 100644
index 000000000..d0785f2bd
--- /dev/null
+++ b/docs/adr/0131-explicit-organization-project-relations.md
@@ -0,0 +1,27 @@
+# ADR 0131: Explicit organization-to-project semantic relations
+
+## Status
+
+Accepted
+
+## Decision
+
+The semantic relationship contract may persist an organization-to-project
+`lw_supports` relation only when the source explicitly assigns that
+organization work, ownership, contracting, or support for the named project.
+`lw_supports` is a LineageWeave profile property with `prov:Agent` domain and
+`prov:Entity` range. It is not a PROV alias and does not create an inferred
+inverse, ownership, or causal edge.
+
+Explicit organization membership uses W3C Organization Vocabulary
+`org_member_of` (`org:memberOf`). A project mention, affiliation, or shared
+meeting does not create either relation. Unresolved names remain text in the
+qualified semantic table and its evidence-bearing navigation projection.
+
+## Consequences
+
+- A post can show distinct organization-to-project responsibilities instead
+ of collapsing every organization under one project label.
+- The graph remains a navigation projection; evidence and confidence stay in
+ `post_summary_semantic_relationship`.
+- Attendance-only actors remain event clues, not role/responsibility rows.
diff --git a/docs/adr/0132-tepp-topic-lineage-consumption-boundary.md b/docs/adr/0132-tepp-topic-lineage-consumption-boundary.md
new file mode 100644
index 000000000..a808a268c
--- /dev/null
+++ b/docs/adr/0132-tepp-topic-lineage-consumption-boundary.md
@@ -0,0 +1,197 @@
+# ADR 0132 — TEPP topic-lineage consumption boundary (TRSL-TM + CHRONOS/TDT)
+
+**Decision status:** Accepted
+**Implementation maturity:** boundary-accepted; evidence/inference/prediction
+mark primitive implemented (`frontend/src/components/EvidenceStatusMark.tsx`,
+below); DAG topic-thread wiring and runtime remain open
+**Date:** 2026-08-22
+**Depends on:** ADR 0022 (authorized TEPP start); ADR 0064 (lineage evidence
+and tree assembly); ADR 0084 (research-grounded lineage and ontology policy)
+**Refs:** TEPP ADR 0012 (Temporal Relational Shared-Latent Topic
+Measurement); TEPP ADR 0016 (TDT, CHRONOS, and Event Ontology intelligence
+boundary)
+
+## Context
+
+ADR 0084 already separates mention detection / lineage-instance
+construction (LineageWeave's own evidence-fusion engine) from calibrated
+measurement, which stays a TEPP wire-contract boundary that is never
+reimplemented locally. That separation did not yet have a topic-identity
+counterpart: `zcrht811_export_rows` board posts are scattered across time
+with no thread connecting a post to the earlier/later posts that share its
+underlying commercial topic (a competitor mention, a market trend, a sales
+opportunity) the way a Git branch connects commits.
+
+TEPP's own accepted-target architecture already defines this problem
+precisely:
+
+- TEPP ADR 0012 adopts **Temporal Relational Shared-Latent Topic
+ Measurement (TRSL-TM)**: one global topic identity set per modeled
+ period, where topics may be active, dormant, or reactivated over time
+ without losing identity, and topic birth/split/merge/retirement is an
+ explicit lineage extension — not an implicit side effect of fitting
+ unrelated time slices.
+- TEPP ADR 0016 separates Event Ontology, TDT-style detection/tracking, and
+ CHRONOS-style reasoning (semantic/neural event-schema
+ extraction/prediction plus symbolic temporal-consistency reasoning).
+ Every output carries an evidence / inference / prediction status and
+ provenance; a prediction is never silently converted into historical
+ fact.
+
+TEPP is currently a foundation-slice (`crates/tepp_api` exposes only
+`AnalysisRunRequest` / `AnalysisRunAccepted`; a completed-result contract is
+still open — TEPP issue #156). Standing up a local topic model or event
+predictor to fill that gap would repeat exactly the "invented psychometric
+substitute" ADR 0084 and the tepp-readiness discipline already forbid.
+
+## Decision
+
+1. LineageWeave does not compute topic identity, topic
+ birth/split/merge/retirement, event-schema predictions, or temporal-
+ consistency verdicts locally. These remain TEPP's TRSL-TM (ADR 0012) and
+ CHRONOS/TDT (ADR 0016) computations, requested through `tepp_client` the
+ same way `analysis_run_start.py` requests a measurement run (ADR 0022).
+2. A new analysis-run kind, topic-lineage, is added alongside the existing
+ lineage / TEPP / period-report kinds (ADR 0013 registry). Requesting it
+ builds a TEPP request payload from the run's idempotency key, snapshot
+ digest, knowledge cutoff, and corporate-entity workspace id — never post
+ bodies or a fabricated topic label — and submits through `TeppClient`.
+3. An empty `TEPP_TRANSPORT_URL`, or a TEPP response that omits the
+ versioned topic-identity/CHRONOS-status envelope, appends Failed with a
+ machine-readable reason (`tepp_not_available` /
+ `tepp_topic_contract_unavailable`), mirroring ADR 0022. Failed is
+ terminal; the operator reconnects TEPP and re-requests.
+4. When TEPP does publish the topic-identity and CHRONOS-status envelope,
+ LineageWeave persists it into a new topic-identity-thread projection
+ (3NF, two-word snake_case, partitioned by corporate-entity + observed
+ period to avoid a hot partition on the shared post table) that links
+ existing posts to TEPP topic ids and carries each edge's evidence /
+ inference / prediction status verbatim. This projection extends — it
+ does not replace — the existing evidence-fusion lineage tree (ADR
+ 0064/0084); a post can appear in both the fusion-based lineage DAG and a
+ TEPP topic thread, and the UI keeps the two visually distinct.
+5. The frontend Event Lineage DAG gains a topic-thread overlay: nodes/edges
+ sourced from TEPP render with a distinct visual channel (color/pattern
+ token, not color alone, for accessibility) per evidence / inference /
+ prediction status, and render nothing (not a placeholder guess) for a
+ topic-lineage run that is Pending or Failed. Storybook stories cover
+ Pending, Failed (`tepp_not_available`, `tepp_topic_contract_unavailable`),
+ and each CHRONOS status; a Playwright e2e spec exercises the golden path
+ once a topic-identity envelope exists and the fail-closed path when it
+ does not.
+
+```mermaid
+sequenceDiagram
+ participant Operator
+ participant API
+ participant TeppClient
+ participant Registry
+ Operator->>API: POST /api/analysis-runs (kind=topic_lineage)
+ API->>Registry: create Pending topic_lineage run
+ Operator->>API: POST /api/analysis-runs/{id}/start
+ Registry->>Registry: Running
+ API->>TeppClient: TopicLineageRequest v1 (TRSL-TM + CHRONOS/TDT)
+ alt TeppNotAvailable
+ Registry->>Registry: Failed tepp_not_available
+ else envelope lacks topic-identity/CHRONOS contract
+ Registry->>Registry: Failed tepp_topic_contract_unavailable
+ else versioned envelope present
+ Registry->>Registry: Succeeded; persist topic-identity threads + CHRONOS status
+ end
+ API-->>Operator: run status + evidence/inference/prediction detail
+```
+
+### Implementation note: the status-mark primitive ships ahead of the wiring
+
+Decision item 5's "distinct visual channel, not color alone" requirement is
+implemented now as `EvidenceStatusMark` (`frontend/src/components/
+EvidenceStatusMark.tsx`, i18n in `evidenceStatusI18n.ts`, tokens in
+`styles/tokens.css`): a reusable badge distinguishing evidence / inference /
+prediction by label text and glyph shape (`●` / `◆` / `△`) in addition to
+color, satisfying WCAG 1.4.1 with redundant, testable channels (see its
+Storybook stories and `EvidenceStatusMark.test.tsx`). It is presentational
+only — every call site must supply `status` from a real TEPP-sourced
+envelope; the component never infers or invents one. Wiring it into
+`LineageDag`'s topic-thread overlay is the remaining step once TEPP issue
+#156 publishes the topic-identity/CHRONOS-status envelope this ADR's
+decision 3-4 depend on; until then, no topic-lineage run reaches Succeeded,
+so there is no envelope to source a `status` prop from.
+
+No Figma frame exists yet for this primitive (cf. ADR 0002's precedent for
+recording that gap rather than fabricating a frame reference); add the file
+ID here when a designer produces one.
+
+Decision 5's fail-closed Playwright half also ships ahead of the wiring:
+`frontend/e2e/topic-lineage-fail-closed.spec.ts` (config in
+`frontend/playwright.config.ts`, `npm run test:e2e`) walks the seeded
+Failed topic-lineage row end to end — Keycloak login, the ADR 0014
+`kind · status · entity` caption, the connect-a-transport next action, the
+detail-only machine failure code, and the absence of any evidence/
+inference/prediction mark without a TEPP envelope. On a deployment holding
+real imported source data the spec skips itself with a named reason,
+because ADR 0001/0042 deliberately hide the synthetic Demo Corp runs
+there; it runs fully against the seed-only stack `make seed` builds. The
+golden-path e2e half still waits on TEPP issue #156.
+
+## Considered alternatives
+
+1. **Fit a local LDA/BERTopic-style model over `zcrht811_export_rows` now,
+ swap to TEPP later** — rejected: an ungrounded local topic model is
+ exactly the invented substitute ADR 0084/CLAUDE.md forbid, and its
+ outputs (unstable topic identity, no posterior uncertainty, no temporal-
+ identity contract) would not be swap-compatible with TRSL-TM's
+ logistic-normal, posterior-bearing topic coordinates.
+2. **Treat the existing evidence-fusion lineage DAG (ADR 0064/0084) as
+ sufficient and skip a topic-identity dimension** — rejected: fusion-based
+ lineage links posts by lexical/embedding/temporal similarity, not by a
+ calibrated, longitudinally stable topic identity; it cannot express
+ topic birth/split/merge/retirement the way TRSL-TM can.
+3. **Block all topic-lineage UI until TEPP ships the full contract** —
+ rejected: the fail-closed Pending/Failed states are themselves a
+ product (ADR 0022 precedent), and the UI/Storybook/e2e scaffolding can
+ and should be built and reviewable now so the feature activates the
+ moment TEPP's contract lands, instead of starting from zero then.
+
+## Consequences
+
+- LineageWeave's topic-lineage feature is fully specified and reviewable
+ before TEPP exposes its topic-identity/CHRONOS envelope; only the
+ transport needs to be connected once TEPP is ready (tracked in memory
+ `tepp-readiness-watch` and TEPP issue #156).
+- The evidence / inference / prediction distinction from TEPP ADR 0016
+ propagates end to end — API response, DB row, and UI rendering — so a
+ CHRONOS prediction can never be flattened into a fact anywhere in this
+ product.
+- Coordination cost: this ADR's runtime activation depends on a
+ cross-repository contract change in TEPP; `docs/product-technical-gap-
+ baseline.md` must track that dependency explicitly rather than mark this
+ gap closed prematurely.
+
+## References — APA 7th
+
+ContextualWisdomLab. (2026). *TEPP* [Computer software]. GitHub.
+https://github.com/ContextualWisdomLab/TEPP
+
+ContextualWisdomLab. (2026). *ADR 0012: Temporal relational shared-latent
+topic measurement* [ADR]. GitHub.
+https://github.com/ContextualWisdomLab/TEPP/blob/main/docs/adr/0012-temporal-relational-shared-latent-topic-measurement.md
+
+ContextualWisdomLab. (2026). *ADR 0016: TDT, CHRONOS, and Event Ontology
+intelligence boundary* [ADR]. GitHub.
+https://github.com/ContextualWisdomLab/TEPP/blob/main/docs/adr/0016-tdt-chronos-event-intelligence-boundary.md
+
+Roberts, M. E., Stewart, B. M., & Tingley, D. (2019). stm: An R package for
+structural topic models. *Journal of Statistical Software, 91*(2), 1–40.
+https://doi.org/10.18637/jss.v091.i02
+
+Mimno, D., Wallach, H. M., Naradowsky, J., Smith, D. A., & McCallum, A.
+(2009). Polylingual topic models. In *Proceedings of the 2009 Conference on
+Empirical Methods in Natural Language Processing* (pp. 880–889). Association
+for Computational Linguistics. https://aclanthology.org/D09-1092/
+
+Allan, J. (Ed.). (2002). *Topic detection and tracking: Event-based
+information organization*. Springer. https://doi.org/10.1007/978-1-4615-0933-2
+
+Kalashnikov, D. V., Chen, Z., Mehrotra, S., & Nuray-Turan, R. (2007). CHRONOS:
+Facilitating history discovery by linking temporal records. *Proceedings of
+the VLDB Endowment*. https://doi.org/10.14778/2367502.2367559
diff --git a/docs/doctoring/CUSTOMER_MASTER_SCOPE_REFERENCES.md b/docs/doctoring/CUSTOMER_MASTER_SCOPE_REFERENCES.md
new file mode 100644
index 000000000..5e5607975
--- /dev/null
+++ b/docs/doctoring/CUSTOMER_MASTER_SCOPE_REFERENCES.md
@@ -0,0 +1,29 @@
+# Customer Master scope references
+
+This register grounds the proposed Customer Master scope-facet decision in
+authoritative access-control and semantic-hierarchy sources. Keep the
+authorization boundary, observed evidence, and catalog identity separate when
+implementing ADR 0125.
+
+## Evidence mapping
+
+| Source | Product decision |
+| --- | --- |
+| NIST SP 800-162 | Treat account, resource, action, and environment attributes as inputs to an ABAC decision; do not turn a display classification into a permission grant. |
+| NIST SP 800-207 | Re-evaluate access at the resource boundary and minimize implicit trust; visible relationship evidence cannot widen private-post access. |
+| W3C SKOS | Represent the corporate hierarchy as a broader/narrower concept relation while retaining the evidence and authorization facets separately. |
+
+## APA 7th references
+
+Hu, V. C., Ferraiolo, D., Kuhn, R., Schnitzer, A., Sandlin, K., Miller, R., &
+Scarfone, K. (2019). *Guide to attribute based access control (ABAC)
+definition and considerations* (NIST Special Publication 800-162, updated
+2019). National Institute of Standards and Technology.
+https://doi.org/10.6028/NIST.SP.800-162
+
+Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). *Zero trust
+architecture* (NIST Special Publication 800-207). National Institute of
+Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207
+
+World Wide Web Consortium. (2009). *SKOS simple knowledge organization system
+reference*. https://www.w3.org/TR/skos-reference/
diff --git a/docs/doctoring/DESIGN_TOKEN_REFERENCES.md b/docs/doctoring/DESIGN_TOKEN_REFERENCES.md
index 717954045..7ae1afbdc 100644
--- a/docs/doctoring/DESIGN_TOKEN_REFERENCES.md
+++ b/docs/doctoring/DESIGN_TOKEN_REFERENCES.md
@@ -9,7 +9,7 @@ the Storybook inventory.
| Source | Product implication | Implemented evidence |
|---|---|---|
| W3C Design Tokens Format Module 2025.10 | Name color, space, type, and radius once; consume those names from repeated objects. | `frontend/src/styles/tokens.css` defines `--color-*`, `--space-*`, `--size-control-min`, `--radius-chip`, `--radius-control`, `--radius-panel`, and `--font-*`. `CitationChip`, `PopupCloseButton`, `CutoffKnownBody`, and `LineageEntityPicker` read those names through `App.css`. |
-| Storybook for React & Vite | Catalog repeated controls so a buyer can try the next click without reading `App.tsx`. | `frontend/src/components/*.stories.tsx` and `docs/storybook-inventory.md`. |
+| Storybook for React & Vite | Catalog repeated controls so a reader can try the next click without reading `App.tsx`. | `frontend/src/components/*.stories.tsx` and `docs/storybook-inventory.md`. |
| WCAG 2.2 | Give interactive controls programmatic names and announce an asynchronous evidence failure instead of leaving a perpetual loading state. | Component interaction tests exercise the named controls; `EvidencePanel` exposes its terminal failure with `role="alert"`. This is targeted evidence, not a claim of complete WCAG conformance. |
## APA 7th references
diff --git a/docs/image-content-schema.md b/docs/image-content-schema.md
index d8e490b80..7574db752 100644
--- a/docs/image-content-schema.md
+++ b/docs/image-content-schema.md
@@ -93,7 +93,7 @@ picture sat relative to the surrounding paragraphs."
The demo popup does not yet read these tables. It splits the live
`post_body` the same way `extract_base64_images` does: each
`data:image/...;base64,...` payload becomes an `{t("Authorized scope")}
+{error}
} {!post && !error &&{t("Loading...")}
} {post && ( <> -{post.voc_type_label ?? post.voc_type_code} ·{" "} {post.visibility_label ?? post.visibility_code} ·{" "} @@ -1929,63 +2256,481 @@ function PostDetailPopup({ {liveBodyWarning}
) : null} -- {t("Source body was not imported; summary and semantic extraction are unavailable.")} -
- )} -+ {t("Last saved summary shown. Retry semantic refresh.")} {" "} + +
) : null} - {post.source_detail_state_code ? ( +{summary.korean_summary}
+ {(summary.key_event_details?.length ?? summary.key_events.length) > 0 && ( <> -{t("Raw source codes are shown; no state label was inferred.")}
+ {post.source_lineage_hints ? ( ++ {sourceLineageContextLabel(post.source_lineage_hints)}{" "} + {t("Combination code")}: {post.source_lineage_hints.combination_code}{" "} + {t("Inferred from field presence")} +
+{t("Field combination")}
++ {t("Lifecycle vector")}: {post.source_lineage_hints.lifecycle_vector} · {t("Raw codes only")} +
+- {t("Last saved summary shown. Retry semantic refresh.")} {" "} - -
- ) : null} -{summary.korean_summary}
- {(summary.key_event_details?.length ?? summary.key_events.length) > 0 && ( - <> -{summaryError}
+{t("No summary is available for this record yet.")}
++ {t("Source body was not imported; summary and semantic extraction are unavailable.")} +
)}- Connect a TEPP transport from this Failed row. Request a lineage - reconstruction does not invent a measurement. + {selected.run_kind_code === "analysis_run_topic_lineage" + ? "Connect a topic-lineage transport from this Failed row. Request a " + + "lineage reconstruction does not invent a topic model." + : "Connect a TEPP transport from this Failed row. Request a lineage " + + "reconstruction does not invent a measurement."}
)} {analysisRunReportPeriod(selected) && onSelectReportPeriod && ( @@ -3566,19 +4231,81 @@ function ReportsPanel({ ); } -const POST_PAGE_SIZE = 50; -type BoardSortOrder = PostSortOrder; +const POST_PAGE_SIZE = 50; +type BoardSortOrder = PostSortOrder; + +const VOC_TYPE_PRESENTATIONS: Record{t("Search includes post text and semantic evidence.")}
- - - - {hasBoardFilters && ( - - )} +@@ -3915,7 +4772,11 @@ function PostList({
) : ({t("Authorized customer scope")}
+{t("Customer scope")}
{t("Customer entities available to this account.")}
+{t("Customer entities available to this account.")}
{error ?{error}
: null} {master === null && !error ?{t("Loading customer master...")}
: null} {master?.corporate_entities.length === 0 ? ({t("No customer entities are connected to this account.")}
) : null} + + {searchedHintCode && master && master.source_customer_hints.length === 0 ? ( ++ {tf("No source customer evidence matches {code}.", { code: searchedHintCode })} +
+ ) : null} {master && master.corporate_entities.length > 0 ? ( + + ) : null} + {master && master.corporate_entities.length > 0 && filteredEntities.length === 0 ? ( ++ {t("No entities match the current scope filter.")} +
+ ) : null} + {filteredEntities.length > 0 ? (+
{t("A counterparty can hold more than one role over time -- a customer in one post can be a competitor, supplier, or partner in another. Every role observed for a name is listed, not just the most frequent.")}
+
{t("Source identifiers are hints only; ontology and semantic evidence must resolve them before binding a customer.")}
{master.source_customer_hints.length > HINT_RENDER_LIMIT && ( @@ -4466,7 +5464,30 @@ function CustomerMasterPanel({ ); } -function AskAgentPanel({ +type AskAgentExchange = { + id: string; + question: string; + status: "pending" | "complete" | "error"; + response?: AskAgentResponse; + error?: string; +}; + +const ASK_AGENT_STARTERS = [ + "What happened between these events?", + "Who is involved?", + "What is the next commitment?", +] as const; + +function toAskAgentExchanges(conversation: Awaited{t("Evidence-grounded questions")}
-{t("Questions use authorized posts and their evidence.")}
- {error ?{error}
: null} -