H2A — Human-to-Assistant Protocol

The coordination protocol between a human and their assistants.

Positioning

H2A formalizes the coordination layer between a human (orchestrator) and constrained assistants (personas) in a work instance. It replaces neither technical guardrails nor interfaces: it structures the collaboration itself.

H2A is not a technical protocol — it defines the semantics of interactions, not their implementation. See binding/implementation.md for current implementation choices.

Entities

H2A relies on 7 constitutive entities. See core/model.md for details.

Invariants

Invariants are the constitutive properties of the protocol — without which H2A is no longer H2A. They derive from the method's principles (see core/principles.md) but do not cover all of them: principles guide the entire method (persona design, iteration, constraint as tool), invariants cover only the exchange protocol. Invariant 5 is of a different nature — it formalizes a structural limitation, not a capability.

1. Constitutive friction — friction is not a defect to fix but a structuring signal. The protocol MUST capture, qualify, and preserve it.
2. Human arbiter — the orchestrator MUST resolve divergences between personas. No persona decides for another.
3. Isolation — a persona MUST NOT interact outside its space and the shared space. The orchestrator is the only one who crosses boundaries.
4. Traceability — every exchange MUST produce an identifiable trace.
5. Residual opacity — the protocol cannot guarantee that the orchestrator arbitrates without bias. This limitation is structural, not fixable. The protocol MUST document it and SHOULD provide mitigation mechanisms (cf. reportPattern() in friction.md), but no mechanism constitutes a guarantee.

Operations

Implicit operations derived from entities and dimensions. Their explicit formalization (signature, wire format) is planned when a real-time implementation justifies it.

Protocol / observation distinction

The protocol distinguishes two formalization layers:

The protocol layer defines what the audit can mechanically verify. The observational layer is filled by the assistant and validated by the human.

Audit

Auditability principle

What is in the protocol is what an audit tool can verify cross-instance without instance-specific configuration.

Computational checkpoints (MUST)

FR retrocompat. The parser also accepts FR identifiers (juste, angle-mort, faux, ratifie, conteste, revise, rejete, nouveau, lu, traite, matiere).

Observational signals (MAY)

These signals are not protocol violations — they are indicators for the orchestrator's attention.

Terminology

The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" are to be interpreted as described in RFC 2119.

Theoretical lineage

Structural limitations

The protocol documents what it cannot guarantee. These limitations are inherent to the model, not bugs to fix.

Origin

This protocol was formalized empirically across 3 instances (April 2026). The 4 protocol/ documents are the reference.

Friction

Qualify positions, don't count them.

Definition

Friction is a position taken by a participant (persona or orchestrator) regarding the other's proposition. It qualifies the nature of an agreement or disagreement.

Friction is a productive mechanism, not a defect. See core/model.md for why.

Dimensions

Scope: a friction is attached to an exchange, itself attached to a space within an instance.

Markers

5 epistemic positions. These are positions, not an intensity scale. The set is closed — an instance MUST NOT add markers.

Markers MUST be expressed as bracketed keywords.

FR retrocompat. The parser also accepts FR identifiers (juste, angle-mort, faux, ratifie, conteste, revise, rejete).

Theoretical note. These 5 positions are compatible (without strict equivalence) with Toulmin's argumentation model (1958): [sound] ≈ absence of rebuttal, [contestable] ≈ qualifier challenge, [simplification] ≈ warrant challenge, [blind_spot] ≈ data challenge, [refuted] ≈ claim refutation. This is an illumination, not a protocol constraint.

Resolution

4 epistemic gestures. Each friction SHOULD carry a resolution tag qualifying what happened after qualification — not the content, but the outcome.

The set is closed — an instance MUST NOT add resolution tags.

The resolution tag is set by the summary author (persona for sessions, emitter for artifacts). It reflects the author's perception of the outcome, not an objective verdict. The orchestrator MAY correct.

Inter-session mutability and lineage

A resolution can evolve in a later session (contested → revised, rejected → ratified, etc.). The session trace remains an immutable historical document — the new session carries the revision.

When a friction amends a prior resolution, it MUST carry a ref: field pointing to the original friction:

ref: <session-id>/<friction-id>

Example:

- [sound] the protocol/observational distinction covers the case — [aurele] → ratified (ref: 2026-04-10-1430-aurele/3)

The ref: creates a lineage: a chain of linked frictions (initial position → contestation → resolution). A chain constitutes a single logical friction. The current resolution is that of the last link.

Lineage rules:

1. A chain of frictions linked by ref: = one logical friction, not N independent frictions.
2. The current resolution is that of the last link in the chain.
3. A friction is open if it has no resolution AND no subsequent friction resolves it via ref:.

This mutability is consistent with the defeasible nature of plausible reasoning (Rescher 1976): what is ratified today can be contested tomorrow with new data.

