Method Composability

| Section | What it covers | |:--------|:---------------| | Principle | Why methods must be composable | | Graph structure | Composition graph, domain graph, engagements, governance line | | Design…

SectionWhat it covers
PrincipleWhy methods must be composable
Graph structureComposition graph, domain graph, engagements, governance line
Design constraintWhat composability requires of each method
Composition examplesHow primitives combine in practice
Relation to encapsulationWhy mixing concerns kills composability

#Principle

HAAK has eleven composable methods (review, audit, write, search, ingest, persona, preregister, sweep, architect, disclose, five-step) forming a directed graph — any method can invoke another as a sub-step. Complex workflows don't create new monolithic methods — they compose existing ones. A manuscript review composes search (literature context) + review (assessment) + write (editorial synthesis). An index audit composes sweep (consistency propagation) + audit (structural checks). A persona build composes search (bibliography) + ingest (source material) + write (persona document).

The alternative — monolithic methods that embed their own search, their own validation, their own writing — duplicates logic and creates divergent behavior. Two methods that each implement their own search will search differently. Composability means search is defined once and composed everywhere, so it behaves consistently.

This is the method-layer expression of encapsulation: information serving different functions lives in different containers. A method that reviews and searches has mixed concerns — changing the search behavior requires modifying the review method.

#Graph structure

Methods participate in two distinct graphs over the same node set.

#Composition graph

A directed labeled graph, potentially cyclic. Nodes are methods. Each edge is labeled with (step, reason) — e.g., review →(Collect, "literature context") search. Cycles exist: review → search → persona → review. This is not a DAG; it's a general directed graph.

The graph is navigable through bidirectional links in each method doc: ## Composition (outgoing edges — what this method invokes) and Composed by: (incoming edges — what invokes this method). The five-step method sits at the root — every sequential method composes it. The disclose and sweep methods are structural — they compose each other but not via the five-step.

Properties: the graph enables consistency checking (if A composes B, A's behavior must be consistent with B's contract), change propagation (modifying B requires checking all methods that compose it), and cost estimation (a workflow's cost is the sum of its composed methods' costs).

#Domain graph

A domain is a governance scope — a semantic space where specific constraints, resources, and quality criteria apply. Domains are declared in domains: frontmatter on both methods and policies.

An engagement is the governed unit of work — one method or a composition of methods applied to content. Skills and raw tool calls are mechanical; methods involve judgment. The governance line runs between skills (below) and methods (above). Domains apply at and above the governance line.

Domain set resolution. Every engagement carries a domain set — the union of:

  1. Static domainsdomains: frontmatter from all composed methods
  2. Dynamic domains — detected from content properties during Define (e.g., patient data → privacy, external manuscript → external)

When methods compose, their domains union. A manuscript review composing search + review + persona + write inherits all four methods' domains. Content detection can add more. The full domain set determines governance for the entire engagement.

What domains provide. Not just constraints — a domain scopes three things:

ProvidesExample
Constraints (policies)review → anti-groupthink requirements
Resources (tools, context)review → persona pool, convergence metrics
Quality criteriareview → independence score, coverage matrix

Entering a domain activates its full scope, not just its prohibitions.

Graph structure. A bipartite hypergraph. One partition is methods; the other is policies. Each domain tag is a hyperedge connecting every method and policy that carries it in domains: frontmatter. The policy mapping is the adjacency matrix. Edges are asymmetric: policies constrain domains, methods declare domains. A policy doesn't know which methods it constrains — the domain tag is the only coupling.

Domains are currently flat and independent — no hierarchy, no inter-domain relationships. They intersect freely through co-declaration. Future extensions (subsumption, implication) are possible but not yet needed.

The two graphs serve different purposes: composition edges say "invokes at step X" (operational), domain edges say "constrained by" (governance). Both maintained through frontmatter and in-text links.

#Design constraint

For methods to compose, each must be:

  • Stateless: no persistent state between invocations. All context comes from inputs (files, frontmatter, skill prompts), all outputs go to files. A method doesn't remember being called.
  • Clean I/O: inputs and outputs are files or frontmatter fields, not internal data structures. A composed method reads the output files of the method it invoked, not its internal state.
  • Single concern: each method does one thing. Review assesses. Search discovers. Write produces. Sweep propagates. When a method needs to do two things, it composes two methods.
  • Self-describing: each method declares its domains: in frontmatter, so policy constraints propagate automatically through composition. A workflow that composes review + search inherits both review and search policies.

#Composition examples

WorkflowComposesHow
Manuscript reviewsearch → review → writeSearch finds relevant literature; review assesses manuscript with that context; write produces editorial synthesis
Index maintenancesweep → auditSweep propagates consistency; audit checks structural invariants
Persona constructionsearch → ingest → writeSearch finds bibliography; ingest processes papers; write produces persona document
Literature reviewsearch → writeSearch discovers literature; write produces the review document
Preprint opinionsearch → review → writeSearch provides context; review generates assessment; write formats as HOP opinion
Architectural changesweep → architect → sweepSweep maps implications; architect analyzes and acts; sweep propagates

#Relation to encapsulation

Encapsulation says: information serving different functions must live in different containers. Method composability is the process-layer consequence. A method is a container for one function. Mixing functions in one method violates encapsulation the same way mixing index and data in one file does — it couples concerns that change independently.

The test: if changing how HAAK searches would require modifying the review method, composability is broken. Each method should be modifiable independently, with composition as the only coupling.

#Generalize before implementing

Before building anything new, ask: what abstraction level does this belong at? The HAAK stack has five levels — foundations (beliefs), architecture (structural decisions), policies (constraints), methods (procedures), skills (atomic capabilities). A new piece of knowledge belongs at exactly one level. Building at the wrong level creates either an over-specific architecture doc (should be a method) or an under-grounded method (should reference an architecture doc).

The same applies within the method layer. Before creating a new method, ask: is this a new primitive, or a composition of existing primitives? If review + search + write already cover a workflow, documenting that composition is cheaper and more correct than creating a new monolithic method that embeds its own review, search, and writing logic. Composition hints in methods/index.md track recurring compositions that haven't yet been promoted to methods.

This is the design-time complement of encapsulation's no unnecessary structure: encapsulation says don't create containers without a function to separate; generalization says don't create implementations without checking what already exists at the right abstraction level.

Architecture 15 — Method Composability — 2026 — Zachary F. Mainen / HAAK