Methodology

1. Bind

Begin with a direct source, a named owner and a bounded task. A source can be an approved brief, a record, a specification or a supplied question. The point is to know what the work is answering and what it is not authorized to alter.

Binding avoids a common AI failure mode: broadening a request through adjacency. A model may recognize related work, but relation does not grant scope.

Worked example: A researcher receives a task: "analyze the performance of the new retrieval pipeline." Before writing a single line, they bind the work by naming the source (the pipeline specification, revision v2.3), the owner (the engineering team), the exact scope (compare recall@5 and latency P95 against the declared baseline), and the boundary (do not change pipeline configuration or evaluate on production traffic). Every decision that follows is traceable to this binding.

2. Make

Create the smallest artifact that gives the question a concrete form. That might be a method card, a source ledger, a typed record, a visual direction, a review packet or a runnable check. The artifact should have a readable shape and a place for the assumptions it uses.

Small artifacts are easier to review because their promises are small enough to test. They are also easier to replace when the underlying source changes.

Failure mode: Making one large artifact that tries to answer every possible question at once. This trades reviewability for comprehensiveness and usually achieves neither. The Fieldcraft principle of one technique per article is a defense against this.

3. Check

State a predicate before treating a result as useful. A check can establish a narrow property: that a field exists, a value stays within a budget, a source identifier still matches, or a lifecycle transition is allowed. It should not claim more than that property.

The counterexample is part of the method. It demonstrates the boundary of the check and keeps a passing path from becoming a vague quality signal.

Technique sketch: Let check: Input → {pass: bool, summary: str, checks: [{name: str, pass: bool}]}. The check function is deterministic, synchronous and has no side effects. The return includes both the overall verdict and the component checks, so a reviewer can see which specific claim failed. This is the Fieldcraft demo standard.

4. Return

Return the artifact with a short account of sources, checks, limits and the next question. Evidence, inference, hypothesis, proposal and release belong to different classes; they should stay distinguishable in the return.

That distinction lets work remain useful across time. A later reader can update the evidence without silently rewriting the earlier conclusion or pretending an unreviewed draft became accepted.

Counterexample: A report that says "the prototype was tested and passed, confirming the approach." This collapses test evidence (the prototype ran without errors on 3 inputs) into a conclusion (the approach is confirmed). A better return says: "the prototype passed 3 of 3 unit tests on synthetic data. It has not been tested on production traffic, concurrent access or boundary inputs. The next question is whether it handles empty and null inputs correctly."

The loop is not linear

The four steps form a loop, not a pipeline. A return may become a new bind for the next cycle. A failed check may send work back to making a better artifact. The methodology describes movement, not a script.

Safety property: Every step has a stop condition. If you cannot bind the work (no named source or owner), stop. If you cannot make a small enough artifact, decompose. If a check is impossible to state upfront, frame it as a discovery question. If a return is too vague to write, the work is not finished.

Notation guide

Throughout this site, formulations use typed predicates, assumption lists and prose bridges. Notation is always pedagogical. It never supersedes the prose explanation, and it is never presented as a formal standard or theorem.

Example notation rule: Let Bind = (S, O, T) where S is a source locator, O is a named owner, and T is a bounded task statement. Bind is valid only when S exists and is versioned, O is reachable for review, and T can be stated in under 100 words. If any component is missing, the bind is incomplete — it should be returned for revision, not accepted as-is and clarified later.

Research question framing

A useful research question starts before the search begins. A decision boundary, inclusion rule, exclusion rule and stopping rule define what the question actually needs — and what it can safely ignore.

Decision boundary: What will change based on the answer? If nothing changes, the question may not need answering right now. A boundary can be small: 'I need to choose between two Rust crates for structured concurrency.' That is research-size. 'What's the best concurrency model' is not.

Inclusion and exclusion rules: I will include sources published after 2023 with a dedicated evaluation section. I will exclude blog posts that describe a library without comparing alternatives. These rules are stated before reading, so the horizon is bounded by design.

Stopping rule: Stop when the decision boundary has a supported answer, even if the literature survey is not exhaustive. A stopping rule prevents research from expanding into a program of its own. Fieldcraft article FC-005 demonstrates bounded iteration budgets.

Source ledger practice

A source ledger records what was consulted, what kind of evidence it provides, what relevant spans were used and which limitations are known. It creates a durable link between a source and a claim.

Ledger structure (synthesized): Each row: Source ID, Title/Identifier, Version/Date, Relevant span, Support role (evidence | context | method | counterclaim), Limitations, Retrieved by. The ledger is versioned — if a source is replaced, the new row carries a 'supersedes' reference to the old one.

Counterexample to avoid: An unsourced paragraph in a synthesis that reads 'recent work in this area suggests…' without naming which work, who published it or when. A reader cannot verify, update or challenge the claim. The source ledger pattern would require: 'Source S04 (2026-03-15, Preprint, authors X and Y) reports measurement Z under condition C. This supports the claim that Q, but the sample size is N=12 — see ledger row S04 for full limitations.'

Claim and evidence mapping

A claim map shows the relationship between a conclusion and the evidence that supports, contradicts or is silent about it. The map does not assert that the evidence is exhaustive; it records the current state of the mapping.