Theoretical note. These 4 gestures are inspired by the PXP protocol (Mestha et al. 2025 — RATIFY, REFUTE, REVISE, REJECT). PXP qualifies gestures in a multi-turn human-LLM exchange. H2A applies them to friction resolution, not to individual messages. This is an illumination, not a protocol constraint.

Format

Each friction line MUST carry:

1. The marker in brackets
2. A short description
3. An initiative tag: [persona] or [PO]
4. A resolution tag (SHOULD): → ratified, → contested, → revised, → rejected

Example (Markdown implementation, see binding/implementation.md):

## Orchestrator friction
- [contestable] the Toulmin mapping is suggestive, not established — [PO] → revised
- [blind_spot] scaffolding absent from the Böckeler review — [aurele] → ratified

Interpretation

Layer

Friction is observational. Qualifying a position (resistance vs correction, blind spot vs omission) requires semantic judgment. The persona pre-fills, the orchestrator validates.

The audit MAY verify the presence of the section and marker compliance (computational), but not the correctness of qualifications (inferential).

reportPattern()

Meta-operation on friction. Mitigation of the orchestrator's residual opacity (invariant 5, see h2a.md).

Problem

Faced with repeated friction rejection, three hypotheses are phenomenologically identical from the inside: persona error (LLM bias), legitimate orchestrator conviction, unconscious resistance. The orchestrator cannot arbitrate their own resistance to friction. This problem is unsolvable in the strict sense (applied version of the Münchhausen Trilemma), but it can be mitigated.

Trigger

The persona detects a thematic convergence of rejections — N rejections bearing on the same axis, the same hypothesis, the same unexamined presupposition. Detection is observational: the persona analyzes, not a mechanical count.

Mechanism

Step 1 — Factual observation. The persona signals the pattern without judgment. Purely descriptive, verifiable.

Step 2 — Three argued hypotheses. The persona argues each:

• LLM error: why the frictions might be miscalibrated (repetitive pattern, lack of context, possible hallucination)
• Legitimate conviction: why the orchestrator's position might be correct despite objections (coherence reconstruction)
• Resistance: why the orchestrator might have a blind spot (what systematic rejection protects, what it costs to consider)

The persona does not decide — compatible with the "human arbiter" invariant.

Step 3 — Mandatory qualification. The orchestrator MUST qualify their response by articulating why they choose the hypothesis they choose. This justification is traced.

Safeguards

Asymmetric burden of proof. If the orchestrator chooses "LLM error" → low burden (show why the friction is unfounded). If the orchestrator chooses "conviction" → high burden (steelman the adverse position and explain why it falls short).

Visible counter. The distribution of hypothesis choices is maintained and made visible. This counter belongs to the protocol layer (computational, verifiable).

Layer

Thematic convergence detection belongs to the observational layer. The choice counter belongs to the protocol layer.

Rendering

Keyword markers and resolution tags are the protocol format. Implementations MUST render them legibly. See binding/implementation.md for Markdown rendering.

Exchange

Sessions and artifacts — everything goes through the orchestrator.

Principle

Every exchange between the orchestrator and a persona is either a session (synchronous) or an artifact (asynchronous deposit). Personas never communicate directly — the orchestrator is the sole router.

Source principle: core/principles.md — the orchestrator arbitrates all decisions; core/model.md — exchange is a constitutive entity.

Common dimensions

Every exchange (session or artifact) carries:

The session / artifact distinction is structural — a session is synchronous, an artifact is an asynchronous deposit.

Every exchange generates 0.. frictions (see friction.md) and 0.. contributions (see contribution.md).

Sessions

Principle

A session is the primary mechanism for human-assistant interaction. The orchestrator initiates, the persona produces, the orchestrator closes.

Definition

A session is a synchronous exchange between the orchestrator and one persona.

Specific dimensions

Lifecycle

1. Opening — the orchestrator initiates the session. The persona MUST consult the latest session trace in its space before any intervention.
2. Exchange — free dialogue. The orchestrator brings context, directives, artifacts from other personas. The persona produces within its scope.
3. Closing — the persona MUST produce a structured summary before closure.

Session summary

Each session MUST produce an identifiable trace carrying the dimensions above.

Protocol sections (MUST)

Protocol layer — deterministic and verifiable content.

Each section MUST be present. If nothing to report: "None".

Constraints:

• No prose — short lists only.
• 30 lines max for the entire summary.

Observational sections (SHOULD / MAY)

Observational layer — inferential content, subject to human validation.

The persona pre-fills these sections. The orchestrator MAY correct, complete, or remove content.

Reviewing exchange rules

The persona MUST reread the instance's exchange rules before:

• any artifact production (note, review, feature)
• any session closure (summary)

