Feature idea: extend /goal with intent calibration, evidence chains, and side-thread tolerance

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #19910

Powered by Codex Action

Thanks for the thoughtful feedback.

We want to make sure that the core primitives that we provide within the Codex harness are generalizable and flexible enough to support many different use cases and workflows. Many of the features and capabilities that you mention here seem like they could be built upon the existing /goal primitive. Which capabilities (if any) do you think are missing from the current core primitive?

I think one missing core primitive is phase-aware, congruence-gated continuation.

A durable /goal should not continue merely because another turn is possible. It should continue only when the previous iteration produced enough evidence to justify a concrete next action.

A minimal phase model could be:

CALIBRATE
→ EXPAND
→ COMMIT
→ EXECUTE
→ VERIFY
→ REFLECT
→ CONTINUE | RECALIBRATE | CLOSE | ESCALATE

The load-bearing transition is EXPAND → COMMIT.

Expansion may discover possibilities, risks, assumptions, and evidence. But continuation should require a committed step with:

• a concrete action;
• the evidence or assumption supporting it;
• an expected observable result;
• a verification method;
• a reconsideration or stop condition.

Without that transition, long-running agents tend toward either premature closure or repeated compression without progress: summarizing, replanning, searching, or emitting synthetic continuation prompts while external state does not materially change.

Congruence as the continuation gate

Before executing a significant next step, the goal runtime could evaluate whether the action is congruent across several dimensions:

• goal alignment — does it advance the confirmed contract?
• evidence alignment — is it supported by current verified facts rather than stale assumptions?
• system alignment — does it improve a local result without damaging architecture, safety, compatibility, or another active workstream?
• temporal alignment — is this the right action now, with prerequisites satisfied?
• consequence alignment — are the effects observable, bounded, and reversible where necessary?

This is not proof that the whole path is correct. It is permission to take the next step. Reality still validates the path through tests, measurements, and observed outcomes.

Self-observation and integrity preservation

A long-running agent also needs a lightweight external-observer state: not another worker, but a meta-level record of how the loop is behaving.

For example:

observer:
  current_phase: verify
  repeated_pattern: "third retry with unchanged hypothesis"
  unresolved_dissonance:
    - "local tests pass but backward compatibility is unverified"
  progress_signal: local
  dominant_driver: evidence | urgency | habit | recovery

This observer should not merely judge success or failure. It should detect when the system is looping, defending an old plan, hiding uncertainty, or converting urgency into synthetic progress.

I would also propose an integrity-preservation invariant: a goal should not achieve a local objective by degrading its own ability to continue safely and truthfully. For an agent, this means preserving state integrity, recovery capacity, safety constraints, and the ability to surface uncertainty rather than fabricating replacement context.

Loops amplify or attenuate forces

A loop is not neutral. Each iteration strengthens some dynamics and weakens others.

Useful runtime questions are:

• What did this iteration amplify?
• What did it attenuate?
• Did it increase verified understanding, mastery, and system coherence?
• Did it also amplify uncertainty, urgency, repeated error, or irreversible risk?

A compact state could look like:

force_delta:
  amplify:
    - verified_knowledge
    - implementation_reliability
    - system_coherence
  attenuate:
    - uncertainty
    - repeated_error
  protect:
    - safety
    - state_integrity
    - recovery_capacity

The continuation guard could then ask:

1. What changed in code, evidence, tests, or the effective goal model?
2. Is there a concrete next action still covered by the contract?
3. Is it materially different from the previous failed attempt?
4. Can its result be observed and verified?
5. Is it congruent with the goal, evidence, wider system, timing, and consequences?
6. Which forces will another iteration amplify or reduce?
7. Is continuation serving the goal, or merely avoiding recalibration or closure?

This does not require embedding a particular philosophy into /goal. The core could expose only general primitives: phase, committed_step, observer_state, force_delta, unresolved_dissonance, and transition_reason. Skills and plugins could then implement different loop strategies on top.

The key principle is:

An autonomous loop should not continue because it can. It should continue because the previous turn produced a reality-based, congruent next step while preserving the integrity of the system performing it.

One additional refinement: goal phase should be temporal, not only logical.

The previous comment treats phase as the current position in the work loop. But long-running goals also cross time boundaries: process exit, quota reset, compaction, resume, stale evidence, changed repository state, or changed permissions.

That suggests separating three clocks:

temporal_state:
  memory_freshness: current | stale | unknown
  evidence_validity: valid | revalidation_required | invalid
  action_authority: authorized | expired | blocked

These values should not be inferred from one another.

• A memory may still be durable while the evidence it contains is stale.
• Evidence may remain true while the authority to act has expired.
• A goal may still be active while the previously committed step is no longer congruent with the current system state.

So resume should not mean "continue from the last sentence." It should mean:

RESTORE MEMORY
→ REVALIDATE EVIDENCE
→ RECOMPUTE CONGRUENCE
→ RENEW ACTION AUTHORITY
→ CONTINUE OR RECALIBRATE

A minimal phase record could therefore include:

phase:
  logical: verify
  entered_at: ...
  last_validated_at: ...
  validity_horizon: ...
  resume_policy: continue | revalidate | recalibrate | block

This is closely related to lifecycle discussions around external memory and compaction boundaries in Claude Code: https://github.com/anthropics/claude-code/issues/47023

The general principle is:

Persisted state is not automatically actionable state. Time can preserve memory while invalidating evidence, congruence, or authority.

For /goal, that means every significant temporal boundary should be able to trigger a phase re-entry check rather than silently inheriting the previous continuation decision.