Map structure (synthesized): For each claim C, record: sources that support C, sources that contradict C, sources that are silent (neither), sources that reframe C (offer a different interpretation), and sources that are missing (the evidence that would change C is not yet retrieved).

Technique: A claim map can be built during synthesis and returned alongside the final claim. It makes dissent visible rather than absorbing it into a smooth narrative. Fieldcraft article FC-015 demonstrates preserving minority conclusions.

Boundary: A claim map is not a verdict. It is evidence of what was considered and what was not. A reader can inspect the map, add missing sources or challenge the support classification without reconstructing the entire synthesis.

The binding contract in practice

A strong binding contract names the exact source version, the exact owner, and the exact task boundary. Here is a worked example:

Scenario: Scott asks: 'Audit the Fieldcraft corpus for broken links.'

Weak bind: 'Audit the Fieldcraft articles.' (No version, no link definition, no scope.)

Strong bind: 'Audit all 32 Fieldcraft articles published at commit f3dfdc6 of hearthandcode.github.io. A broken link is any <a href> whose target returns an HTTP error status or whose fragment target does not exist in the target document. Exclude external links behind authentication. Return a table of article slug, broken URL, error type, and recommended fix.'

Why this works: The exact commit prevents the audit from becoming outdated if the site changes mid-audit. The definition of 'broken link' is testable. The exclusion prevents false positives from protected resources. The return shape gives a reviewer stable material.

Making at the right scale

How small is small enough? A good rule of thumb: if the artifact cannot be described in one sentence, it is probably too large. Decompose it into smaller artifacts that each do exactly one thing.

Scale guide: Single check: one fixture file, one predicate. Method card: one page, one technique. Source ledger: one row per source, one type per row. Review packet: one candidate under review, one reviewer, one disposition. Dashboard: one surface, one purpose, one audience.

Worked example: Instead of building 'a complete knowledge management system' (impossible to describe in one sentence), build: (a) a source ledger format (one page), (b) a script that validates a ledger against its schema (one check), (c) a script that compares two ledgers (one check), (d) a script that generates a claim map from a ledger (one method). Each is independently useful, reviewable, and replaceable.

Check design patterns

A good check has five properties: (1) It tests exactly one predicate — 'this field exists,' not 'the data is correct.' (2) It is deterministic — same input always produces the same result. (3) It returns both pass/fail and evidence — why it passed or failed, not just a verdict. (4) It is synchronous and has no side effects — it does not change the system state. (5) It includes a counterexample that demonstrates the boundary.

Pattern: the three-fixture set. Every check should have three fixtures: a passing example (demonstrates the expected behavior), a failing example (demonstrates the boundary), and a boundary example (tests a value at or near the edge of the accepted range). The Fieldcraft library uses this pattern throughout.

Counterexample: A test that only passes on ideal inputs but fails silently on realistic input. This is worse than no test — it creates a false sense of coverage. The three-fixture pattern prevents this.

Return structure for maximum reuse

A return is most useful when it follows a predictable structure. The recommended return format for any significant work:

Return header: Goal statement (one line), Owner, Date, Source set (what was loaded).

Return body: Changed paths or artifacts (with evidence), Checks performed and results, Risks and open questions, Next action (one concrete step), Safe stop (how to undo or pause).

Return footer: Limits — what was not tested or not authorized. Next decider — who or what decides the next step.

Worked example from this session: 'Goal: expand depth pages. Changed: detail-pages.json (+23KB), build.py (+3KB). Checks: all 111 corpus fixtures pass, 31 Node invocations pass, 0 broken links. Next action: you review the expanded pages. Safe stop: git checkout main if the build breaks. Limits: not deployed, not committed. Next decider: Scott.'

Working with uncertainty at scale

When multiple decisions depend on uncertain evidence, the methodology must scale beyond a single claim map. The technique: maintain a decision registry that records each pending decision, its supporting evidence, its uncertainty level, its owner, and the trigger for a decision.

Decision registry (synthesized): Each entry: Decision ID, Description, Supporting evidence, Uncertainty (High/Medium/Low), Dependencies (other decisions that must be resolved first), Owner, Decision trigger (what would resolve the uncertainty).

Worked example from architecture: 'Decision D3: Choose the persistence layer. Evidence: three options evaluated against latency, consistency, and operational complexity. Support: Option A leads on latency but requires eventual consistency. D3 depends on D2 (consistency model choice). Decision trigger: D2 is resolved → D3 can proceed. Owner: engineering team.'

Cross-methodology integration

The Bind-Make-Check-Return methodology integrates with other methodological approaches. When a question arrives, the integration point is the binding step: bind to the relevant methodology, not to a generic process.

Integration with evidence hierarchies: Bind identifies the required evidence level. Make produces a claim map at that level. Check validates the claim map against the evidence. Return includes the evidence level and the confidence it supports.

Integration with peer review: Bind declares the review criteria. Make produces the candidate under review. Check runs the review criteria against the candidate. Return documents the review finding and next steps. This integration is used in the Employment Operations workflow.

Boundary: Integration does not mean merging methodologies into one. Each retains its own criteria and failure modes. The integration point is a handoff, not a fusion.