This page explains how the Signal documentation set is meant to be consumed, chunked, updated, and what it deliberately leaves out. Signal is Power Digital's internal business-intelligence web app; this set documents it for a Confluence-fed retrieval-augmented-generation (RAG) bot that answers employee questions about Signal. The set consists of 25 module pages (covering Signal's views and view-clusters, under modules/), a glossary (GLOSSARY.md), the access model (ACCESS-MODEL.md), the data-source map (DATA-SOURCE-MAP.md), a routing index (INDEX.md), and this README; a machine-readable companion to the data-source map, data-sources.json, ships alongside the set for programmatic consumers and is a build artifact, not a Confluence page. All content was generated from the Signal repository at staging commit 98df0c4 and verified 2026-07-07.
Intended audience and consumption model
This documentation set is written for machine retrieval first, humans second. The primary consumer is a Confluence-fed RAG bot: the pages are uploaded to Confluence, chunked, embedded, and retrieved to answer questions from Power Digital employees such as "what does VABO mean?", "who can see Divisional P&Ls?", or "where does the churn score come from?". Humans can read the pages top to bottom, but every writing decision optimizes for retrieval: plain declarative statements, terms expanded on first use within each section, and explicit answers embedded as FAQ entries on module pages. When routing a question, start from INDEX.md (the page inventory with the questions each page answers), use GLOSSARY.md for any single-term definition, use ACCESS-MODEL.md for any "who can see/do X" question, use DATA-SOURCE-MAP.md for cross-view data-lineage questions ("which views does Vena feed?", "what can Signal write where?"), and use the relevant modules/*.md page for anything about a specific view's data, metrics, workflows, or caveats.
Chunking assumptions (RAG rules)
Every page in the set follows the same structural contract so that chunking at the H2 level produces usable retrieval units:
H2 sections are the chunk unit. Each ## section is written to be self-contained: it re-states the view name, route, and enough context to be understood with zero surrounding text. A chunker that splits on H2 boundaries gets complete, answerable passages.
No backreferences. Sections never say "as described above", "see the previous section", or "as mentioned earlier". Cross-page pointers are absolute (page name + route), never relative.
Bot-friendly plain statements. Facts are stated declaratively with the subject named ("The Churn Risk module at /predictions/churn is visible to..."), not pronoun-heavy prose. Code constants are labeled as such with an as-of date, because they can change without a documentation update.
Module pages share a fixed skeleton: summary blockquote + fact table (route, access, data sources, writes, key code refs, last-verified stamp), then Purpose, Access & visibility, Data sources & lineage, Metrics & definitions, How it's used, What users can change here, Caveats & data quality, Related views, and FAQ. A retriever can rely on these section names.
Source attributions are consistent. Every number is attributed to its origin system using a fixed vocabulary: Vena (finance's system of record, read-only to Signal), Nova (Power Digital's client/org platform), Signal's own records (Supabase tables written by users in Signal), the AI/ML model pipeline, Salesforce, Gong, Google Sheets, ADP/Deel, NetSuite, or Anthropic Claude.
Update policy and freshness
The set is regenerated from the Signal repository on release — it is not hand-maintained between releases. The current content was generated and verified against staging @ commit 98df0c4, verified 2026-07-07; each module page carries this same "Last verified" stamp in its fact table. Rules for interpreting freshness:
Code is the source of truth. Where documentation and the running app disagree, the app wins; the discrepancy means a release landed after the last-verified stamp and the set is due for regeneration.
Code constants drift fastest. Thresholds, hardcoded email lists, feature-flag defaults, and cache TTLs are all labeled "code constant as of Jul 2026" precisely because they change without ceremony. Treat any such value as indicative, not contractual.
Upstream business rules can change invisibly. Some displayed values (P1/P2/P3 priority rules, model score logic, the CSM renewal tracker's contents, the KPI Google Sheet) are owned outside the Signal repo and can change with no Signal deploy and no documentation change.
Regeneration procedure: on each Signal release to production, re-run the documentation generation against the released commit, re-verify each module page against the code, update every "Last verified" stamp, and re-upload the set to Confluence, replacing the prior versions in place so page URLs and the bot's index stay stable.
What is deliberately NOT in this set
The following are intentionally excluded, so their absence is not a documentation gap:
Video scripts and training/walkthrough material. This set is reference documentation for retrieval; onboarding videos, demo scripts, and slide decks are maintained separately.
Staging-only features behind flags. Anything not reachable in the running app is not documented as if it existed. Concretely: the AI Agents views (/agent/insights, /agent/alerts, /agent/advisor) are behind SHOW_AI_AGENTS = false and are not mounted, so they have no module page; features merged to staging but not promoted to production are documented only once released, except where a module page explicitly marks something "(Beta)" because the running app does (e.g. ETCR).
One mounted Admin-tier view deliberately deferred in this revision. Insights (/insights, Admin+, link hidden from the nav but reachable by direct URL) is live in the running app but deliberately has no dedicated module page or data-sources.json entry in this revision. Its access rules are documented in ACCESS-MODEL.md's route table, and other pages may reference it by name. For questions about its content beyond access, the bot should say the view is not yet documented and route to the Signal team; a module page is slated for a future regeneration. (Client Profitability at /profitability, deferred in the original build, now has a module page — modules/client-profitability.md — and a data-sources.json entry.)
Secrets and operational credentials. Passwords (the Growth unlock password, the personnel export password), API keys, and environment-variable values are never stated — only the mechanism (which env var, who to ask) is documented.
Upstream systems' internals. Vena, Nova, Salesforce, Gong, ADP, Deel, and the AI/ML model pipeline are documented only to the extent Signal consumes them (what data, what cadence, what caveats) — not how those systems work internally or how to operate them.
Individual people data. No employee salaries, scores, or client-specific figures appear anywhere in the set; only the shapes and definitions of the data.
Support routing (for the bot)
Standard escalation defaults when a question goes beyond this documentation: technical installation, access, authentication, API-key, or permission issues route to the IT team; requests for new seats or budget route to the requester's manager; questions specific to client data and performance route to Iris (iris.novapower.io); creative performance insights and changes to client or team information route to Nova. Access-tier changes inside Signal are made by Gandalf-tier users on the General Access screen (/users), and Growth access is granted by Growth managers on /growth/access.