Retained IC Context

An IC can retain context through O_holder.

This retained context is not the same as Field state.

O_holder preserves perception history inside the IC so the DN can receive an enriched Signal without keeping hidden internal state.

Why Retention Exists

Human action often arrives across multiple steps.

Example:

type username
type password
click submit
correct password
click submit again

The DN should not need to remember all of this internally.

O_holder can accumulate the relevant Pulses and construct the enriched input Signal when the DN runs.

O_holder facilitates four client action modes:

act
commit
resume
reset

These modes are carried through:

<"_perception_mode", Y, ["act"]>

The mode tells O_holder how to handle retained context before DN execution.

act appends the new perception.

new Signal
    |
    v
append to O_holder
    |
    v
build enriched input

This is the everyday mode for typing, clicking, selecting, dragging, or otherwise expressing perception through GridLookout.

commit affirms that accumulated perception is ready for final action.

O_holder can freeze or mark the accumulated context as committed before the DN processes it.

This mode is useful for actions like:

resume rebuilds context from persistence.

This is useful when:

O_holder replays retained perception so the DN can continue from represented context rather than from an empty state.

reset clears accumulated perception.

This is not merely deletion. It is a represented human or system act:

the current path is no longer relevant

Reset is useful for:

O_holder context is local to the IC.

Field context is public to the CPUX Field after reflection.

O_holder retains what the IC needs.
O_reflector exposes what the Field should know.

This separation lets the IC remember details without forcing every detail into the Field.

Use O_holder for perception history that a DN needs.

Use O_reflector when that history produces a result that should become part of the CPUX Field.