wiki-compile

The "so what" test

If you cannot state a durable finding in one sentence, skip the compile. A formatting fix, a template tweak, or a mechanical rebuild does not need a wiki entry. The test is not "did something happen" but "will someone need to know this in three months without re-deriving it."

When to skip

• The output is a formatting-only change to a file that already exists.
• The output is an intermediate or draft that this same session will supersede.
• No new data, decision, join key, or analytical finding was produced.

Checklist

1. Read the wiki index to find existing pages this output touches.
2. Decide which pages need creating or updating: a dataset gets a 3-data/ page, an initiative gets an initiatives/ page, and so on, per your wiki's own routing rules.
3. Write or update the page with:
   • Frontmatter: title, type, created, updated, sources, tags.
   • ## Summary, ## Key facts, ## Analysis, ## Cross-references, ## Open questions, ## Sources, in that order.
   • [[wikilinks]] for every cross-reference: a bare path is not a link and does not show up in the graph.
   • A ## Sources section that is actually clickable: an in-vault page as a [[wikilink]], an external file as a file:// link, a conversation with no artefact as plain text. A page is not complete without this section.
4. Update the wiki index if a new page was created.
5. Append a dated entry to wiki/log.md:
   • Source (the output that triggered this compile)
   • Channel (what kind of event this was)
   • Pages created or updated
   • The one-sentence durable finding
6. If the new material contradicts something already on the page, flag the contradiction explicitly before overwriting it. Silently replacing a claim erases the reason someone believed the old one.

What to extract

• Why the work mattered: the problem it solved, what was at stake if nothing changed.
• Key numbers, totals, and variances, with the date they were measured.
• Decisions made and the reasoning behind them.
• Join keys, schema notes, and data-quality counts that the next build will need.
• What worked and what did not, for the next person attempting something similar.
• Open questions the work surfaced but did not answer.

What not to extract

• File paths, formatting details, script mechanics: these belong in the code's own header comment, not the wiki.
• Anything already captured in the project's own log file.
• Ephemeral task state that will be stale by next week.

Ticket write-back

After a Jira or Smartsheet write specifically:

1. Add the issue key (or row reference) and its URL under ## Sources on the initiative's wiki page.
2. Add the same reference to the day's session log.
3. If the ticket resolved an open question that was sitting on the wiki page, close it out there rather than leaving it to go stale.

The wiki holds the reasoning; the ticket holds the slice an engineer needs to act on it. Keeping the two linked in both directions is what makes the ticket defensible later and keeps the wiki from drifting out of date with what was actually done.

Optional: humanising pass

If the page carries a long block of narrative prose (a summary or analysis section running to more than a paragraph or two), consider a pass to strip stock phrasing before saving: antithetical pivots ("not X, but Y"), throat-clearing openers, and listicle padding read as generated even when every fact in them is correct. This is optional and has no bearing on whether the compile itself happens.