docs: rename "DL output" to "DL resource"

"Output" implied the thing was produced by the system, but a DL resource
can be a pre-existing artifact a person manually designates as an entry
point. "Resource" is production-neutral. Renames the two-word term across
the v0.5 docs, the FAQ, and the key-concepts/levels diagrams, plus the
definitional bare-"output" uses that named the same umbrella concept.
Leaves genuine production/verb uses of "output" untouched.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: yoomlam

lik-ui/src/lik_ui/faq.md

@@ -133,7 +133,7 @@ LIK's skills and agents should be updated to efficiently and effectively call on
 ```
 DSs → DL-creation skill (one of many, per source/team) → DL record (tagged `discovery-layer`, in a store, via MCP)
 DL records → Catalog-registration skill (the registrar) → Catalog pointer (via MCP)
-AI tools → Query skill (one of many, per topic) → known DL output directly, else read Catalog → follow pointers
+AI tools → Query skill (one of many, per topic) → known DL resource directly, else read Catalog → follow pointers
 Designated artifact (a saved synthesis, or any pre-existing record a person points at) → the person designates it an entry point; if they opt to register → the governed writer writes the Catalog pointer (human-owned row), optionally tagging the source
 Confirmations → service-fronted store (via MCP)
 Durable updates → DSs

lik-ui/src/lik_ui/static/lik-data-flows-diagram.svg

@@ -10,7 +10,7 @@ A company's knowledge is scattered across many data sources — storage (Google
 
 Leave the knowledge where it already lives, in the **Data Sources** — each stays authoritative for the knowledge it holds, and each keeps controlling who may see what. On top, add a **Discovery Layer**: material — mostly *derived* from those sources — whose only job is to make knowledge fast to find and reuse — **without** copying everything into one place and **without** becoming a competing authority.
 
-Its outputs come in three kinds:
+Its resources come in three kinds:
 
 - **Most of it (stored as "DL records")** — summaries, indexes, and pointers written back into a Data Source and marked `discovery-layer` to flag their role: an entry point an AI agent looks at first. Most are generated automatically from the sources, though a person may curate or edit one. Without this prepared material, every tool would re-search the full sources from scratch on each question — the slow, costly repetition the Discovery Layer exists to remove.
 - **The Catalog** — an index to look up where a topic's material lives, and the first place to start answering a question. It's built only from the DL records — not the full sources — so it's the coarse, topic-level map of what exists and where across many systems. Without it, a tool would have to search every system just to learn what exists before it could begin.
@@ -34,7 +34,7 @@ Every design choice traces back to these.
 - **Loosely coupled** — keep the pieces independent so any one — a store, a source, a tool — can be swapped without rewriting the rest, and no single vendor becomes hard to leave.
 - **Intuitive** — lean on standards (e.g., MCP) and common patterns rather than bespoke mechanisms, so people and tools pick it up quickly.
 - **Flexible** — adaptable to a wide range of questions, data, and tools: many small, specialized skills instead of one rigid system.
-- **Knowledge stays authoritative where it lives** — each piece of knowledge stays authoritative in the data source that owns it. The Discovery Layer isn't a place to author authoritative knowledge for its own sake; its outputs — DL records, summaries, indexes, pointers, and signals — exist to make that knowledge faster to find. Its safety comes from where those outputs live (governed and backed up by the source) and from always citing what they point to, not from a rule that they can never contain original content.
+- **Knowledge stays authoritative where it lives** — each piece of knowledge stays authoritative in the data source that owns it. The Discovery Layer isn't a place to author authoritative knowledge for its own sake; its resources — DL records, summaries, indexes, pointers, and signals — exist to make that knowledge faster to find. Its safety comes from where those resources live (governed and backed up by the source) and from always citing what they point to, not from a rule that they can never contain original content.
 - **Secure by default** — least privilege, deny when unsure, and access always enforced by the *original data source*, never by the Discovery Layer's own metadata. A wrong entry can misdirect a lookup but can never unlock a door.
 - **Build on existing sign-in** — access reuses the existing Google SSO (single sign-on) and its group permissions instead of standing up a new identity system. (Sources that don't already use Google groups need a one-time mapping — see <u>Architecture</u>.)
 - **Earn each step** — add each capability only once the previous one's limits prove it's needed; spend follows evidence, not ambition.

lik-ui/src/lik_ui/static/lik-key-concepts-diagram.svg

@@ -6,12 +6,12 @@
 
 1. **Data Sources (DSs)** — the systems where knowledge is actually created, corrected, and governed (Drive, Confluence, Jira, GitHub, Slack, Salesforce, Workday, …). These hold the **primary knowledge** and stay **authoritative** for it: every lasting change is written here, and each system keeps controlling who may see what. An individual unit stored in a DS — a Confluence page, a Jira ticket, a Slack thread, a GitHub PR — is a **DS record**. What separates a plain DS record from a **DL record** is **purpose, not how it was produced or what it contains**: a DL record is a DS-stored record whose job is to be an *entry point an AI agent looks at first* — a summary, index, pointer, or signal that makes the underlying knowledge faster to find. Because a DL record lives in a DS, that DS stores, backs up, and governs it like any other record. Most DL records are generated automatically and rebuilt on demand, but a person may author or edit one — even adding original content — and it stays a DL record as long as its purpose is to be that entry point.
 
-2. **Discovery Layer (DL)** — prepared material whose only job is to make knowledge **easy to find and reuse**, so tools don't re-search everything from scratch. Each piece is a **DL output**. What makes something DL is **purpose, not how it was produced**: it exists to be a fast entry point into the knowledge, not to be authored as knowledge for its own sake. **Two things are easy to conflate here, so keep them apart.** *Derived* describes the content's relation to the sources — it summarizes or points at what they already hold rather than adding new knowledge (a rule of thumb: remove the underlying records and a typical DL output has nothing left to describe). *Automatically generated* (`ai-generated`) describes who produced it. **Neither implies the other:** a person can hand-author derived material — a summary they write by hand is derived yet `human-created`. Most DL is both derived and auto-generated, but that's a common pairing, not a rule. And DL's safety doesn't rest on its content being purely derived anyway: it is still governed by the source it lives in, still cites what it points to, and still carries freshness signals.
+2. **Discovery Layer (DL)** — prepared material whose only job is to make knowledge **easy to find and reuse**, so tools don't re-search everything from scratch. Each piece is a **DL resource**. What makes something DL is **purpose, not how it was produced**: it exists to be a fast entry point into the knowledge, not to be authored as knowledge for its own sake. **Two things are easy to conflate here, so keep them apart.** *Derived* describes the content's relation to the sources — it summarizes or points at what they already hold rather than adding new knowledge (a rule of thumb: remove the underlying records and a typical DL resource has nothing left to describe). *Automatically generated* (`ai-generated`) describes who produced it. **Neither implies the other:** a person can hand-author derived material — a summary they write by hand is derived yet `human-created`. Most DL is both derived and auto-generated, but that's a common pairing, not a rule. And DL's safety doesn't rest on its content being purely derived anyway: it is still governed by the source it lives in, still cites what it points to, and still carries freshness signals.
 
-   By **where it lives and who keeps it safe**, every DL output is one of three:
+   By **where it lives and who keeps it safe**, every DL resource is one of three:
    - **DL records** — the common case, and most of DL: each a record written into a Data Source (such as a Confluence page) whose purpose is to be an AI entry point — a summary, index, pointer, or signal — marked `discovery-layer` to flag that role (the marker exists so the registrar can *discover* the record; a human-registered entry point may forgo it — see **Catalog-registration** below). Because it lives in a Data Source, **that source stores, backs it up, and governs it** like any other record, and reverting to an earlier version is its recovery. DL records divide by how they stay current: **automatic** ones are generated and rebuilt from the sources on demand (disposable); once a person edits, verifies, or hand-authors one it becomes **durable** — the automated rebuild never silently overwrites that copy: it leaves it alone, or surfaces a proposed update for the owner to accept, reject, or reconcile.
    - **The Catalog** — one well-known directory mapping a *topic* to *where its material lives*, so a tool does **one lookup** then follows the pointer instead of searching every system (move a piece and you change one line, not the tools). It's built only from the **DL records** — not the full sources — so there's far less to process. Those records hold the same "what exists and where" at finer granularity; the Catalog is the coarse, topic-level view over them. Rows a skill registered are recomputed and don't need to be backed up; the human-registered rows can't be regenerated, so those are backed up — the Catalog as a whole is not safe to drop and rebuild.
-   - **Confirmation signals** — people vouching that the source behind an answer was right (or flagging it wrong). A confirmation attaches to the **cited DS record or DL output the answer drew from**, never to the AI's response text — which is why answers always cite their sources. A **Query skill** records one when a person gives positive or negative feedback on a cited source. It can't be re-derived, so it must be **kept deliberately** rather than simply rebuilt — as must a human-registered Catalog row; what's special about a confirmation is that it has no copy in any Data Source at all, so DL's own store is its only home.
+   - **Confirmation signals** — people vouching that the source behind an answer was right (or flagging it wrong). A confirmation attaches to the **cited DS record or DL resource the answer drew from**, never to the AI's response text — which is why answers always cite their sources. A **Query skill** records one when a person gives positive or negative feedback on a cited source. It can't be re-derived, so it must be **kept deliberately** rather than simply rebuilt — as must a human-registered Catalog row; what's special about a confirmation is that it has no copy in any Data Source at all, so DL's own store is its only home.
 
 3. **DL-creation skills** — the automated *producers*. Each reads the Data Sources and writes DL records, tagging each with the metadata a registrar needs to catalog it (its key, its audience, and the sources it came from); each runs on its own service identity, on a schedule or on demand. **There are many, not one** — a given skill is customized to the kind of source data it handles, so it can process and validate that source the way its owning team needs. Producing a DL record is a distinct job from cataloging it.
 
@@ -25,9 +25,9 @@
 
 Two relationships tie these together:
 
-- The **DL-creation skill** takes **DS records** and creates **DL output**.
+- The **DL-creation skill** takes **DS records** and creates **DL resource**.
 - The **Catalog-registration skill** finds those **DL records** and registers them in the **Catalog**.
-- The **Query skill** queries **DL output** and **DS records** to answer a person's question.
+- The **Query skill** queries **DL resource** and **DS records** to answer a person's question.
 
 ## Progressive disclosure: answering in cheap steps
 
@@ -43,7 +43,7 @@ The Catalog and the Discovery Layer let an agent find an answer in increasingly
 | LIK concept | Office building | Why it fits |
 | --- | --- | --- |
 | DS records | The individual offices, where the real work and records are kept | Authoritative for what they hold; each office controls who it lets in. |
-| DL output | Handouts and digests *about* what the offices do — at reception, on floor screens, in a kiosk | Entry points so you don't visit every office; most are regenerated automatically, some can be hand-written. |
+| DL resource | Handouts and digests *about* what the offices do — at reception, on floor screens, in a kiosk | Entry points so you don't visit every office; most are regenerated automatically, some can be hand-written. |
 | Confirmation signals | Visitor feedback cards — "Suite 4B actually solved my problem" | People vouching an answer was good; kept on the card, not inside the office. |
 | Catalog | The lobby directory — topic → where its handout is posted | The board everyone checks first; points to *where the handout lives*, not into the offices. |
 | DL-creation skills | Information officers, each assigned to certain offices — they tour them and write the handouts | Produce the derived material; each specializes in the offices it knows. |