The first three correspondences (POSIX, football, Harvard) validated the ontology against external systems. This correspondence applies the ontology reflexively — mapping HAAK's own constructs to the definitions in [[01-objects]] as revised by the relational reading in [[04-correspondence_v1-2]]. Every HAAK structural feature receives an ontological assignment. Open questions are marked with ⚡.
This document has a normative consequence the other three do not: where the mapping reveals that HAAK's current structure diverges from the ontology HAAK itself defines, the divergence is a flaw in the structure, not in the ontology. The ontology is the standard; the system must be brought into conformance.
| Section | What it covers |
|---|---|
| Axis correspondences | Actors, methods, domains, materials |
| Compound correspondences | Patterns, situations, policies, engagements, constitution |
| The type system question | Reconciling the constitution's types with the ontology's |
| Constitutional scope | What should have constitutional status |
| Open questions | What doesn't map cleanly |
#Axis Correspondences
#IV.1 Actors
Three substrate kinds bear actor-types in HAAK:
| Substrate | Actor-types | Actor-tokens | Actor-power |
|---|---|---|---|
| The PI (Zach) | super-architect, requester | singular | Maximal — analogous to root (I.1), the Corporation (III.1) |
| Claude sessions | architect, editor, reviewer, copy-editor, writer, auditor, librarian | Each session is a token, identified by [model:session8:context] | Varies by profile — architect has broader scope than reviewer |
| Scripts/hooks | service-monitor, session-starter | Each execution is a token | Minimal — hooks observe and report, they do not decide |
Agent profiles (.claude/agents/*.md) define actor-types: capability profiles specifying what operations an actor can perform, what tools it has access to, and what skills it invokes. This maps cleanly to Definition 2 — actor-types specify "what operations it can perform."
Specialization. Agent profiles form a refinement tree rooted in the generic Claude session. The architect specializes toward system-modifying operations; the reviewer specializes toward assessment. Under the ontology's two orderings (specialization and organizational hierarchy), the current HAAK agents have specialization (architect ≠ reviewer ≠ editor) but minimal hierarchy — the PI holds authority over all agents equally. There is no intermediate hierarchy among agents.
Personas (personas/.md) are the ontology's "expressive grounding — voice, epistemic position, characteristic style of action" (Definition 2). A reviewer agent bears a persona that shapes how it reviews. The persona is not an actor-type — it does not define capabilities. It defines orientation. Clean.*
> ⚡ Open IV.1.A (origin tag conflation). The origin tag [claude:sonnet-4-6:a16dc698:haak-infra] conflates four ontological objects: agent substrate (claude), actor-type capability (sonnet-4-6 — really a model, which constrains capability), actor-token identity (a16dc698), and engagement context (haak-infra). Under the ontology, these should be distinguishable: agent, actor-type, actor-token, engagement. The tag is pragmatically adequate but ontologically imprecise.
#IV.2 Methods
Methods in HAAK map to Definition 3 with a three-level refinement hierarchy:
5-step workflow (meta-pattern: Define → Collect → Reason → Act → Validate)
├── review (method-type, specializes 5-step)
│ ├── manuscript (pattern within review, specifies deltas)
│ ├── proposal (pattern within review)
│ ├── idea (pattern within review)
│ └── architecture (pattern within review — not yet formalized)
├── write (method-type)
│ ├── opinion (pattern within write)
│ ├── manuscript (pattern within write)
│ └── revision (pattern within write)
├── search (method-type)
├── ingest (method-type)
├── architect (method-type)
└── ... (audit, persona, preregister, sweep, disclose, interview, gdrive-import)At the finest grain, methods become skills — executable primitives invoked as /commands. This maps exactly to Definition 3: "At the finest grain, a method becomes an executable skill — the minimum unit of execution, not further decomposable into sub-methods. The method→skill relation is refinement within the same axis."
Composition is confirmed: review composes search (at Collect), persona-selection (at Collect), write (at Act). The 5-step provides the compositional interface — "the interface between composed methods is always a step boundary" (11-five-step.md).
Maturity is a tag on method-types: observed → stable → enforced. This has no direct ontological analog — it is a property of the normative status of a descriptive compound. An observed method is a pattern (descriptive type); when promoted to enforced, it becomes a policy (normative type). Maturity is the promotion path from pattern to policy. Clean under the stance interpretation.
Method inheritance. Each method inherits the 5-step's structure and specifies only its deltas. Each pattern within a method inherits the method's structure and specifies only its deltas. This is exactly the refinement relation of Definition 3: "methods refine from abstract to concrete." The inheritance is documented in 11-five-step.md (the instantiation tables). Clean.
#IV.3 Domains
The directory hierarchy is the domain forest. This is the same correspondence as POSIX (I.3), and it is the most structurally exact mapping in the system.
| HAAK directory | Domain kind | Domain-scope |
|---|---|---|
/ (project root) | organizational | Maximal within HAAK |
patterns/ | process | Cross-cutting — methods, policies, architecture |
ontology/ | topical | The conceptual ground |
projects/ | organizational | Container for all project domains |
projects/ai-ontology/ | topical | One research program |
projects/ai-ontology/inscription-agents/ | topical | One manuscript project |
data/ | activity | System-wide data stores |
strategy/ | activity | Portfolio-level planning |
Subsumption holds at every parent/child edge. Policies scoped to projects/ constrain all projects. Policies scoped to a specific manuscript constrain only that engagement. Clean.
Index files (index.md in every directory) are materials that carry method-property — they encode a navigational method (progressive disclosure). They also define the domain's scope: the index says what the domain contains. Under the relational revision, this bundling (material-property + method-property) is accepted. Clean.
Board files (board.md in active directories) are materials within domain-instances. They carry communication state for that domain. Under the relational revision, a board has high material-malleability (agents read and append to it) and some domain-property (it constitutes a communication context). The board is not itself a domain — it is a material-token within one. Clean under relational reading.
#IV.4 Materials
| Material-kind | Examples | Material-malleability |
|---|---|---|
| Documents | Markdown files, PDFs, session transcripts | High for PI and author agents; read-only for reviewers |
| Databases | data/papers.db, data/contacts.db, data/music.db | High for skills that write to them; query-only for agents |
| Board entries | Timestamped lines in board.md | Zero after creation (immutable by design) |
| Images/media | Photos, figures, audio recordings | Processable (vision, transcription) but typically not mutated |
| Session transcripts | sources/YYYY-MM-DD-session.md | Zero after export (archival) |
Material identity persists across transformation: a manuscript before and after revision is the same material-token in a different state (Definition 5). Version control (git) makes this explicit — the file's identity persists across commits.
Affordances are actor-relative: a manuscript affords assessment for a reviewer, revision for an author, and editorial judgment for an editor. The same material, different affordances depending on the actor's capabilities. Clean under relational reading.
#Compound Correspondences
#IV.5 Patterns (descriptive type-compounds)
Patterns in HAAK are documented in patterns/:
patterns/architecture/— structural patterns (how the system is built)patterns/features/— development records of capabilitiespatterns/methods/— procedural patterns (how work is done)
The 5-step workflow is the most important pattern: a descriptive type-compound capturing the observed regularity in how HAAK methods unfold. It generalizes from many specific method executions into a repeatable structure (Definition 10). It was abstracted from observed practice, not imposed — making it descriptive, not normative. Clean.
The progressive disclosure pattern (index → summary → full content) is another: an observed regularity in how information is organized throughout the system.
The board convention (per-folder board.md, origin tags, append-only entries, archive at threshold) is a pattern in active use.
#IV.6 Situations (descriptive token-compounds)
A session is the primary situation in HAAK: a particular, ongoing coming-together of actor (Claude session or PI), methods (skills invoked), and domain (project context). Sessions begin, accumulate state (board posts, file edits, decisions), and end. While active, a session is a situation (Definition 11). When complete, it becomes a historical record (session transcript in sources/).
A board thread is a micro-situation: a sequence of entries between agents on a topic, observable on the board, with a beginning (first entry) and an end (indexing/archiving).
A review round is a situation: this panel, reviewing this manuscript, producing these outputs, in this round.
#IV.7 Policies (normative type-compounds)
Policies are documented in patterns/policies/:
| Policy | Scope (actors × methods × domains) | Deontic strength |
|---|---|---|
| 01-constitution | All × all × all | Must (maximal) |
| 02-file-structure | All agents × file operations × all directories | Must |
| 03-external-content | All agents × ingest methods × external sources | Should |
| 04-source-tracking | All agents × review/write × source-bearing domains | Must |
| 05-anti-groupthink | Reviewer agents × review methods × review domains | Must |
| 06-model-selection | All agents × model-invoking methods × all | Should |
Policy accumulation through domain subsumption is confirmed: 01-constitution applies everywhere; domain-specific policies apply within their scope and accumulate downward.
The six constitutional requirements are policies embedded within the constitution. Their scope is maximal (all actors, all methods, all domains). They are: externalization, human authority, reflexive improvement, AI attribution, auditability, privacy.
#IV.8 Engagements (normative token-compounds)
An engagement in HAAK (invoked via /engage) is a normative token-compound: it specifies what should be happening (goals), under what obligations (policies in force), by whom (actor-token), in what domain (project context). This maps exactly to Definition 13.
A review engagement bundles: these reviewers (actor-tokens), reviewing this manuscript (material), using the manuscript review pattern (method), in this project domain, under review policies (anti-groupthink, source-tracking), toward the goal of producing an assessment.
Engagement state is tracked in files: _next.md (resume point), board posts (current status), project indices (accumulated outputs).
#IV.9 Constitution
patterns/policies/01-constitution.md is a policy of maximal scope whose subject is the creation and amendment of other policies (Definition 14). It prescribes:
- What the system is for (purpose)
- Six requirements that constrain all action
- A type system that classifies system constructs
- Format requirements for methods and policies
- An amendment clause (PI approval required)
Clean as a structural correspondence. But see The type system question for where the constitution's internal taxonomy diverges from the ontology's.
#The Type System Question
The constitution defines a type system: Constitution → Policies → Methods → Skills → Foundations → Features. The ontology defines a different classificatory framework: axes (actor, method, domain) + materials + four compounds (pattern, situation, policy, engagement). These are not the same classification, and bringing them into alignment is the central task.
#Reconciliation
| Constitution type | Ontological assignment | Notes |
|---|---|---|
| Constitution | Policy of maximal scope (Def. 14) | Exact match |
| Policies | Normative type-compounds (Def. 12) | Exact match |
| Methods | Method-types with internal structure (Def. 3) | Exact match — methods in patterns/methods/ are method-types with refinement and composition |
| Skills | Method-types at finest refinement grain (Def. 3) | Exact match — "at the finest grain, a method becomes an executable skill" |
| Foundations | Materials carrying policy-grounds | Foundations are not patterns (not descriptive of what tends to happen). They are the grounds of policies — the reasons for the normative order (Def. 12: "a policy carries a ground"). Ontologically, foundations are materials with high method-property: they encode the reasoning that justifies policies. |
| Features | Materials representing engagements | Features are development records — materials that stand in for completed or ongoing engagements. Under the representation relation (Open IV.R), they are materials that represent how capabilities were developed. |
#What the reconciliation reveals
- Methods and skills are on the same axis. The constitution treats them as separate types; the ontology treats them as the same type at different refinement levels. The constitution should acknowledge this: skills are methods, not a separate kind.
- Foundations are not a separate ontological kind. They are materials that ground policies. The constitution's separate listing is pragmatically useful (they deserve their own directory) but ontologically they are materials, not a sixth kind of object.
- Features are not a separate ontological kind. They are materials representing engagements. Again, pragmatically useful as a category but ontologically they are materials with a particular representational function.
- Patterns are missing from the constitution's type system. The ontology has patterns (descriptive type-compounds); the constitution's type system does not list them. Yet
patterns/architecture/is full of them. The constitution should add Pattern as a type: "observed regularities — what tends to happen."
- Situations and engagements are missing. The constitution's type system is entirely about types (general categories). It has no vocabulary for tokens (particular instances). Sessions, review rounds, board threads — these are situations and engagements, and the constitution doesn't name them. This is appropriate: a constitution governs types (rules for rule-making), not particular instances. But the absence should be noted rather than accidental.
#Constitutional Scope
What should have constitutional status — maximal scope, governing governance?
#Currently constitutional (in 01-constitution.md)
- Purpose statement
- Six requirements (externalization, human authority, reflexive improvement, AI attribution, auditability, privacy)
- Type system definition
- Format requirements for methods and policies
- Amendment clause
#Should be added to the constitution
- Ontological grounding. The constitution should reference the ontology as the conceptual ground of its type system. The ontology defines actor, method, domain, material, and the four compounds. The constitution uses these concepts (methods, policies, skills) without grounding them in the ontology that defines them. Add: "The type system is grounded in the ontology at
ontology-objects. Terms used here (method, policy, domain, scope) are defined there."
- The domain forest. The directory hierarchy is the domain hierarchy. This is structural, not incidental — policies accumulate through directory subsumption. This should be constitutional: "HAAK's domain structure is the directory hierarchy. Child directories subsume under parents. Policies scoped to a parent apply to all children."
- Human authority as maximal actor-power. The current wording ("The PI has final authority") should be grounded: "The PI holds maximal actor-power within all HAAK domains. No agent action can constrain the PI's authority."
- Method inheritance from the 5-step pattern. All methods follow the 5-step shape. This compositional constraint should be constitutional: "Methods follow the Define → Collect → Reason → Act → Validate shape. Each method specifies its deltas from the general pattern."
#Should remain policy (not constitutional)
File structure conventions, external content handling, source tracking, anti-groupthink, model selection, board protocol. These are normative type-compounds of narrower scope than the constitution. They constrain specific actor/method/domain combinations, not all of them.
#Should be explicitly identified as patterns (not policies)
The 5-step workflow, progressive disclosure, the board convention, directory indexing, the skill anatomy (SKILL.md format). These are descriptive type-compounds — observed regularities that methods tend to follow. When a pattern is promoted to enforced maturity, it becomes a policy. Before that, it remains a pattern.
#Open Questions
> ⚡ Open IV.A (foundations as policy-grounds). If foundations are materials carrying policy-grounds, their special status in the constitution's type system is pragmatic, not ontological. Should the type system be revised to align with the ontology (dropping Foundations as a separate kind and treating them as materials), or should the pragmatic classification be preserved and annotated? The relational reading permits both — what matters is that the relationship (foundation grounds policy) is explicit.
> ⚡ Open IV.B (the 5-step as pattern or constitution). The 5-step workflow is currently a pattern (descriptive type). If it becomes constitutional ("all methods must follow this shape"), it transitions to a policy — a normative type-compound of maximal scope within the method axis. This changes its ontological status. The tension: is the 5-step an observed regularity that methods happen to follow (pattern), or a requirement that they must follow (policy)? Its current status (patterns/methods/11-five-step.md) implies pattern. Making it constitutional implies policy. The user's directive suggests the latter.
> ⚡ Open IV.C (method maturity as stance transition). Under Move 2, the normative/descriptive distinction is a stance. Method maturity (observed → stable → enforced) is a transition in dominant stance: an observed method is approached with descriptive stance (this is what we do); an enforced method is approached with normative stance (this is what we must do). The object is the same; the stance shifts. This is the cleanest account of method promotion but it means the same document can be simultaneously a pattern (descriptive stance) and a policy (normative stance) depending on who approaches it. Under the relational revision, this is accepted.
> ⚡ Open IV.D (HAAK as institution). HAAK bundles high actor-power (it processes materials, transforms actors, creates norms) with high domain-scope (it defines the territory within which all its action occurs). Under the resolution of Gap IV.1 (v1.2), this makes HAAK an institution — an entity with jointly high actor-power and domain-scope. The PI is the institution's governance agent, analogous to Harvard's Corporation or FIFA. Whether HAAK's institutional status should be explicit in the constitution is open.
> ⚡ Open IV.E (representation and progressive disclosure). Index files, board summaries, session exports, and features all represent other objects: indices represent domains, board summaries represent archived situations, features represent engagements. This representation relation (Open IV.R from v1.2) is pervasive in HAAK. Progressive disclosure — the defining architectural pattern — is fundamentally about layered representation: each layer represents the layer below at lower resolution. A full account requires the representation relation to be formalized in 02-relations.md.
ontology · correspondence IV · HAAK self-mapping · 2026-02-28 · zach + claude
Ontology 07 — Correspondence IV: HAAK — 2026 — Zachary F. Mainen / HAAK