Wiki Schema — Standing Instructions for AI Agents

Owner: Paul Wiki domain: Broad professional knowledge Audience: Paul + AI agents (no other human readers) Last revised: 30 May 2026 Schema version: 2.0 — adds §10 Graph & Relationship Layer (frontmatter properties, typed edges, tag taxonomy, graph colour). All v1 sections unchanged; v1 content and rules remain in force.

How to use this file. Any AI agent operating on this wiki must read this schema first and follow it as standing editorial policy. The schema is more authoritative than any individual prompt. If a user request contradicts the schema, ask before acting.

1. Wiki Purpose Statement

This wiki exists to (a) build compounding professional understanding across the topics Paul actively works in, (b) serve as a reliable operational reference Paul can consult before meetings or decisions, and (c) capture project context that survives between sessions. It is not a personal journal, not a public publication, and not a place for content that hasn’t been read or thought about — every page must be grounded in real source material.

2. Page Types

The wiki contains exactly six page types. Do not invent new ones without updating this schema.

Graph layer (v2). Every page now also carries a YAML frontmatter property block at the very top (above the H1) and uses typed-edge inline fields and a controlled tag vocabulary. The page-type structures below are unchanged; the frontmatter block sits above them. See §10 for the property block, the edge ontology, the tag taxonomy, and the graph-colour conventions. The standalone references are _schema/graph-and-edges.md and _schema/tag-taxonomy.md.

2.1 Topic Page (the core synthesis unit)

What it is. A layered synthesis of everything the wiki knows about a single concept, theme, or domain area.

Trigger for creation.

A second source has arrived on a theme that previously only had one source — promote from a Source page note to a Topic page.
Paul explicitly requests a Topic page.
Two existing Topic pages keep cross-referencing the same unnamed concept — extract it into its own page.

Required structure (in this order):

# {Topic Name}

**Created:** YYYY-MM-DD   **Updated:** YYYY-MM-DD   **Source count:** N

## TL;DR
2–4 sentences. Plain prose. The fastest correct answer to "what is this?"

## Key Points
Bullets. Each bullet ends with an inline source tag like [S-2025-04-12-foo].

## Detail
Layered prose. Headings as needed. This is where nuance lives.

## Practical Applications
How this concept shows up in real work / decisions / tools. Required if applicable; write "None identified yet" otherwise.

## Related Concepts
Wikilinks to other Topic, Concept, Technology, or Company pages. Brief one-line note on the nature of each link (e.g. "→ [[Bayesian inference]] — underlying method").

## Open Questions
Things sources disagree on, or that the wiki doesn't yet have a confident answer to. Never empty by default — if there genuinely are none, write "No open questions surfaced yet".

## Tensions / Contradictions
Visible disagreements between sources on this topic. See §4 for handling rules. Omit section only if zero contradictions exist.

## Sources
List of `[S-tag]` → linked source page. One line per source.

Linking rules. Every claim in the Key Points and Detail sections must end in a [S-tag] referring to a Source page. No exceptions. See §6.

2.2 Source Page (one per ingested source)

What it is. A faithful summary of a single source — article, paper, meeting note, own writing — separate from any synthesis.

Trigger for creation. Every source ingested gets a Source page. Always.

Required structure:

# {Source title}

**Tag:** S-YYYY-MM-DD-shortslug
**Type:** article | paper | report | meeting-note | own-writing
**Author(s):** ...
**Date of source:** YYYY-MM-DD (publication or meeting date)
**Date ingested:** YYYY-MM-DD
**Authority weight:** high | medium | low — with one-line reason
**Raw file:** link to /_raw_sources/...

## What it claims
Faithful summary. Use the source's own framing. 100–400 words.

## Notable quotes
Verbatim quotes worth preserving, in quotation marks, with locator (page / paragraph / timestamp).

## What's speculative vs. asserted
Required section. Mark which claims the source treats as established vs. proposed/speculative.

## Topics this feeds
Wikilinks to Topic pages this source has been folded into.

