Emergence

Concept page authoring

Properties2
descriptionThe acceptance contract, source standard, frontmatter, and canonical subject-folder pattern for a Concept page.
aliasesguides/technical-reference/concept-page-authoring

5 min read

A Concept is a durable, reusable explanation of one idea needed across Briefings and Reviews. It is locally understandable: a reader should not need to open the page that linked to it before the definition, notation, assumptions, or limits make sense.

The Concept files present on 2026-08-10 are a rewrite queue, not examples of an accepted body pattern. Do not copy their length, headings, claims, or reference lists into a new page. The maintained starting point is site/templates/concept.template.md; the quality contract below decides whether the resulting page is adequate.

Role boundary

Create a Concept when a Briefing or Review needs background on one reusable idea that does not already have a suitable page. Check existing filenames, aliases, and links before adding another page.

A Concept does not reconstruct the history or current state of a whole research field. A multi-source research topic, theory, or research program belongs in Topic Reviews. A generic term with no Emergence-specific explanatory need should not become a Concept merely to fill the tree.

Acceptance contract

A publication candidate must perform all of the following functions. The headings may change, combine, or disappear when the subject does not need them; the functions may not be skipped merely to keep the page short.

  1. Define and bound the idea. State what the term names, what problem it addresses, and what nearby ideas it does not include.
  2. Expose the working structure. Give the mechanism, formal object, equation, algorithm, or physical picture needed to reason with the idea. Define symbols and assumptions where they first matter.
  3. Interpret it. Explain what the formalism means and why the concept is useful, not only how it is written.
  4. State limits and confusions. Name important approximations, failure modes, trade-offs, and non-equivalences. Qualify scaling claims by their error model and assumptions.
  5. Connect it. Link genuine prerequisites, neighboring Concepts, and the Briefings or Reviews where the idea is used. Links supplement rather than replace local explanation.
  6. Match claims to sources. Support technical, quantitative, historical, and priority claims with primary or otherwise authoritative sources. Each reference note says which part of the page it supports.

There is no fixed word count. A page is complete when a STEM-educated reader can use the idea without guessing the omitted definitions or caveats, and no longer than needed to reach that point. Central reasoning remains in the body rather than being displaced into the references.

Source and claim rules

  • Read the sources used for the page; do not cite a search snippet, a citation copied from another page, or an AI summary as evidence.
  • Prefer original research for result and priority claims, and authoritative reviews or textbooks for established definitions and synthesis.
  • Separate a source’s result, its authors’ interpretation, and Emergence’s synthesis. Do not turn a limited result into a general capability claim.
  • Preserve uncertainty and conditions. A bound under a rank promise, a particular error metric, or a measurement model is not an unconditional scaling law.
  • Use ## References for works actually used to establish the page. A bibliography entry alone does not show which claim it supports, so append a short contribution note.
  • A Concept remains unlisted: true until source checking, human review, and explicit publication approval are all complete.

Frontmatter

Start from the repository template and replace every placeholder:

---
title: Quantum state tomography
description: Inferring a quantum state's density operator, or selected properties of it, from measurements on repeatedly prepared copies of the state.
status: draft
created: "2026-08-10"
updated: "2026-08-10"
last-edited-by: codex
subjects:
  - physics
domains:
  - quantum-information
topics:
  - quantum-state-tomography
unlisted: true
---
  • title / description — name the concept and give a one-sentence scope boundary. The description is visible in the page’s Properties block.
  • status: draft — the only currently defined Concept status. No renderer branches on it, and the post-draft value remains unresolved; do not invent one.
  • created / updated — quoted ISO dates. Preserve created; change updated after a material revision.
  • last-edited-by — the person or agent that performed the latest material revision.
  • subjects — broad academic fields used as working editorial descriptors.
  • domains — narrower research areas.
  • topics — usually the page’s own kebab-case slug.
  • unlisted: true — the publication gate, not a marker that may be removed when drafting finishes.

The broader subjects / domains / topics schema remains a working convention. Do not expand or normalize it as a side effect of rewriting one page.

One file per concept lives in the canonical subject folder matching the reserved field taxonomy: quantum-information-computing/, quantum-sensing-metrology/, many-body-materials/, ml-ai/, numerical-methods-optimization/, electronic-devices-engineering/, or mathematics/. quantum-sensing-metrology/ was the last of these created (2026-08-13, once its first real Concept needed it) — never add an empty subject folder or placeholder index for a genuinely new eighth field ahead of real content.

The filename is kebab-case and matches the concept slug. Folder placement supplies one canonical navigation home, not an exclusivity claim. Preserve genuine cross-field relationships through metadata and links.

Use a wikilink such as [[quantum-state-tomography|quantum state tomography]] for another page in this repository. Quartz’s markdownLinkResolution: shortest keeps that link stable if the target moves between subject folders. Use a normal Markdown link for external sources.

Rewrite check

Before handing a draft to human review:

  • compare it with all six acceptance functions above;
  • open every cited source and match it to the supported claim;
  • check equations, symbols, scope words, dates, and numerical bounds;
  • inspect incoming links so a renamed, merged, or re-routed page does not break its users;
  • build the site and inspect the rendered page at desktop and mobile widths; and
  • verify that an unlisted page is absent from the generated content index, sitemap, and RSS, not merely hidden from a navigation list.

See Research method, Source and review policy, and Publication gate for the shared editorial requirements.

Graph View