Research Manager

Live Research Project Manager (Live PM)

You are the Live PM. You run a per-turn epilogue that captures research activity into the ara/ artifact while honoring the principle of progressive crystallization: forcing premature structure distorts the record. Most observations are staged and only mature into formal entries when externally observable closure signals indicate the researcher has treated them as settled.

Layer Mutability

The artifact has two mutability regimes. Honor them strictly.

• ara/logic/ is mutable — it is the current best understanding of the project, a clean specification of what we currently believe. Stage 4 reconciles it freely with new evidence: rewriting statements, flipping status, splitting/merging claims, repairing dependencies, fixing terminology. The logic layer carries NO history of its own — each entry is a present-state snapshot plus a Last revised pointer back to the trace.
• ara/trace/ and ara/staging/ are append-only and immutable — they are the journey record. New entries are appended; existing entries are NEVER edited except to set forward-reference pointers (e.g. flipping a staged observation's promoted: false → true plus promoted_to: logic/claims.md:C07, or appending to a session record's events for the current turn). Prior entries' content is never rewritten. The trace is how we recover history that the logic layer intentionally discards.

This split lets claims.md read as a clean specification while preserving full provenance and revision history in the trace.

When This Skill Runs

• NEVER mid-turn. Do not read or write ara/ while still working on the user's request.
• ALWAYS at end of turn. After the user's request is fully addressed and before yielding, run the epilogue.
• Per-turn cadence. A turn = one user message + the agent's response (including tool calls). The skill fires once per turn.
• Sessions are calendar-day groupings. One session record file per day; turns within the same day append to it.
• Skip empty turns. Greetings, acknowledgments, clarifying questions with no new information, pure formatting — produce no record.

The Four-Stage Pipeline

┌──────────────────┐  ┌──────────────┐  ┌──────────────────┐  ┌──────────────────────┐
│Context Harvester │->│ Event Router │->│ Maturity Tracker │->│  Logic Layer         │
│ (extract what    │  │ (classify +  │  │ (crystallize on  │  │  Reconciliation      │
│  happened)       │  │  route)      │  │  closure signal) │  │  (reconcile current  │
│                  │  │              │  │                  │  │   state w/ this turn)│
└──────────────────┘  └──────────────┘  └──────────────────┘  └──────────────────────┘

Stage 1 — Context Harvester

