The DDS team knowledge base — products, services, processes, people, and frameworks. A linked wiki, rendered as a searchable website with Quartz.
A compounding wiki the team maintains together. Contributors curate sources and direct the analysis; the wiki's job is to summarize, cross-reference, file, and keep everything current — the bookkeeping that otherwise gets abandoned.
Pages are interlinked with [[wikilinks]]. Dependencies, ownership, and
relationships are always one click away. The graph view shows how everything
connects.
- Data products — pipelines, quality checks, dashboards
- Services and tools
- Processes and workflows
- People, roles, and ownership
- Frameworks and concepts — data governance, product lifecycle
- Comparisons — side-by-side analysis across entities
New entity types can be added as the team's needs grow.
Pages are organized by kind: entities in wiki/entities/, concepts in
wiki/concepts/, comparisons in wiki/comparisons/, and immutable source
material in wiki/raw/.
The same protocol applies to every contributor. Every change goes through the same path: source → wiki pages → commit. The index is regenerated for you on push (see below) — you never have to touch it.
- Read first. Before adding anything, read
wiki/SCHEMA.md(conventions and templates) andwiki/index.md(what already exists). This prevents duplicates and missed cross-references. - Pick the right template. Entities use the canvas for their subtype
(Data Product, Service, Process, Team Resource, Person) and live in
wiki/entities/. Concepts are free-form but need frontmatter and live inwiki/concepts/(e.g. frameworks like data governance). Cross-entity comparisons go inwiki/comparisons/. - Cross-reference. Every new or updated page must link to at least 1 other
page via
[[wikilinks]](2+ is better — the graph is the point). Update existing pages that should link to the new one too, so it isn't an orphan. - Commit. One commit per logical change, with a message describing what
changed and why — git history is the wiki's changelog. Push triggers a site
rebuild, and CI regenerates
wiki/index.mdfrom page frontmatter and commits it back — never edit the index by hand. (To preview it locally,npm run index; the one-line entry comes from each page'ssummary:field.)
1. Choose the right template from wiki/SCHEMA.md
2. Create the page in wiki/entities/ (lowercase, hyphens, .md)
3. Fill in the template sections — use (TBD) for unknowns
4. Add [[wikilinks]] from any related pages
5. Verify — npm run check
6. Commit (CI regenerates the index; the commit message is the changelog entry)
When new information arrives — a meeting transcript, a GitHub issue, a document:
1. Save the raw source in wiki/raw/ by type — articles/, issues/,
presentations/, specs/, or transcripts/ (immutable — never edit sources)
2. Identify which existing pages are affected
3. Update each affected page with new facts
4. Add new pages if the source introduces new entities
5. If new info contradicts existing content, note both claims
and flag the contradiction in frontmatter
6. Verify — npm run check
7. Commit (CI regenerates the index; the commit message is the changelog entry)
A reusable brief that captures the whole ingestion task in one place — hand it, plus the source, to whoever (or whatever) is doing the write-up:
Read
wiki/SCHEMA.mdandwiki/index.md. Ingest the following source into the wiki. Extract entities, ownership, dependencies, SLAs, and lifecycle info. Update every affected page with[[wikilinks]]. Add new pages if needed. Runnpm run checkto verify (CI regenerates the index on push). Do not commit — I'll review first.
Run npm run check before committing. It lints every page — the same check CI
enforces on push:
- Required frontmatter present (
title,summary,created,updated,type,sources) — keys must exist;sources: []is allowed.confidenceis optional (defaults tolow) - Every page links to at least 1 other, with no broken
[[wikilinks]] - No orphan pages (every page has at least one inbound link)
wiki/index.md is regenerated and committed by CI on push, so it's not part of
the local check — you never edit or regenerate it by hand.
Browse: https://cal-itp.github.io/central_docs/ — search, graph view, tags.
Edit: Open in Obsidian as a vault, or edit markdown directly. Follow the
conventions in wiki/SCHEMA.md. See Contributing for the full
protocol.
Starter templates for every page type live in wiki/templates/ and are wired to
Obsidian's built-in Templates plugin. To add a page by hand: create the note
in the right folder (wiki/entities/, wiki/concepts/, or wiki/comparisons/),
then run the command palette's Templates: Insert template and pick the canvas
that fits (data product, service, process, team resource, person, concept, or
comparison). The template fills in the required frontmatter and section headings.
Example links in the templates are shown as inline `[[code]]` so inserting a
template never creates stray empty pages — replace them with real [[wikilinks]]
(no backticks). Then delete the %% ... %% hints and run npm run check. CI
regenerates the index on push, so there's no index step.
Check your changes (no dependencies — needs only Node):
npm run check # lint every page (frontmatter, wikilinks, orphans)
npm run index # optional — preview wiki/index.md locally (CI does this on push)Preview locally:
scripts/build-site.sh --serveQuartz is not vendored into this repo — scripts/build-site.sh clones it
(pinned version) into a gitignored quartz/ directory on first run, overlays
quartz.config.ts, then builds and serves. To upgrade Quartz, bump the version
in that script and delete the local quartz/.
Push to main → GitHub Actions lints the wiki → regenerates wiki/index.md and
commits it back if it changed → builds the site (Quartz cloned fresh) → deploys
to GitHub Pages. A lint failure (bad frontmatter, broken link, orphan page)
blocks the deploy. No manual build or index step needed.