Research draft

booting

vr.tr.booting · ACT.ACT

Enable an AI agent to recognise a booting attempt, assess progress toward an explicit operational readiness condition, and determine which interventions are permitted.

Thing Registry Activities and processes

Research draft, second pass

A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.

Researched by: Codex + Grok

Purpose and description

Enable an AI agent to recognise a booting attempt, assess progress toward an explicit operational readiness condition, and determine which interventions are permitted.

Booting is the process of starting a computer from power-on or reset by executing firmware at a hardware reset vector, initializing devices, loading successive boot programs into memory, and transferring control until a runtime system - typically an operating system - is attained.

It can be Observe startup progress and associate available console, event, or status evidence with a particular boot attempt.; Initiate an authorised boot attempt using an identified target and startup selection.; Compare observed progress with the target's stage expectations and readiness condition.; Identify a blocking dependency or trust decision and determine the authorised next action.; Select an authorised recovery or fallback path after checking its consequences.; Interrupt or retry an attempt when permitted, preserving failure evidence and applying a retry limit..

Distinguishing features

An attempt starts or re-establishes the target's foundational execution environment; opening an application within that environment does not qualify.

The activity has an identifiable initiating event and readiness boundary, even when observations cannot determine their exact times.

The target may be physical or virtual, but its identity must distinguish its boot attempt from startup activity in a host or dependent service.

A restart includes a booting segment after reset or shutdown; the preceding teardown is outside that segment.

Restoring preserved execution state is distinguished from establishing an initial execution state; hybrid cases require an explicit boundary decision.

Scope

+ The computing target, initiating trigger, starting condition, and identity of each boot attempt

+ Selection and loading of the startup path, executable images, and boot configuration

+ Progress through applicable firmware, loader, operating environment, and initialisation stages

+ Dependencies and trust checks that permit or prevent startup

+ Evidence of readiness, failure, interruption, and repeated attempts

+ Permitted observation, recovery, retry, and cancellation actions

- Installation, provisioning, and updating of the operating environment

- Routine application launch inside an already operational environment

- Steady-state operation and ongoing service health after the boot readiness boundary

- Shutdown activities preceding a restart

- Sleep, suspension, and restoration of preserved execution state

- General hardware repair and boot-image development

Characteristics

Boot target: Reference to the physical device, virtual machine, or other explicitly bounded computing target Prevents observations from different execution environments being combined into one attempt.
Starting condition: Powered off | reset | running before restart | failed startup | other evidenced condition | unknown Determines which startup stages and interventions are applicable.
Attempt state: Initiated | progressing | waiting | suspected stalled | failed | interrupted | ready | unknown Separates observed progress and terminal outcomes from uncertainty caused by missing evidence.
Current startup stage: Target-specific stage name, with observation time and evidence; unknown when unobserved Locates a blockage and limits interventions to those relevant to the active stage.
Selected boot path: References to the selected boot entry, image or device, configuration, and fallback path where applicable Distinguishes the intended environment from the environment actually being started.
Elapsed boot time: Milliseconds or seconds from a named initiating event to a named observation or readiness event Supports progress and timeout judgments without assuming one universal boot duration.
Readiness condition: Explicit target-specific acceptance predicate and its evaluation as satisfied, unsatisfied, or unknown Avoids equating a visible startup screen or a running kernel with completion.
Attempt lineage: References to preceding attempts, reset events, and automatic or manual retry causes Makes repeated failures and boot loops recognisable across otherwise separate attempts.

Also called

booting process of LinuxAndroid boot procesWindows startup process

Where this came from

wikidata · CC0 1.0

Source repository Registry entry point

Drafted structure

Bundle to layer to finding to question, as the second pass will find it: 5 bundles · 9 layers · 16 findings · 24 questions.

Boot attempt boundary Establishes which target is booting, what initiated it, and where the attempt begins and ends.

Boot events can be confused with application launches, host restarts, resumed sessions, or successive retries.

Target and trigger

Identifies the execution environment being established and the event that initiated the attempt.

Identified boot attempt

Record the target, its starting condition, and evidence that separates this attempt from neighbouring startup events.

Which computing target is establishing its execution environment, and what distinguishes it from its host or dependent applications? boundary
Which power-on, reset, watchdog, operator, or orchestration event initiated this attempt, and what evidence identifies that event? provenance

Completion boundary

Defines the operational condition that ends booting for this target.

Declared boot readiness

Record a testable readiness condition and distinguish it from intermediate signs of life.

What observable condition counts as boot complete for this target: an initial process, an interactive session, a device function, or another explicit criterion? definition
Which initialisation tasks must finish before that condition is satisfied, and which belong to subsequent operation? boundary

Startup path and handoffs Describes the selected route from initial execution to the intended operating environment.

A target can make startup progress while loading the wrong environment or failing at a particular transfer of control.

Boot selection

Captures the intended and actual startup source and configuration.

Resolved boot source

Record which startup entry, device, image, or network source was selected and how that selection was resolved.

Which boot source and configuration were intended, and which were actually selected? provenance
Did an override, boot-order rule, unavailable source, or fallback decision change the selected startup path? provenance

Execution handoffs

Tracks applicable startup stages and evidence that control passed between them.

Observed control transfer

Record the target-specific sequence of startup stages without requiring every target to have firmware, a separate loader, or a general-purpose operating system.

Which startup stages apply to this target, and what event demonstrates successful transfer of control between each pair? definition
What is the last evidenced handoff, and is the next stage unstarted, active, failed, or unobserved? measurement

Boot prerequisites and trust Captures resources and acceptance decisions required to continue the selected startup path.

Booting may wait on unavailable resources or deliberately stop at a trust boundary; those conditions require different responses.

Startup dependencies

Identifies dependencies required before the target can reach readiness.

Blocking boot dependency

Record required resources such as a boot device, network image source, root filesystem, or authorised unlock mechanism when applicable.

Which resource must the current startup stage obtain, and what evidence shows it is available or blocking progress? measurement
Can this dependency be deferred or substituted while still satisfying the declared boot readiness condition? boundary

Startup acceptance

Separates image availability from permission to execute or unlock the selected environment.

Boot trust decision

Record applicable verification or authorisation checks, their outcomes, and the policy governing continuation without storing secret material.

Which verification, integrity, or unlock checks apply to this boot path, and what evidence establishes their outcomes? provenance
If a check rejects the selected path or awaits authorisation, which recovery actions are permitted under the target's policy? action

Boot progress and recovery Supports evidence-based assessment of progress, failure, and intervention across attempts.

Silence does not by itself establish a stall, and repeated resets can obscure failure evidence or perpetuate a boot loop.

Progress evidence

Relates observations and elapsed time to stage-specific expectations.

Assessed boot progress

Record milestones, errors, observation gaps, and the basis for declaring a wait, suspected stall, failure, or successful completion.

Which milestones or errors have been observed, when were they observed, and which startup stages lack visibility? measurement
What target-specific timeout, explicit error, or readiness evidence supports the current assessment of this attempt? measurement

Bounded intervention

Connects recovery choices to authority, evidence preservation, and previous attempts.

Permitted boot recovery

Record which interventions are authorised, their preconditions, and the conditions under which retries must stop or escalate.

Which of waiting, supplying an authorised prerequisite, selecting a fallback, interrupting, or retrying is permitted now, and what evidence must be preserved first? action
How many related attempts have occurred, what changed between them, and what stopping condition prevents an uncontrolled boot loop? action

Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.

A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.