Parameter Golf Research Garden

Quartz Structural Proposal for the Parameter Golf Garden

7 min read

This proposal translates the audit in IA report into a concrete research-first structure.

The goal is not “make the site prettier.” The goal is:

make the best research paths obvious before readers fall back to filesystem browsing, generic tags, or random note hopping.

Design principles

1. Route by research intent first

The garden should first answer:

  • are you here to understand the challenge?
  • interpret the public record?
  • find the best open research bets?
  • study a mechanism family?
  • inspect operations / harness details?

Only after that should it expose note types and folder structure.

2. Keep the site shaped like a research program, not a blog

That means:

  • no chronology-first navigation
  • no “recent posts” mentality as the primary path
  • no assumption that all leaf notes deserve equal prominence

3. Use hubs to compress complexity

A good hub should:

  • explain why a section exists
  • say who should start there
  • give a short recommended reading order
  • route into a few best pages, not every page equally

4. Use tags and graph as reinforcement layers

Tags and graph should help readers once they are inside the structure. They should not be asked to substitute for structure.

Proposed top-level research model

The clearest public model for this garden is:

  1. Challenge — what the game rewards
  2. Public Record — what has already become legible
  3. Research Program — the main lanes and frontiers
  4. Active Bets — hypotheses and experiments
  5. Literature Shelf — papers and supporting notes
  6. Operations — meta / harness

Mapped onto existing pages, that means the primary public spine should be:

Proposed role for each major hub

Home

Role: orientation by reader intent.

Home should feel like a compact decision page, not a broad directory.

It should route explicitly into:

  • challenge framing
  • public record
  • frontier ideas
  • lane map
  • active hypotheses
  • literature shelf
  • meta

Challenge

Role: problem statement and scoring logic.

This is the place to answer “what is Parameter Golf really optimizing?”

Challenge history

Role: public record and strategic opening map.

This should sit directly beside challenge framing, not behind it.

Research lanes

Role: stable conceptual map of the design space.

This is where readers choose a mechanism family.

Research frontiers

Role: highest-value “what should I read next?” page.

For serious researchers, this is the page that should increasingly feel like the center of gravity.

Hypothesis ledger

Role: active, falsifiable bets.

This should answer what is currently worth testing, not simply what is interesting.

Paper index

Role: curated shelf, not primary orientation layer.

The paper index is valuable, but it should usually be reached from a lane, frontier, or hypothesis, not treated as the main landing route.

Meta layer

Role: operations boundary.

This should remain clearly separated from the research graph.

Path 1 — serious newcomer

Use when the reader wants a correct mental model before diving into mechanisms.

  1. Challenge
  2. Constraints and scoring
  3. Challenge history
  4. Public runs
  5. Research lanes
  6. Research frontiers
  7. Hypothesis ledger

Path 2 — best current ideas

Use when the reader wants leverage, not broad orientation.

  1. Research frontiers
  2. chosen lane page
  3. linked hypothesis page
  4. linked supporting notes and papers
  5. experiment record if it exists

Path 3 — public competitive landscape

Use when the reader wants to know what is established, what is speculative, and what still looks open.

  1. Challenge history
  2. Public runs
  3. Public research directions
  4. Research frontiers
  5. relevant lane page

Path 4 — mechanism-first expert

Use when the reader already knows the challenge.

  1. Research lanes
  2. lane page
  3. hypothesis cluster
  4. notes cluster
  5. paper cluster
  6. experiment or idea pages as extensions

Explorer proposal

Current problem

The explorer is useful as a maintainer tree but weak as a research navigator because it is:

  • fully open
  • alphabetic
  • folder-first
  • not priority-aware

Proposed role

The explorer should become a section compass, not a full public dump of every note.

Good explorer outcome

A reader should be able to glance at the left rail and immediately see:

  • the main public reading path
  • the major research regions
  • the operations boundary

Suggested explorer hierarchy

If the explorer remains folder-based, its conceptual order should be closer to:

  1. Home
  2. Challenge
  3. Challenge History
  4. Research Lanes
  5. Research Frontiers
  6. Hypotheses
  7. Papers
  8. Notes / Ideas / Experiments
  9. Meta
  10. Reports