## Open questions raised
Anything unresolved or punted by the source.

Critical rule. A Source page is not synthesis. It represents what this one source says, attributed to it. Do not pull in context from other sources to fill gaps. If the source is wrong about something, note it inside the source page only as a comparison line — don’t rewrite what the source claims.

2.3 Entity Page — Company / Organisation

Trigger. Mentioned in 2+ sources, or central to an active project.

Required structure:

# {Company name}

**Type:** company | non-profit | regulator | research org | other
**Sector:** ...
**First seen:** YYYY-MM-DD   **Last updated:** YYYY-MM-DD

## Snapshot
TL;DR — what they do, why they matter to the wiki.

## Positions / Claims they advance
What this org argues, builds, or is known for. Each line sourced.

## Relationships
Wikilinks to: technologies they use/own, concepts they advance, other companies (competitor / partner / parent).

## Tracked changes
Dated bullets when something material changes. Old entries are not deleted.

## Sources

2.4 Entity Page — Technology / Tool / Method

Trigger. Mentioned in 2+ sources, or actively in use in a project.

Required structure:

# {Technology name}

**Category:** tool | framework | method | protocol | model
**Maturity:** experimental | adopted | mature | declining
**First seen:** YYYY-MM-DD   **Last updated:** YYYY-MM-DD

## What it is
Plain definition, 2–4 sentences.

## How it's used
Practical applications, with sourced examples.

## Theoretical basis
Concepts it depends on — wikilinks to Concept pages.

## Strengths / weaknesses
Sourced. If sources disagree, surface that under Tensions, not here.

## Tensions
Where sources disagree about this technology's value, fit, or maturity.

## Sources

2.5 Entity Page — Concept / Framework

Trigger. A theoretical idea that gets referenced from multiple Topic or Technology pages.

Required structure:

# {Concept name}

**Type:** mental model | framework | theory | principle | definition
**First seen:** YYYY-MM-DD   **Last updated:** YYYY-MM-DD

## Definition
Plain language. 1–3 sentences.

## Origin
Where it comes from (person, paper, tradition). Sourced.

## How it connects to other concepts
Wikilinks with one-line notes.

## Practical applications
Where in Paul's work this concept actually shows up.

## Tensions / variants
Different schools of thought, if any.

## Sources

2.6 Project Page

Trigger. Paul declares a project; or a sustained line of work appears across 3+ sources or meeting notes.

Required structure:

# {Project name}

**Status:** active | paused | done | abandoned
**Started:** YYYY-MM-DD   **Last touched:** YYYY-MM-DD

## Why this project exists
1–2 sentences of stated goal.

## Current state
Latest situation in 3–6 bullets. This section is rewritten in place; previous states move to "History" below.

## Decisions made
Append-only. Each entry: date, decision, why, link to sources/notes.

## Open questions / blockers
Live list.

## Connected wiki pages
Wikilinks to Topic, Technology, Company pages relevant to the project.

## History
Append-only diary of state snapshots when "Current state" gets rewritten.

## Sources / notes

2.7 Index / Map Pages

Trigger. When a category accumulates 8+ Topic pages, create a map page that groups them.

Required structure:

# Map: {Category}

Brief intro: what this map covers.

## Topics
Bulleted wikilinks, one-line description each.

## Adjacent maps
Wikilinks to other Map pages this overlaps with.

**Last updated:** YYYY-MM-DD

Map pages are pure navigation — no synthesis claims, no sources required.

2.8 Special: `open-questions.md`

A single global page that aggregates “Open Questions” pulled from every Topic page. Updated weekly. One section per topic, with wikilink back to the topic.

2.9 Special: Debate Page (rare)

Trigger. A contradiction within a Topic page grows beyond ~150 words or has 3+ sources on each side. Promote it from inline ## Tensions to its own page.

Structure:

# Debate: {short framing}

## The question
One sentence.

## Position A — {label}
Argument summary. Each claim sourced.

## Position B — {label}
Argument summary. Each claim sourced.

