Rigor Frameworks

Overview

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

Pick the framework from the domain, not from the user

Framework selection is the architect’s job. Most people cannot name the framework that governs their own field, and asking them to choose pushes the work back onto them.

When two frameworks both plausibly fit, surface the choice in one sentence each and let the user pick. Silently choosing between claim-evidence-counter and argument mapping decides whether the vault is built to recommend actions or to stake out a position.

Encode the framework as schema and rules, not as advice

A framework written only in a style guide is a suggestion. Encode it three ways so it holds.

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 without an “Alternatives considered” section is incomplete, and that is checkable.
3. Filename prefixes. ADR-, hypothesis-, theme-, CT-. Prefixes let framework-specific audit rules trigger only on the notes that opted into them.

The auditor described in vault-audit reads all three from the vault spec, which is what turns a methodology into a gate.

Layer frameworks when the domains are structurally different

A vault legitimately spans several frameworks: a property portfolio (MECE plus a decision journal) that also carries the engineering decisions for the software being built (ADR) and the tenant-dispute research behind a claim (source credibility). Shoehorning all three into one framework loses what each was for.

Layering rules:

• Declare the layered frameworks in the vault spec so future readers and agents know the vault is intentionally multi-framework.
• Add each framework’s note types additively, with their own prefixes and required fields. Existing notes are untouched.
• Bridge frameworks with links, not by merging schemas. An ADR that rests on a strategic claim links that MECE atom; a decision that rests on a qualitative theme lists the theme atom in key_atoms.

Do not fork into a second vault when the domains cross-link, which they usually do. The cross-links are the value. The mechanics of adding a framework to a live vault are in vault-evolution.

Compose a custom framework from primitives when nothing fits

For genuinely novel domains, build the framework from the primitives the named ones are made of: the claim unit, the evidence unit, the counter unit, the unit of time or sequence, the actor, and the resolution criterion. Ask which of those the domain actually argues over, and require exactly those.

This is the right move for a new domain and the wrong move for an unfamiliar one. Check the table first.

Make the framework the default, not the ceiling

The framework sets the minimum shape of a finished note. It does not forbid extra structure, and it does not apply to capture. Inbox notes and daily notes are shapeless on purpose; the framework applies at promotion, when a note becomes a permanent claim.

Applying framework rigor to raw capture kills capture. Applying no rigor at promotion kills the vault. The line between the two is the promotion step described in atomic-notes, and the same separation of concerns argument appears in general-principles.

Related

• vault-architecture
• vault-frontmatter-schema
• decision-journals
• source-verification
• vault-evolution
• vault-audit
• general-principles