timchen0618/taxonomy-v0-viewer

Information-Scaffolds Taxonomy v0 Viewer

A static viewer for the v0 unified scaffold-unit taxonomy — 12 clusters derived by merging 22 cluster batches over 27,824 extracted scaffold units spanning three QA / retrieval benchmarks (browsecomp_plus, monaco, qampari).

For each cluster, the viewer shows one example unit per dataset (36 total), each rendered together with:

1. 1.Unit metadata — name, organizing_principle, description, scope_hint, question_class (what the cluster pipeline claims this unit is).
2. 2.Source scaffold — the full markdown/YAML scaffold the unit was extracted from (the actual "structure" the upstream LLM produced for that (dataset, qid)), rendered as markdown.

Files

index.html                # layout: sidebar + cluster header + dataset tabs + example panel
style.css                 # dark theme, matches monaco-benchmark-viewer
viewer.js                 # IIFE; load → render; keyboard nav (↑/↓ or j/k)
taxonomy_examples.json    # the data: 12 clusters × 3 datasets, with scaffolds inlined

The single data file is committed plain (no LFS — ~300 KB).

Data provenance

Examples are picked deterministically per cluster:

• —If the cluster's exemplar_id belongs to the dataset, use it.
• —Otherwise pick the member id whose source scaffold is closest to 5 KB (i.e. an "average-length", inspectable scaffold).

This avoids the LLM-exemplar bias that picked 11/12 exemplars from browsecomp_plus.

Local dev

cd taxonomy-v0-viewer
python -m http.server 8000
# then open http://localhost:8000/

Regenerating the data file

If the upstream taxonomy or scaffold extraction changes, rebuild taxonomy_examples.json from a Python shell or one-off script:

# rough sketch — adapt paths as needed
import json
from pathlib import Path
from collections import defaultdict

# 1. index extracted scaffolds by "<dataset>/<qid>" key
scaffolds = {}
with open('.../outputs/taxonomy/<run>/named-outputs/extracted/extracted') as f:
    for line in f:
        rec = json.loads(line)
        scaffolds[rec['key']] = rec['user_prompt']

# 2. index units by id
units = {}
for p in sorted(Path('.../batches').glob('batch_*_input.json')):
    for u in json.loads(p.read_text()):
        units[u['id']] = u

# 3. walk each cluster, pick one example per dataset, emit JSON
merged = json.loads(Path('.../merged_reconstructed.json').read_text())
# ... see the writeup in checkpoints/008 + 009 for the full script

Deploy

This folder is not yet an HF Space repo. To publish it as one:

cd taxonomy-v0-viewer
git init && git lfs install   # not needed unless data file > 10 MB
# Add a Space-style README header before pushing:
#   ---
#   title: Information-Scaffolds Taxonomy v0 Viewer
#   sdk: static
#   app_file: index.html
#   pinned: false
#   ---
git add . && git commit -m "Initial taxonomy-v0 viewer"
git remote add origin https://huggingface.co/spaces/timchen0618/<name>
git push origin main

Until then, it runs purely locally.

Why a 4th viewer (not a page inside one of the existing three)

The taxonomy is a cross-dataset artifact — it unifies scaffold units from all three benchmarks under a single 12-cluster ontology. It doesn't belong inside any one of the per-dataset viewers (browsecomp / qampari / monaco), and it has its own static-only deploy story (one JSON, no backend, no per-qid shards). Following the established pattern — one independent static folder per artifact — keeps the deploy boundaries clean.