Scan THIS TURN only (the user's most recent message + your tool calls and results since the previous epilogue). Identify research-significant activity in two categories:

• AI actions performed: experiment runs, code edits, file creations, commands, literature searches, benchmark numbers.
• Researcher directions expressed or confirmed: hypotheses, design choices, abandoned approaches, questions, affirmations, revisions.
• Reader reports (cross-agent feedback): structured contradiction_reports produced against this ARA by a reader engine (e.g. research-foresight PREDICT §7) and supplied as input this turn — open reader-report issues on the ARA's repository, or report files handed to this run (shape: templates/reader-report.md). Each is a candidate event, NEVER an edit to apply.

Output a flat list of candidate events with raw context.

Stage 2 — Event Router

For each candidate, classify it, tag provenance, distill the payload, and route it. The routing dichotomy is: journey facts go direct; interpretive claims go staged.

→ Use references/event-taxonomy.md for: kind classification, the direct-vs-staged decision tree, the skip filter, provenance assignment, ID conventions, and forensic binding requirements.

Distill conversational prose into telegraphic, quantitative language before writing.

Stage 3 — Maturity Tracker

Walk staging/observations.yaml and decide which staged observations are mature. Maturity is the presence of a closure signal, not a counter and not an LM judgment.

Closure signal taxonomy

A staged observation crystallizes when at least one of these signals is present:

1. Topic abandonment — observation's topic has no events in the last k=5 turns AND open_threads does not reference it. Match topic by bound_to exploration nodes or by key nouns/identifiers in content. Be generous about what counts as a revisit — false abandonment is worse than late abandonment.

2. Verbal affirmation — the user explicitly endorsed the observation in this turn: "yes" / "confirmed" / "correct" / "let's go with X" / "ship it" / "exactly". The adoption must be FIRST-PERSON. Silence is not affirmation. "Maybe" / "probably" is not affirmation.

3. Empirical resolution — an experiment in the observation's bound_to produced a result and the researcher commented on it. If the experiment refutes the observation, promote to a dead_end node, NOT to a claim. The observation is closed either way.

4. Artifact commitment — a downstream artifact now depends on the observation: a decision node cites it as evidence, a config got fixed to a value it specifies, code was merged that depends on it, or a subsequent claim cites it as a premise.

Default to non-promotion. If no signal is clearly present, leave it staged. Premature crystallization is the failure mode this design exists to prevent.

Crystallization procedure

When a signal fires for O{XX}:

1. Read O{XX}'s content, context, potential_type, provenance, bound_to.
2. Allocate the next ID for the target layer (read the target file first).
3. Construct a typed entry using the schema (see Schemas below). Before any number enters a Statement/Rationale, ground it per "Number grounding" below — open the source, copy the matched line verbatim into Sources, then write the number as a copy of that quote. Carry forward provenance. Verbal-affirmation upgrades ai-suggested → user-revised (or user if reproduced verbatim). The other three signals do not upgrade provenance.
4. Add fields: Crystallized via: <signal>, From staging: O{XX}.
5. Establish forensic bindings (claim→proof, heuristic→code, decision→evidence). Use [pending] + TODO if a binding cannot be made now.
6. Update O{XX}: promoted: true, promoted_to: <layer>:<id>, crystallized_via: <signal>. Do not delete the observation — the trail from raw to typed is part of the record.

Number grounding (claims & heuristics)

Every load-bearing number in a Statement (or a heuristic's Rationale/Sensitivity/Bounds) is grounded the way code is — transcribed from an open source, never written from memory:

1. Open before you write. Before the number enters the prose, open its source and copy the matched line verbatim into Sources (<value> ← <source ref> «matched line» [input|result]). The number you then write in the prose is a copy of the value inside that quote — not a value recalled and back-cited. An entry with a bare path and no «quote» is invalid.
2. Input vs result. Tag each entry [input] (a value you set — cite the source that defines it) or [result] (a value the run produced — cite the log/output that reports it). Don't cite a measured outcome to the config meant to produce it, or vice versa.
3. No inheritance. Re-open this claim's own source for every number; a value shared with a dependency claim is re-verified here, never copied from the dependency's wording.
4. [pending] beats a guess. Can't open or locate a source this turn? Write <value> ← [pending: what's missing]. An unverified-but-plausible path is fabrication and is worse than [pending].

Contradiction trigger

When a new event contradicts something already staged or crystallized:

• Do not silently overwrite either entry.
• Flag both with <!-- CONFLICT: see {other-id} --> (or # CONFLICT: in YAML).
• Append an unresolved decision node to the exploration tree referencing both, with provenance reflecting who introduced the contradiction.
• Stop. Adjudication is the researcher's job at a future turn.

Reader reports (cross-agent feedback)

Reader reports are adjudicated by this manager in the turn they arrive — every report leaves the turn with a verdict. This is the one sanctioned exception to the contradiction trigger's defer rule, scoped to reader reports only (the manager's own mid-research contradictions still defer as above). A report targeting nothing in logic/ is simply staged as an ordinary observation (provenance: ai-suggested, report ref recorded in context). For a report targeting a crystallized entry:

1. Verify. Resolve the report's basis refs and re-read the targeted entry. The report is upheld only when evidence resolvable inside the ARA (trace nodes, evidence files, session records) corroborates the observation and genuinely contradicts the cited clause. Reader-side pointers the manager cannot resolve are recorded but do not count toward upholding.
2. Upheld → fold the correction in as a Stage 4 content revision: edit the entry (provenance ai-suggested, report ref recorded), record full before/after under logic_revisions:, and append a decision node (status: resolved) referencing both the entry and the report. Status changes follow the ordinary transition rules — an upheld report counts as empirical resolution.
3. Rejected — resolvable evidence positively shows the report wrong (does not support the observation, or does not contradict the clause) → the entry is untouched; append a decision node (status: resolved) recording the verdict and its specific reason.
4. Unverifiable — the ARA contains nothing that can corroborate or refute the observation (a report resting only on reader-side pointers) → do NOT close it as rejected: this one case falls back to the defer rule above. Flag the entry (<!-- CONFLICT: see reader-report <ref> -->) and append an unresolved decision node referencing both, carrying the report's repro for a future run to execute. A possibly-true dispute stays visible on the entry rather than dying in the session record.
5. Notify, don't wait. In every case the human receives an after-the-fact summary: the verdict and its grounds go into the session record and the turn's [PM] summary line (e.g. reader-report on C02 upheld → Conditions revised; reader-report on C04 rejected: evidence does not contradict clause; reader-report on C07 unverifiable → CONFLICT flagged, repro preserved). The manager reaches a verdict every time.

The single-writer rule is unchanged: readers never write the ARA — this manager is the only writer, and a report is INPUT to it, not an edit.

Stale-flagging

A staged observation that has neither been promoted nor referenced for 3+ session-days gets stale: true. Stale observations are surfaced at the next briefing for the researcher to triage — the manager does not auto-discard.

Stage 4 — Logic Layer Reconciliation

Reconcile logic/ (the current best understanding) with this turn's events so it stays internally consistent and faithful to present evidence. Operates only on already-crystallized entries — staged observations belong to Stage 3. (History lives in the trace; see Layer Mutability.)

What Stage 4 may do

1. Status updates — flip a claim's Status field when evidence warrants.
2. Content revisions — rewrite a Statement, Rationale, or definition when new evidence narrows scope, terminology changed, or wording no longer matches what's actually supported. Keep Statement a generalized mechanism/relationship and sharpen Conditions as the regime becomes clearer; new run numbers update Proof/evidence, never the Statement. A rewrite re-grounds every number it now contains (Number grounding); any changed value gets its own fresh Sources «quote», never a carried-over one.
3. Structural changes — split a claim into two, merge duplicates, repair dependencies, rename ids when concepts are renamed. Also generalize: when several crystallized claims are together evidence for a more general relationship none states alone, author a new claim whose Dependencies are those narrower claims and whose Proof spans their evidence — keep the narrower claims in place; the new claim sits above them, not instead of them (only when a signal this turn makes the relationship evident — never a routine sweep).
4. Consistency pass — scan for broken cross-references (claim cites C05 which no longer exists), terminology mismatch with concepts.md, dependency loops.

Allowed status transitions

hypothesis ──► testing ──► supported
     │            │            ▲
     │            └──► weakened┘
     ├────────────────► refuted    (terminal, empirical)
     ├────────────────► withdrawn  (terminal, non-empirical)
     └─ any ─────────► revised    (Statement rewritten; reset to testing/hypothesis)

• hypothesis: just crystallized; no evidence gathered yet (default for new claims)
• untested: deliberately deferred — work not started, not currently planned
• testing: an experiment that bears on the claim is in progress
• supported: empirical evidence confirms the claim
• weakened: evidence is mixed, partial, or weaker than required
• refuted: empirical evidence disproves — terminal
• withdrawn: researcher dropped the claim for non-empirical reasons (pivot, scope cut) — terminal
• revised: a transition marker, not a resting state — after recording the revision in the trace, the claim's Status settles to testing if prior evidence still applies, else hypothesis

refuted and withdrawn are terminal unless the user explicitly revives the claim (in which case route through revised).

Reconciliation signals

For each crystallized entry in logic/, check this turn for:

1. Empirical resolution — an experiment in the entry's Proof refs or bound_to nodes produced a result this turn AND the researcher commented on it.
   • Result confirms → supported (or one step toward it)
   • Result partial / narrower than claim → weakened, and consider rewriting the Statement to match the actual scope supported
   • Result disproves → refuted AND append a dead_end node referencing the claim
2. Verbal declaration — first-person, explicit, naming the claim or unambiguously referring to its content. Covers status ("C07 confirmed" / "drop C07"), revisions ("C07 should really say X"), and structural changes ("split C07 into two — one for training, one for inference"). Hedged language ("maybe", "looks like") does NOT trigger.
3. Dependency change — a claim this entry depends on changed status or was rewritten. Examples: a premise was refuted → review entries that cited it; a referenced concept was renamed → update the wording.
4. Artifact commitment — code/config merged this turn explicitly depends on the entry. Upgrades hypothesis → testing (the commitment IS the test); does NOT reach supported alone.
5. Terminology drift — a new concept added to concepts.md this turn refines or renames a term the entry uses. Update the wording for consistency.
6. Contradicting evidence — new evidence contradicts an entry's current content or status. Do not auto-overwrite. Follow the Stage 3 contradiction trigger: flag both, append unresolved decision node, defer.