## Where they actually disagree
Locate the precise point of disagreement (often narrower than it looks).

## What would resolve it
Evidence that doesn't yet exist, or experiments that haven't been run.

## Sources

Never pick a winner unless one side has been definitively refuted by later sources — and even then, archive the loser’s position rather than delete it.

3. Cross-Referencing Rules

When a new source arrives.

Create its Source page first.
Identify which existing Topic / Entity pages it touches. Wikilink the Source page from each, and update those pages’ Key Points or Detail sections with the new claims (each ending in the new [S-tag]).
If the source raises a concept that has no page yet but seems durable, create the new page.
If the source raises something that may matter later but isn’t durable yet, add it only to the Source page.

When to update an existing page rather than create a new one.

The new source supports, refines, or contradicts existing claims on the page → update the page.
The new source is on the same broad topic but a clearly distinct sub-aspect → consider a new sub-Topic page, linked from the parent.

When a concept spans multiple topics.

If it shows up as a referenced concept in 3+ Topic pages, give it its own Concept page and replace inline definitions with wikilinks.
Never duplicate a definition across pages. Define once, link everywhere.

Wikilink format. Use [[Page Title]] for internal links. Always include a brief one-line note on the nature of the link (e.g. ”→ Bayesian inference — underlying method”). A bare wikilink with no description is not acceptable.

4. Contradiction Handling Protocol

This is the most important section of this schema. Wikis fail by smoothing contradictions into clean prose. This wiki must surface them.

Default behaviour: never resolve silently. When two sources disagree, the AI must do one of the following — never neither:

Surface inline. Add a ## Tensions section to the Topic page with both positions, each sourced. Acceptable when the disagreement is small and well-bounded.
Promote to a Debate page. Acceptable (and required) when the disagreement is sustained, multi-source, or central to the topic.
Ask Paul. Acceptable when the AI genuinely cannot tell whether the sources are disagreeing or talking past each other.

Authority weighting. Source authority is set per-source on the Source page (high | medium | low) using a loose hierarchy:

Peer-reviewed papers and primary data → typically high
Industry reports from credible organisations → typically medium-high
Expert essays / well-cited articles → medium
Opinion blog posts / unsourced claims → low

The AI may suggest a weight; Paul confirms or overrides. Authority is not a tiebreaker. Even a high-authority source can be wrong, and a low-authority source can be the only one to flag a real issue. Use authority to weight contributions, not to silence them.

Format for inline contradictions:

## Tensions

**On [precise sub-claim]:**
- Source A [S-tag-A] (high) argues: ...
- Source B [S-tag-B] (medium) argues: ...
- Where they actually disagree: ...
- Status: unresolved | partially reconciled | superseded by [S-tag-C]

Forbidden moves:

Quietly picking one side because it sounds more confident.
Averaging two positions into a vague middle.
Dropping a contradicting source from a topic because it complicates the synthesis.
Re-attributing claims to “some argue” or “it is sometimes said” — every claim has a [S-tag].

5. Editorial Standards

What to include from a source.

Claims central to the source’s argument.
Evidence, examples, and data points the source uses to support those claims.
Caveats and limitations the source itself acknowledges.
Verbatim quotes worth preserving (in the Source page).

What to exclude.

Filler, marketing, throat-clearing in articles.
Restatements of well-established context the wiki already has.
The AI’s own examples not present in the source. Never invent illustrative examples. If an example is needed and the source doesn’t provide one, write “No example given by source” or ask Paul.

Handling uncertainty in sources.

If a source hedges (“may”, “could”, “preliminary evidence suggests”), the wiki must hedge equivalently. Don’t strip the qualifier.
Tag speculative content explicitly: [speculative — S-tag] after the claim.

Attribution requirements.

Every factual claim in a synthesis page ends in a [S-tag].
If a claim integrates two sources, list both: [S-tag-A][S-tag-B].
If the AI cannot find a source for a claim, delete the claim rather than leave it unsourced.

When to quote vs. summarise.

