Skip to content

README.md

Latest commit

 

History

History
97 lines (66 loc) · 5.65 KB

README.md

File metadata and controls

97 lines (66 loc) · 5.65 KB
Raw

Affine Tech Writing

Workspace for the Affine (Bittensor Subnet 120) whitepaper, and (later) the arxiv paper that derives from it.

Private working repo. Once the v1 draft is ready it will be moved or mirrored to a shared location.

Read the outline

The single canonical view is whitepaper/00-outline.md. Open it in VSCode and press Cmd/Ctrl + Shift + V for the markdown preview.

One-time VSCode setup for diagrams: install the Markdown Preview Mermaid Support extension (bierner.markdown-mermaid). VSCode's built-in markdown preview does not render Mermaid by default; with the extension, every ```mermaid code block renders inline.

For collaborators and their coding agents

If you are Tobias, Pablo, Allan, Tong, or Nick, this section is your operating manual. Hand this README + STYLE.md to your coding agent — that is everything it needs.

Instructions for the coding agent

Step 0 — Identify the user and read the writing guide. Before doing anything else in this repo, ask the user which of these team members they are:

  • Tobias
  • Pablo
  • Allan
  • Tong
  • Nick

If the user is none of the above, stop and ask Nick before making any changes — outsiders should not modify this repo without coordination.

Then read STYLE.md once, end to end. It defines the file/folder layout, heading levels, titled-paragraph format, figure tooling, uncertainty markers, and tone every contribution must follow. Read it once at the start of the session and you can stop thinking about formatting.

Step 1 — Sanity-check the overall outline. Open whitepaper/00-outline.md and read it end to end. Before doing anything section-specific, ask the user:

  • Does the overall structure make sense? Are there sections that should be added, merged, removed, or reordered at the top level?
  • If the user wants any structural change, make the change first, then assign an owner to any new or substantially restructured section in the Ownership table, then move on.

This step is shared across all collaborators — it is a sanity check, not section-specific work.

Step 2 — Look up the user's owned sections. In the Ownership table, find every section the user owns. From this point on, your scope of work is exactly those sections — do not edit prose or restructure subsections in sections owned by other people. If you think a change to someone else's section is necessary, raise it with the user as a question rather than editing it.

Step 3 — Own the section. For each section the user owns, the user is responsible for the structure, content, and visuals of that whole section. Walk the user through it however makes sense — review the subsections, check the page plans, check the draft files in the corresponding whitepaper/0N-*/ folder, build figures, fill in TODOs, mark uncertainty inline. There is no prescribed order. Just deliver the section.

All the formatting rules, file/folder naming, figure tooling, and uncertainty markers are in STYLE.md. Read that once at the start of the session.

Step 4 — Watch for cross-section references. A few sections reference each other. If you change any of these substantially, ping the dependent owner (or open a question in the PR):

  • §3 (Mechanism) forward-references §5 (Environments), §6 (Scoring), §8.4 (Distillation pipeline).
  • §7 (Mining Tutorial) forward-references §8 (Training Methodology) for the deep dive on recipes.
  • §9 (Empirical Benchmarks) cites the active environment list from §5.
  • §10 (Roadmap) references nearly everything.

Workspace pointers

  • whitepaper/00-outline.md — the outline (TOC, ownership, per-subsection page plans, figure index)
  • STYLE.md — formatting, file structure, figure tools, uncertainty markers
  • CONTEXT.md — source-of-truth pointers (AffineFoundation/CONTEXT.md, the live system config API, affine-cortex source, Discord, Twitter, the verified active environment list) and the open questions Nick still needs to resolve

Layout

tech-writing/
├── README.md
├── STYLE.md             ← writing guide for all contributors
├── CONTEXT.md           ← source-of-truth pointers + open questions
├── whitepaper/
│   ├── 00-outline.md    ← THE outline (single canonical view + ownership table)
│   ├── 01-abstract/         (one folder per section)
│   ├── 02-introduction/
│   ├── 03-mechanism/
│   ├── 04-architecture/
│   ├── 05-environments/
│   ├── 06-scoring/
│   ├── 07-mining-tutorial/
│   ├── 08-training/
│   ├── 09-benchmarks/
│   ├── 10-roadmap/
│   └── figures/         ← Mermaid sources, matplotlib scripts, Excalidraw exports
└── references/          ← reference material (Templar paper, screenshots, link collection)

Each section folder contains one markdown file per subsection (N.M-short-name.md); each file is one page in the final whitepaper. See STYLE.md for the conventions.

Future export targets

Target Purpose Tool
PDF whitepaper Investors, partners, Twitter pandoc → LaTeX → PDF (or Typst)
Web (Mintlify / GitBook) Public-facing reading experience port markdown into the chosen renderer
Notion Non-technical stakeholder review Notion markdown import
arxiv paper Academic publication rewrite + restructure into LaTeX/Typst

License

TBD — defaults to "all rights reserved" until decided.