Overview

A rigor framework is the required shape of an argument in a domain: what a conclusion note must contain before it counts as finished, such as a counter-thesis, alternatives, a corroboration count, or an assessment. Without one, a vault collects assertions in whatever shape they were captured and nothing can be checked. Schema mechanics are in vault-frontmatter-schema.

Pick the framework from the domain

Selection is the architect’s job, not the user’s.

Domain shapeFramework
Strategy, business, capital allocationMECE plus Minto pyramid
Software architecture and system designADR (architecture decision records)
Historical and biographical analysisFive-axis: actor, event, place, period, cause and effect
Empirical, medical, quantitative evidenceClaim, evidence, counter-evidence
Hypothesis-driven researchHypothesis, method, result, confound
Qualitative and interview researchCode, theme, triangulation
Legal, regulatory, contract, case lawIRAC (issue, rule, application, conclusion)
Investigative and accountability researchSource credibility and corroboration
Course and curriculum designBloom-aligned objective, concept, assessment
Philosophical and contested positionsArgument map

When two frameworks both fit, state the choice in one sentence each and let the user pick. Choosing silently between claim-evidence-counter and argument mapping decides whether the vault recommends actions or stakes out a position.

Encode the framework as schema and rules

A framework in a style guide is a suggestion. Encode it three ways.

  1. Required frontmatter fields. ADR atoms require adr_status and blast_radius; experimental atoms require n, effect_size, and replication_status; journalism claims require source_tier and corroboration_count.
  2. A required body structure. An ADR with no “Alternatives considered” section is incomplete, and that is checkable (rule S007).
  3. Filename prefixes. ADR-, hypothesis-, theme-, CT-. Prefixes let framework rules trigger only on notes that opted in.

The auditor reads all three from the spec, which turns a methodology into a gate (vault-audit).

Layer frameworks when domains differ in structure

A property portfolio (MECE plus a decision journal) may also hold the engineering decisions for its software (ADR) and tenant-dispute research (source credibility). Forcing all three into one framework loses what each is for.

  • Declare the layered frameworks in the spec so readers and agents know the mix is intentional.
  • Add each framework’s note types additively, with its own prefixes and fields. Existing notes are untouched.
  • Bridge frameworks with links, not merged schemas. An ADR resting on a strategic claim links that MECE atom; a decision resting on a qualitative theme lists it in key_atoms.

Do not fork into a second vault when domains cross-link; the cross-links are the value. Adding a framework to a live vault is covered in vault-evolution.

Compose a custom framework from primitives

For a novel domain, build from the units the named frameworks share: claim, evidence, counter, time or sequence, actor, and resolution criterion. Ask which of those the domain argues over and require exactly those.

Apply rigor at promotion, not capture

The framework sets the minimum shape of a finished note. Inbox and daily notes stay shapeless on purpose; the framework applies when a note becomes a permanent claim. Rigor on raw capture kills capture, and none at promotion kills the vault. The promotion step is in atomic-notes.