Quote verbatim only on the Source page (in ## Notable quotes).
On synthesis pages, paraphrase. Use direct quotation only for short distinctive phrases (≤15 words) where the exact wording matters; put it in quotation marks with [S-tag].

Tone and voice.

Plain professional prose.
Direct, not hedging unnecessarily — but hedge faithfully when sources hedge.
No first-person (“I think”, “we should”) unless quoting Paul’s own writing.
No marketing voice, no clickbait headings, no emoji.

6. Maintenance Rules

Revise vs. add. Default to revising the existing page when a new source touches a known topic. Create a new page only when the new material is clearly a distinct topic / entity / concept.

Stale page marking. A Topic or Entity page whose newest source is older than 12 months gets a **Possibly stale — last source YYYY-MM-DD** banner near the top. The banner is removed when a fresh source updates the page.

Superseded information. Never delete. When a claim is overtaken by newer evidence:

Move the old claim into a ## History or ## Earlier view section on the page.
Date the supersession and link to the source that overturned it.
The old claim stays readable; future readers can see what was once believed and why.

Updated: field. Every time a page changes substantively, bump the Updated: date. Trivial typo fixes don’t count.

Index / Map maintenance. Map pages are reviewed monthly. Add newly-promoted Topic pages, retire pointers to merged pages.

Open Questions page. Refreshed weekly by sweeping every Topic page’s ## Open Questions section.

7. Source Handling

Raw sources are sacred.

Every ingested source is preserved verbatim in /_raw_sources/.
Filename matches the S-tag (e.g. S-2025-04-12-foo.pdf or S-2025-04-12-foo.md).
Raw sources are never edited. If a raw source contains errors, the corrections live in the Source page’s notes, not in the raw file.

Wiki pages are synthesised artifacts. They depend on raw sources but never replace them. A wiki page must always be reconstructible if needed by re-reading the listed sources.

Traceability standard. From any synthesis claim, two clicks: claim → Source page → raw source. If a claim can’t trace this path, it doesn’t belong in the wiki.

8. Folder Structure

/wiki/
  /_schema/
    wiki-schema.md          ← this file
    graph-and-edges.md      ← edge ontology + graph colour config (v2)
    tag-taxonomy.md         ← controlled tag vocabulary (v2)
    wiki-ingest-prompt.md   ← ingest prompt (carries the v2 graph addendum)
  /_raw_sources/            ← untouched ingested sources, named by S-tag
  /sources/                 ← one Source page per S-tag
  /topics/                  ← Topic pages (synthesis)
  /entities/
    /companies/
    /technologies/
    /concepts/
  /projects/                ← active and archived project pages
  /maps/                    ← index / map pages
  open-questions.md         ← global aggregator, weekly refresh
  README.md                 ← one-paragraph orientation for any new agent

Naming conventions.

Page filenames: kebab-case.md.
Source tags: S-YYYY-MM-DD-shortslug — date is the source’s own date, not ingestion date.
Wikilinks reference page titles, not filenames, so renames are safe.

9. Standing Instructions for the AI Agent (TL;DR)

When you are operating on this wiki:

Read this schema before acting. Re-read it when uncertain.
Every claim has a source tag. No exceptions. If you can’t source it, delete it.
Never invent examples. If an example is needed and not in the sources, say so.
Never silently resolve contradictions. Surface them in ## Tensions or a Debate page.
Never delete content. Mark superseded, move to History, but preserve.
Hedge as the source hedges. Don’t strip qualifiers. Tag speculation.
Wikilinks always carry a one-line note on the nature of the link.
Raw sources are read-only. Synthesise from them; never alter them.
When in doubt, ask Paul rather than guess.
Every page starts with the §10 frontmatter block. Set node-class, tags, dates, and the typed-edge properties. Frontmatter is added above the H1; it never replaces body content.
Typed relationships live in frontmatter (§10.2) as link-list properties — this is what the graph tools read. The body relationship section keeps a readable edge → [[Target]] — note mirror. Every edge is sourced or marked [inference].
Tags come from the controlled vocabulary in §10.3 / tag-taxonomy.md. Do not invent ad-hoc tags; extend the taxonomy file first.

10. Graph & Relationship Layer (v2)

This section makes the vault behave like a lightweight property graph (Neo4j-style): nodes carry typed properties, edges carry relationship types and direction, the core graph colours nodes by class, and Breadcrumbs (and optionally Juggl) renders typed, directional relationships. It is additive — it does not change any v1 rule. Companion files: _schema/graph-and-edges.md (edge dictionary, graph colour, plugin setup) and _schema/tag-taxonomy.md (controlled tags). This section is the authoritative summary.

Implementation lesson (2026-05-30). Typed edges MUST live in YAML frontmatter. Inline Dataview fields (implements:: [[X]] — note) are NOT reliably read by Breadcrumbs or Juggl — a trailing prose note after the link stops them building the edge. Frontmatter link-list properties are read cleanly by Breadcrumbs, Juggl, Dataview, and Bases. So edges are authored in frontmatter; the body keeps a human-readable mirror.

10.1 Frontmatter property block (mandatory on every page)

A YAML block at the very top of every page, above the H1. It mirrors the page’s bold metadata in machine-readable form (the bold metadata stays in the body — do not delete it) and carries the typed edges. Fields not relevant to a page type are omitted.

node-class: topic            # topic | source | company | technology | concept | project | map
title: EU AI Act
domain: [ai-regulation]      # see tag taxonomy; list allowed
jurisdiction: [eu]           # eu | uk | ie | us | global
service-line: []             # gfd | iga | pgs | rre (only where relevant)
status: active               # active | draft | stale
authority:                   # sources only: high | medium | low
created: 2026-05-17
updated: 2026-05-29
source-count: 5              # topics only
tags:
  - node/topic
  - domain/ai-regulation
  - juris/eu
# --- typed edges (see 10.2): one property per edge type, value is a list of wikilinks ---
maps-to:
  - "[[EBA Supervisory Direction on AI and Governance]]"
regulated-by:
  - "[[entities/companies/eu-ai-office|EU AI Office]]"
relates-to:
  - "[[topics/fca-approach-to-ai|FCA approach to AI]]"
  - "[[BCBS AI Governance Framework]]"

node-class is required (set from the folder, §10.4). Adding the block must never alter or remove body content.

10.2 Typed edges (relationship types)

Each relationship is a frontmatter property named for the edge type, whose value is a YAML list of "[[Target]]" wikilinks (always quoted — a bare [[X]] is invalid YAML). For every frontmatter edge, the page’s body relationship section (## Relationships / ## Related Concepts / ## Connected wiki pages) keeps a readable mirror line: - <edge> → [[Target]] — one-line note [S-tag]. The arrow form (not ::) avoids duplicate-key noise in Dataview.

Canonical edge vocabulary (full definitions, colours, and inverse pairs in graph-and-edges.md):

Edge	Direction / meaning	Inverse
`regulates`	regulator → regulated topic/firm	`regulated-by`
`implements`	project/firm → framework it operationalises	`implemented-by`
`evidences`	artefact → requirement it satisfies	`evidenced-by`
`maps-to`	cross-framework equivalence (symmetric)	`maps-to`
`depends-on`	technology/concept → concept it rests on	`supports`
`supersedes`	newer claim/source → older it replaces	`superseded-by`
`contradicts`	source/claim ↔ source/claim in tension (symmetric)	`contradicts`
`derived-from`	synthesis page → source it draws on	`feeds`
`competes-with`	company ↔ company (symmetric)	`competes-with`
`partners-with`	company ↔ company (symmetric)	`partners-with`
`parent-of`	parent → child	`part-of`
`relevant-to`	node → service line	`covers`
`relates-to`	generic fallback (use only when none above fit)	`relates-to`

Edge guardrails (extend §3/§4). A typed edge is a claim about a relationship and obeys all v1 attribution rules: it must be supported by the page’s sources or be explicitly marked [inference] on the body mirror line. Never invent a relationship to densify the graph. Only the edge target link goes in the frontmatter list — do not include wikilinks that merely appear in the prose note. contradicts is the structural form of a ## Tensions entry — it points at the disputing source/page and never resolves the tension.

10.3 Tag taxonomy (controlled vocabulary)

Tags are nested and drawn only from _schema/tag-taxonomy.md. Five facets: node class (#node/topic …), domain (#domain/ai-regulation …), jurisdiction (#juris/eu …), service line (#sl/gfd …), status (#status/active …). To add a value, add it to the taxonomy file first.

10.4 Folder → node-class mapping

Folder	node-class	colour
`/topics/`	topic	blue `#4C8DFF`
`/sources/`	source	grey `#8A8A8A`
`/entities/companies/`	company	red `#E5484D`
`/entities/technologies/`	technology	green `#30A46C`
`/entities/concepts/`	concept	purple `#8E4EC6`
`/projects/`	project	amber `#F5A623`
`/maps/`	map	teal `#12A594`

10.5 Graph view & Juggl

The core graph colours nodes by class via colour Groups in .obsidian/graph.json (path-based, works for everyone) and has direction arrows on (showArrow: true). Edge colour in the core graph is not supported by Obsidian.

Juggl (optional) renders typed, coloured edges from the frontmatter edges. Its stylesheet is .obsidian/plugins/juggl/graph.css; nodes are selected by node[path ^= 'topics/'] and edges by edge[type *= "implements"] (a contains match — Juggl’s edge type data can carry a trailing ::, and a class containing : is unselectable, so use *= on the data attribute, not a .type- class selector). Note: on current Obsidian, Juggl’s hover popover logs a harmless renderMarkdown error; it does not affect styling.

10.6 Relational complement (Obsidian Bases)

The Bases core plugin reads the §10.1 frontmatter to produce filtered table/card views (e.g. all node-class: source with authority: high). Bases views are navigation aids with no synthesis claims.

10.7 Breadcrumbs (typed navigation)

Breadcrumbs reads the frontmatter edges as typed links. Setup (one-time): register every edge type from §10.2 under Settings → Breadcrumbs → Edge Fields, and assign them to direction groups so the Matrix/Trail views work — up: part-of, depends-on, derived-from, regulated-by, implements, evidences; down: parent-of, supports, feeds, regulates, implemented-by, evidenced-by; same: relates-to, maps-to, competes-with, partners-with, contradicts, relevant-to; next/prev: superseded-by / supersedes. The Matrix view then lists a note’s typed neighbours grouped by direction; the Trail view shows ancestry. This config lives in .obsidian/plugins/breadcrumbs/data.json (edge_fields + edge_field_groups).

End of schema. Revisions to this document require changing the Last revised: date at the top.

Browse

wiki-schema

Wiki Schema — Standing Instructions for AI Agents

1. Wiki Purpose Statement

2. Page Types

2.1 Topic Page (the core synthesis unit)

2.2 Source Page (one per ingested source)

2.3 Entity Page — Company / Organisation

2.4 Entity Page — Technology / Tool / Method

2.5 Entity Page — Concept / Framework

2.6 Project Page

2.7 Index / Map Pages

2.8 Special: open-questions.md

2.9 Special: Debate Page (rare)

3. Cross-Referencing Rules

4. Contradiction Handling Protocol

5. Editorial Standards

6. Maintenance Rules

7. Source Handling

8. Folder Structure

9. Standing Instructions for the AI Agent (TL;DR)

10. Graph & Relationship Layer (v2)

10.1 Frontmatter property block (mandatory on every page)

10.2 Typed edges (relationship types)

10.3 Tag taxonomy (controlled vocabulary)

10.4 Folder → node-class mapping

10.5 Graph view & Juggl

10.6 Relational complement (Obsidian Bases)

10.7 Breadcrumbs (typed navigation)

Graph View

Table of Contents

Backlinks

Recently updated

2.8 Special: `open-questions.md`