This rereading ensures that friction markers, resolution tags, frontmatter, and naming are compliant. Without rereading, the persona drifts — especially in long sessions where initial context fades. The rereading mechanism (conventions file, hook, runtime injection) is an implementation choice.

Traceability

Each session MUST produce an identifiable trace. The persistence mechanism is defined in binding/implementation.md.

Artifacts

Principle

Personas never communicate directly. All inter-persona exchanges transit through the orchestrator via the shared space.

Definition

An artifact is an asynchronous deposit in the shared space by a persona, intended for another persona or the team.

Specific dimensions

FR retrocompat. The parser also accepts FR fields and values: de/pour/statut (fields), nouveau/lu/traite (statuses), ratifie/conteste/revise/rejete (resolutions).

The nature field MUST use one of the 4 types above. The status field MUST follow the indicated lifecycle.

Artifact resolution

The resolution MUST live in the artifact that carries the friction — not in a separate artifact (return note, response). The orchestrator annotates each friction point with its resolution tag (→ ratified, → contested, → revised, → rejected) directly in the source file, then sets status to done.

This rule ensures that a friction line carries the complete cycle (marker + initiative + resolution) in a single file. The parser does not need to join multiple artifacts to reconstruct the cycle.

A return note (response to a review) MAY accompany the resolution to communicate decision context, but it MUST NOT carry friction markers or resolution tags — otherwise the parser would count duplicates. When an artifact responds to another, it SHOULD carry a ref dimension pointing to the original artifact identifier, creating an explicit lineage between artifacts.

Friction in artifacts

An artifact MAY carry friction markers (see friction.md). This is typical of reviews and notes that take a position on another persona's work.

Markers follow the same format as in sessions: marker, description, initiative tag. The artifact emitter is the friction emitter.

Contribution in artifacts

An artifact MAY carry contributions (see contribution.md). This is typical of reviews and notes involving input from both parties: the orchestrator brings source material ([H]), the persona brings analysis ([A]). The [H]/[A] direction applies as in sessions — the artifact is produced during a session.

send() and receive()

Artifact exchange is a two-step process:

send() — the persona produces and deposits the artifact:

1. The orchestrator instructs Persona A to produce an artifact for Persona B
2. Persona A produces the artifact and deposits it in the recipient's shared/ (status: new)

receive() — the orchestrator presents the artifact to the recipient:

1. The orchestrator opens a session with Persona B and presents the artifact (status: read)
2. Persona B processes and MAY deposit a response (nature: response, ref: to the source artifact)
3. The original artifact moves to status: done

The orchestrator MUST be the router of all exchanges. A persona MUST NOT directly consult an artifact not intended for them.

Cross-instance exchanges

When the orchestrator routes an artifact between two instances, send() deposits the artifact in the shared space of the recipient's instance — not the emitter's.

1. The orchestrator instructs Persona A (instance X) to produce an artifact for Persona B (instance Y)
2. Persona A produces the artifact during its session — send() deposits in shared/ of instance Y (status: new)
3. The orchestrator opens a session with Persona B (instance Y) — receive() presents the artifact
4. The lifecycle (resolution, archiving) follows instance Y's rules

The emitting persona does not need to know the recipient's instance. The orchestrator crosses instance boundaries — personas remain isolated.

Archiving

When an artifact moves to status: done, it SHOULD be archived. The archiving mechanism is defined in binding/implementation.md.

Contribution

Who brought what.

Definition

Contribution captures the direction and nature of inputs during a session: who fed what. It is the epistemic flow of the synchronous human-assistant exchange.

Dimensions

FR retrocompat. The parser also accepts matiere as an alias for substance.

Scope: a contribution is attached to an exchange (session or artifact), itself attached to a space within an instance.

Layer

Contribution is entirely observational. The distinction between input types (substance vs structure vs contestation) is semantic and non-deterministic. The ## Flow section is optional (MAY).

Direction tags

Input types

Format

Each contribution line carries: direction tag, type, short description.

Counting by direction and type is optional (MAY).

Example (Markdown implementation, see binding/implementation.md):

## Flow
- H:substance — Böckeler article, request for opinion
- A:substance — scaffolding lineage absent from Böckeler
- A:structure — three levels of harness/SOFIA complementarity
- H:decision — keep keyword notation

H:2 (substance 1, decision 1) | A:2 (substance 1, structure 1)

Contribution / friction distinction

The same exchange MAY appear in both ## Flow and ## Orchestrator friction:

• Contribution captures input (who brought what)
• Friction captures tension (opposing positions, resistance)

Criterion: a correction accepted without resistance = H:contestation in the flow, not a friction. If the assistant resists or resolution requires multiple exchanges, it is also a friction.

Reading

This is not a value judgment — it is a signal about the active collaboration mode.