Practical implication

The explorer should bias toward major hubs first and treat notes, ideas, and experiments as deeper layers rather than equal-status siblings of the top-level map.

Tag strategy proposal

Current problem

The current flat tag set is too noisy for either tag pages or graph use.

Proposed model: hierarchical tags with clear roles

Quartz tag pages support prefix hierarchies, so the tag system should use slash-based families.

1. Document-type tags

Examples:

  • doc/hub
  • doc/paper
  • doc/note
  • doc/frontier
  • doc/hypothesis
  • doc/idea
  • doc/experiment
  • doc/meta
  • doc/report

These should be used sparingly and consistently.

2. Research-domain tags

Examples:

  • topic/quantization
  • topic/recursive-sharing
  • topic/tokenizer
  • topic/output-head
  • topic/inference-time-compute
  • topic/public-record
  • topic/artifact-budget

These should become the main faceting layer.

3. Status tags

Examples:

  • status/active
  • status/promising
  • status/open
  • status/speculative
  • status/reference
  • status/archive

These help distinguish frontier notes, live hypotheses, and background shelf material.

4. Scope tags

Examples:

  • scope/challenge
  • scope/local-benchmark
  • scope/public-history
  • scope/meta

These clarify whether a page is challenge-facing, local-only, or operational.

Tag rules

Use tags for orthogonal structure, not folder echo

Bad pattern:

  • folder = papers/
  • tag = paper

Better pattern:

  • folder = papers/
  • tags = doc/paper, topic/quantization, status/reference

Avoid single-use decorative tags

If a tag will only ever appear once, it is usually better expressed in prose.

Prefer tags that answer discovery questions

A useful tag helps readers ask things like:

  • show me all active work on recursive sharing
  • show me public-record pages
  • show me topic pages about output-head cost

Graph proposal

Current problem

The graph currently competes with the text route at Map of content while also inheriting noisy tags.

Proposed role

The graph should be a secondary sensemaking tool for readers who are already inside the garden.

  • local graph near leaf pages: good
  • global graph for discovery after entering via a hub: good
  • graph as the first answer to “where do I start?”: weak

Best structural improvements for graph discoverability

1. Stop overloading the word “graph”

Readers should not have to guess whether Map of content is a visualization route or a text map.

2. Reduce graph tag noise

If tags remain visible in the graph, only structured, reusable tags should survive.

3. Use hubs to explain when the graph is useful

Good guidance would be:

  • start with a hub page
  • use the local graph to branch sideways into related mechanisms
  • use backlinks to return to context

Routing cleanup proposal

1. Promote the missing hub routes

The strongest missing routes from the main spine are:

Before expanding breadth, resolve references to missing pages such as:

  • papers/awq
  • papers/quarot
  • papers/universal-transformers
  • papers/albert
  • frontiers/refinement-loops-as-decompression

3. Give each “map” page a single job

A cleaner split would be:

  • Home = start here / choose route
  • Map of content = text routing map only
  • Atlas = historical synthesis or internal map, not a competing entry point

4. Make maturity states legible

The garden already has distinct page types that reflect research maturity:

That progression is excellent material for a serious research garden and should be made more explicit.

Suggested implementation order

Phase 1 — discovery spine

  1. re-route home around challenge history and frontiers
  2. clarify the map / atlas / graph role split
  3. repair missing hub targets

Phase 2 — navigation quality

  1. make explorer prioritize hubs over folders-as-storage
  2. reduce graph/tag noise
  3. explicitly route readers by intent

Phase 3 — research-program clarity

  1. make ideas → frontiers → hypotheses → experiments progression legible
  2. connect experiment pages back into the main conceptual graph
  3. tighten the distinction between public-record pages and local research machinery

Bottom line

The highest-value structural move is simple:

treat the garden as a public-facing research program with curated entry routes, not as a notebook whose folder tree happens to be exposed.

If that principle holds, then the right priorities are:

  • elevate frontiers
  • elevate challenge history
  • keep papers as a shelf, not the main entrance
  • use tags and graph to reinforce structure rather than substitute for it

Graph View

Referenced by

Recent notes