{ "model": { "rank": 5949, "code": "thing-q180256", "model_id": "vr.tr.booting", "name": "booting", "purpose": "Enable an AI agent to recognise a booting attempt, assess progress toward an explicit operational readiness condition, and determine which interventions are permitted.", "family": "Thing Registry", "category": "Activities and processes", "status": "research-draft", "kind": "thing", "plane": "ACT", "domain": "ACT.ACT", "industry": "", "version": "", "url": "/models/thing/q180256/", "tier": 2, "score": 63, "payload": { "layer": "wikidata", "aliases": [ "booting process of Linux", "Android boot proces", "Windows startup process" ], "aliasCount": 3, "merged": 3, "knownIn": 63, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q180256", "url": "https://www.wikidata.org/wiki/Q180256", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-07T10:19:24Z", "providers": [ "Codex", "Grok" ], "missingProviders": [], "pass": 2, "cost": { "grok": { "usd": 0.0406785, "turns": 4, "seconds": 242.1, "error": null }, "codex": { "seconds": 68.7, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.3\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a07b5d-8aa7-7323-a67e-27e3464d1025\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: booting\nRegistry id: vr.tr.booting\nPlane / domain: ACT / ACT.ACT\nRegistry definition: (none recorded)\nNames folded into this entry: (none)\n\nA Vercy m" } } }, "metaModel": { "id": "THING-Q180256", "registryId": "vr.tr.booting", "name": "booting", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "ACT.ACT" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q180256/", "model": { "registry_id": "vr.tr.booting", "name": "booting", "purpose": "Enable an AI agent to recognise a booting attempt, assess progress toward an explicit operational readiness condition, and determine which interventions are permitted.", "definition": "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.", "scope_statement": "This draft interprets booting as the activity that brings a computing target from an off, reset, or otherwise non-operational execution state into an initial operational state; it owns the attempt, startup control transfers, dependencies, evidence of progress, and intervention boundaries.", "in_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" ], "out_of_scope": [ "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" ], "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." ], "characteristics": [ { "name": "Boot target", "kind": "relation", "unit_or_values": "Reference to the physical device, virtual machine, or other explicitly bounded computing target", "why_it_matters": "Prevents observations from different execution environments being combined into one attempt." }, { "name": "Starting condition", "kind": "category", "unit_or_values": "Powered off | reset | running before restart | failed startup | other evidenced condition | unknown", "why_it_matters": "Determines which startup stages and interventions are applicable." }, { "name": "Attempt state", "kind": "state", "unit_or_values": "Initiated | progressing | waiting | suspected stalled | failed | interrupted | ready | unknown", "why_it_matters": "Separates observed progress and terminal outcomes from uncertainty caused by missing evidence." }, { "name": "Current startup stage", "kind": "state", "unit_or_values": "Target-specific stage name, with observation time and evidence; unknown when unobserved", "why_it_matters": "Locates a blockage and limits interventions to those relevant to the active stage." }, { "name": "Selected boot path", "kind": "relation", "unit_or_values": "References to the selected boot entry, image or device, configuration, and fallback path where applicable", "why_it_matters": "Distinguishes the intended environment from the environment actually being started." }, { "name": "Elapsed boot time", "kind": "measurement", "unit_or_values": "Milliseconds or seconds from a named initiating event to a named observation or readiness event", "why_it_matters": "Supports progress and timeout judgments without assuming one universal boot duration." }, { "name": "Readiness condition", "kind": "category", "unit_or_values": "Explicit target-specific acceptance predicate and its evaluation as satisfied, unsatisfied, or unknown", "why_it_matters": "Avoids equating a visible startup screen or a running kernel with completion." }, { "name": "Attempt lineage", "kind": "relation", "unit_or_values": "References to preceding attempts, reset events, and automatic or manual retry causes", "why_it_matters": "Makes repeated failures and boot loops recognisable across otherwise separate attempts." } ], "affordances": [ "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." ] }, "sources": [ { "id": "wikipedia-booting", "title": "Booting", "url": "https://en.wikipedia.org/wiki/Booting", "what_it_supports": "Process definition; hard vs soft reboot; IPL; UEFI vs BIOS; PXE; El Torito; Open Firmware; hibernation vs sleep; MBR/reset-vector details; etymology.", "url_status": "live" }, { "id": "wikidata-q180256", "title": "booting (Q180256)", "url": "https://www.wikidata.org/wiki/Q180256", "what_it_supports": "Canonical identifier, aliases (boot process, computer startup, boot sequence), subclass of planned process, uses bootloader and firmware.", "url_status": "live" }, { "id": "ms-boot-uefi", "title": "Boot and UEFI", "url": "https://learn.microsoft.com/en-us/previous-versions/windows/drivers/bringup/boot-and-uefi", "what_it_supports": "Vendor-specific SoC firmware then UEFI then Windows Boot Manager handoff on Windows 10 devices.", "url_status": "live" }, { "id": "uefi-forum-specs", "title": "UEFI Specifications", "url": "https://uefi.org/specifications", "what_it_supports": "Governing firmware/boot-manager specification (v2.10 family) and pointer to TCG measured-boot profiles.", "url_status": "blocked" }, { "id": "baeldung-boot-process", "title": "Computer Boot Process Explained", "url": "https://www.baeldung.com/cs/computer-boot-process", "what_it_supports": "BIOS→POST→MBR→bootloader sequence and the 512-byte MBR layout (446+64+2).", "url_status": "live" }, { "id": "ms-secure-boot", "title": "Secure boot", "url": "https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot", "what_it_supports": "Industry Secure Boot profile: UEFI 2.3.1 authenticated variables, PK/KEK/db, RSA-2048/SHA-256 firmware signing.", "url_status": "live" }, { "id": "nist-sp-800-147", "title": "SP 800-147, BIOS Protection Guidelines", "url": "", "what_it_supports": "NIST guidelines treating conventional BIOS, EFI, and UEFI as boot firmware that must be protected against unauthorized modification." } ], "structure": { "bundles": [ { "id": "boot-attempt-boundary", "name": "Boot attempt boundary", "description": "Establishes which target is booting, what initiated it, and where the attempt begins and ends.", "rationale": "Boot events can be confused with application launches, host restarts, resumed sessions, or successive retries.", "layers": [ { "id": "target-and-trigger", "name": "Target and trigger", "description": "Identifies the execution environment being established and the event that initiated the attempt.", "findings": [ { "id": "identified-boot-attempt", "name": "Identified boot attempt", "description": "Record the target, its starting condition, and evidence that separates this attempt from neighbouring startup events.", "questions": [ { "text": "Which computing target is establishing its execution environment, and what distinguishes it from its host or dependent applications?", "kind": "boundary", "id": "identified-boot-attempt-q01" }, { "text": "Which power-on, reset, watchdog, operator, or orchestration event initiated this attempt, and what evidence identifies that event?", "kind": "provenance", "id": "identified-boot-attempt-q02" } ] } ] }, { "id": "completion-boundary", "name": "Completion boundary", "description": "Defines the operational condition that ends booting for this target.", "findings": [ { "id": "declared-boot-readiness", "name": "Declared boot readiness", "description": "Record a testable readiness condition and distinguish it from intermediate signs of life.", "questions": [ { "text": "What observable condition counts as boot complete for this target: an initial process, an interactive session, a device function, or another explicit criterion?", "kind": "definition", "id": "declared-boot-readiness-q01" }, { "text": "Which initialisation tasks must finish before that condition is satisfied, and which belong to subsequent operation?", "kind": "boundary", "id": "declared-boot-readiness-q02" } ] } ] } ] }, { "id": "startup-path-and-handoffs", "name": "Startup path and handoffs", "description": "Describes the selected route from initial execution to the intended operating environment.", "rationale": "A target can make startup progress while loading the wrong environment or failing at a particular transfer of control.", "layers": [ { "id": "boot-selection", "name": "Boot selection", "description": "Captures the intended and actual startup source and configuration.", "findings": [ { "id": "resolved-boot-source", "name": "Resolved boot source", "description": "Record which startup entry, device, image, or network source was selected and how that selection was resolved.", "questions": [ { "text": "Which boot source and configuration were intended, and which were actually selected?", "kind": "provenance", "id": "resolved-boot-source-q01" }, { "text": "Did an override, boot-order rule, unavailable source, or fallback decision change the selected startup path?", "kind": "provenance", "id": "resolved-boot-source-q02" } ] } ] }, { "id": "execution-handoffs", "name": "Execution handoffs", "description": "Tracks applicable startup stages and evidence that control passed between them.", "findings": [ { "id": "observed-control-transfer", "name": "Observed control transfer", "description": "Record the target-specific sequence of startup stages without requiring every target to have firmware, a separate loader, or a general-purpose operating system.", "questions": [ { "text": "Which startup stages apply to this target, and what event demonstrates successful transfer of control between each pair?", "kind": "definition", "id": "observed-control-transfer-q01" }, { "text": "What is the last evidenced handoff, and is the next stage unstarted, active, failed, or unobserved?", "kind": "measurement", "id": "observed-control-transfer-q02" } ] } ] } ] }, { "id": "boot-prerequisites-and-trust", "name": "Boot prerequisites and trust", "description": "Captures resources and acceptance decisions required to continue the selected startup path.", "rationale": "Booting may wait on unavailable resources or deliberately stop at a trust boundary; those conditions require different responses.", "layers": [ { "id": "startup-dependencies", "name": "Startup dependencies", "description": "Identifies dependencies required before the target can reach readiness.", "findings": [ { "id": "blocking-boot-dependency", "name": "Blocking boot dependency", "description": "Record required resources such as a boot device, network image source, root filesystem, or authorised unlock mechanism when applicable.", "questions": [ { "text": "Which resource must the current startup stage obtain, and what evidence shows it is available or blocking progress?", "kind": "measurement", "id": "blocking-boot-dependency-q01" }, { "text": "Can this dependency be deferred or substituted while still satisfying the declared boot readiness condition?", "kind": "boundary", "id": "blocking-boot-dependency-q02" } ] } ] }, { "id": "startup-acceptance", "name": "Startup acceptance", "description": "Separates image availability from permission to execute or unlock the selected environment.", "findings": [ { "id": "boot-trust-decision", "name": "Boot trust decision", "description": "Record applicable verification or authorisation checks, their outcomes, and the policy governing continuation without storing secret material.", "questions": [ { "text": "Which verification, integrity, or unlock checks apply to this boot path, and what evidence establishes their outcomes?", "kind": "provenance", "id": "boot-trust-decision-q01" }, { "text": "If a check rejects the selected path or awaits authorisation, which recovery actions are permitted under the target's policy?", "kind": "action", "id": "boot-trust-decision-q02" } ] } ] } ] }, { "id": "boot-progress-and-recovery", "name": "Boot progress and recovery", "description": "Supports evidence-based assessment of progress, failure, and intervention across attempts.", "rationale": "Silence does not by itself establish a stall, and repeated resets can obscure failure evidence or perpetuate a boot loop.", "layers": [ { "id": "progress-evidence", "name": "Progress evidence", "description": "Relates observations and elapsed time to stage-specific expectations.", "findings": [ { "id": "assessed-boot-progress", "name": "Assessed boot progress", "description": "Record milestones, errors, observation gaps, and the basis for declaring a wait, suspected stall, failure, or successful completion.", "questions": [ { "text": "Which milestones or errors have been observed, when were they observed, and which startup stages lack visibility?", "kind": "measurement", "id": "assessed-boot-progress-q01" }, { "text": "What target-specific timeout, explicit error, or readiness evidence supports the current assessment of this attempt?", "kind": "measurement", "id": "assessed-boot-progress-q02" } ] } ] }, { "id": "bounded-intervention", "name": "Bounded intervention", "description": "Connects recovery choices to authority, evidence preservation, and previous attempts.", "findings": [ { "id": "permitted-boot-recovery", "name": "Permitted boot recovery", "description": "Record which interventions are authorised, their preconditions, and the conditions under which retries must stop or escalate.", "questions": [ { "text": "Which of waiting, supplying an authorised prerequisite, selecting a fallback, interrupting, or retrying is permitted now, and what evidence must be preserved first?", "kind": "action", "id": "permitted-boot-recovery-q01" }, { "text": "How many related attempts have occurred, what changed between them, and what stopping condition prevents an uncontrolled boot loop?", "kind": "action", "id": "permitted-boot-recovery-q02" } ] } ] } ] }, { "id": "evidence-and-external-alignment", "name": "Evidence and external alignment", "description": "What the world already says about this thing, gathered so the model can be checked against it.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "layers": [ { "id": "reported-evidence", "name": "Reported evidence", "description": "Findings from the breadth pass, kept separate from the structural claims.", "findings": [ { "id": "evidence-kinds", "name": "Kinds and varieties", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Cold (hard) boot: full power-on from off, including POST and DRAM/device initialization", "Warm (soft) reboot: restart without cutting CPU power; some hardware init may be skipped", "UEFI boot: firmware boot manager loads PE/EFI executables from an EFI System Partition", "Legacy BIOS/CSM boot: firmware loads an MBR/VBR boot sector and chain-loads later stages", "Network boot (PXE): NIC firmware fetches a boot image over TFTP after DHCP discovery", "Secure or measured boot: each stage is signature-checked and optionally hashed into a TPM", "Dual or multi-boot: a boot manager presents a choice of OS images or rescue tools", "Hibernation resume: the firmware/bootloader restores a saved memory image from disk (unlike S3 sleep, which is not a boot)" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of booting this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-identifiers", "name": "Identifiers and schemes", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "scheme": "Wikidata", "value_or_pattern": "Q180256", "note": "Item 'booting': process of starting a computer." }, { "scheme": "IBM IPL", "value_or_pattern": "Initial Program Load from a three- or four-hex-digit device address (CUU / CSS.CHPID.UA on later systems)", "note": "Name used on System/360 and z/Architecture instead of 'boot'." }, { "scheme": "UEFI boot option", "value_or_pattern": "Boot#### (hex 0000-FFFF) NVRAM variable plus BootOrder", "note": "Firmware-persisted boot entries defined by the UEFI specification." }, { "scheme": "x86 reset vector", "value_or_pattern": "physical 0xFFFFFFF0 (32/64-bit) or 0xFFFF0 (16-bit)", "note": "First instruction fetch after reset; typically a jump into firmware ROM." }, { "scheme": "MBR boot signature", "value_or_pattern": "0x55 0xAA at bytes 510-511 of sector 0", "note": "Little-endian word AA55h that BIOS treats as evidence a sector is bootable." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of booting this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-standards-and-regulation", "name": "Standards and regulation", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "UEFI Specification (v2.10 family, UEFI Forum) - firmware boot manager, ESP, Secure Boot variables and image validation", "IEEE Std 1275-1994 Open Firmware (IEEE) - Forth-based boot firmware used on SPARC and some PowerPC Macs", "Preboot Execution Environment (PXE) specification (Intel) - DHCP/TFTP network boot", "El Torito Bootable CD-ROM Format Specification (Phoenix Technologies / IBM) - optical-disc boot", "NIST SP 800-147 BIOS Protection Guidelines (NIST) - authorized, authenticated update of PC client boot firmware", "Windows Hardware Compatibility Program UEFI Secure Boot requirements (Microsoft) - PK/KEK/db provisioning and signed boot path for Windows" ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of booting this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-real-world-use", "name": "Real-world use", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Pressing the power button on a PC, phone, or server so firmware POST/init runs, a boot device is selected, and the OS reaches a login or ready state", "Software reboot after kernel update, driver install, or crash recovery", "Enterprise imaging: PXE-boot a fleet of PCs from a deployment server", "Installer and rescue media: boot from USB, ISO (El Torito), or Windows To Go-style live drives", "Dual-boot menus (GRUB, rEFInd, Windows Boot Manager) choosing among OS partitions", "IBM Z operator IPL from a specified DASD, tape, or virtual device", "Embedded and appliance devices executing from ROM/flash with little or no secondary-store load" ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of booting this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-measurements", "name": "Typical measurements", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "quantity": "Time from power-on to firmware handoff (POST/init)", "typical_range": "about 1-30 on PCs; near 0 when the runtime executes in place from ROM", "unit": "s" }, { "quantity": "Time from power-on to interactive OS", "typical_range": "about 10-90 on modern SSD desktops; minutes on HDD, first boot after update, or VDI boot storms", "unit": "s" }, { "quantity": "MBR first-stage code size", "typical_range": "up to 446 in a 512-byte sector (64-byte partition table + 2-byte signature)", "unit": "byte" }, { "quantity": "BIOS boot-sector load address", "typical_range": "linear 0x7C00", "unit": "address" }, { "quantity": "UEFI Secure Boot signature strength (Microsoft profile)", "typical_range": "RSA-2048 with SHA-256 minimum for firmware components", "unit": "algorithm" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of booting this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-failure-modes-and-hazards", "name": "Failure modes and hazards", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "POST halt: missing/failed RAM, CPU, or other required hardware (beep codes or firmware error screens)", "No bootable device or wrong boot order (empty optical/USB first, missing ESP, corrupt MBR signature)", "Damaged bootloader, ESP, or kernel image causing a boot loop, recovery prompt, or drop to firmware shell", "Secure Boot rejection of an unsigned or wrongly signed bootloader (common after Linux install or key expiry)", "Unauthorized firmware modification: persistent malware or permanent denial of service below the OS", "Boot storm: many clients booting at once saturate storage or network (VDI/PXE)", "Dual-boot overwrite: one OS installer replaces another's bootloader", "Failed firmware update leaving the platform unbootable (brick)" ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of booting this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-regional-variation", "name": "Regional variation", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "IBM mainframe practice names the same act Initial Program Load (IPL), not 'boot'", "Spanish: arranque; French: démarrage / amorçage; German: Bootvorgang / Hochfahren; Chinese: 开机 / 启动", "Many PC vendors still label UEFI setup screens 'BIOS' in every market, which confuses firmware generation with the boot process", "Open Firmware (IEEE 1275) was the workstation/Mac PowerPC path; x86 PCs standardized on BIOS then UEFI" ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of booting this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-neighbours", "name": "Neighbouring kinds and how to tell them apart", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "name": "bootloader", "difference": "A bootloader is a program (BIOS/UEFI, GRUB, BOOTMGR, U-Boot) used during booting; booting is the whole start-up process that uses one or more such programs." }, { "name": "reboot", "difference": "A reboot is a restart of an already-running machine; it is an instance of booting, not a different process, and may be hard (power cycle) or soft." }, { "name": "power-on self-test (POST)", "difference": "POST is the firmware diagnostic/init phase; booting includes POST plus locating a boot device and loading a runtime. POST can fail with no OS ever loaded." }, { "name": "sleep / ACPI S3 wake", "difference": "Sleep keeps RAM powered and does not reload the OS; Wikipedia treats wake-from-sleep as not booting, unlike resume from hibernation." }, { "name": "application or service startup", "difference": "Starts after the OS is already running; booting ends when the runtime can run system or application programs." }, { "name": "bootstrapping (general / statistics)", "difference": "The etymological parent ('pull oneself up by one's bootstraps') and the statistical resampling method; neither is the computer start-up sequence." }, { "name": "boot (footwear)", "difference": "Homonym (Wikidata Q190868); this entry is the computing process Q180256." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of booting this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does the registry intend computing startup by 'booting', or another activity such as kicking or expulsion, given that no definition is recorded?", "Which existing Vercy world model, if any, already owns computing booting and should be linked instead of creating a separate model?", "Which target classes belong here, particularly containers, embedded runtimes, and application environments that describe their own startup as booting?", "How should hybrid startup, hibernation restoration, and direct operating-environment replacement be bounded against neighbouring resume and restart models?", "Which authoritative target-specific sources establish stage expectations, readiness criteria, timeout policies, and permitted recovery actions?" ], "statistics": { "bundles": 5, "layers": 9, "findings": 16, "questions": 24 } }, "draft": { "generator": "vr.draft.v3", "status": "draft-generated", "researched": false, "archetype": "abstract concept", "method": "Written from the archetype playbook - what this kind of thing needs beyond identity and provenance - and from the structure that recurred across 6,333 models already researched by two engines. Applied to this entry by rule. No source was read for this thing and no claim here is researched. This entry carries no facets of its own, so they were inferred from its domain - a guess about a whole domain applied to one thing.", "facetsInferred": true, "nextPass": "A researcher replaces this draft with a sourced specification. Treat every sentence below as a proposal to argue with.", "purpose": "Give an agent a durable, checkable way to recognise a booting, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an AI agent to recognise a booting attempt, assess progress toward an explicit operational readiness condition, and determine which interventions are permitted.", "characteristics": { "substance": "activity", "origin": "conceptual", "agency": "inert" }, "whatYouCanDoWithIt": [ "observed and measured" ], "distinguishingFeatures": [ "Names folded into this entry, which a task may need to split apart again: booting process of Linux, Android boot proces, Windows startup process.", "3 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 63 Wikipedia languages, which is a measure of how widely the thing is known, not of how important it is." ], "openQuestionsForResearch": [ "Which of the bundles below does a real task actually need, and which are ceremony?", "What does this thing have that the facets do not capture at all?", "Which neighbouring kind is most often confused with a booting, and on what evidence are they told apart?" ], "whatItIsMadeOf": "something that happens over time", "physicalCharacter": [ "Does nothing on its own; everything it does, something else did to it.", "These come from the domain this entry sits in rather than from the entry itself, so treat them as a first guess about the whole domain applied to one thing." ], "whatCanBeDoneWithIt": [ "observe it, measure it, record its state" ], "howItIsRecognised": [ "Nothing to see. What is recognised is an instance of it, and which instances count is exactly what is argued about." ], "relatedModels": [ { "relation": "covers", "note": "Finer kinds folded into this entry because telling them apart needs a task that asks for it. Each is a model waiting to be split out when one does.", "targets": [ "booting process of Linux", "Android boot proces", "Windows startup process" ] } ], "standing": "Described in 63 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 3 finer distinctions are held inside this entry as names rather than as separate models.", "structure": { "bundles": [ { "id": "identity-and-classification", "name": "Identity, naming and classification", "description": "How an agent tells one booting from another, and a booting from things that resemble it.", "rationale": "Recognition comes before every other claim. Without stable identity nothing else in the model can be trusted to be about the same thing twice.", "layers": [ { "id": "naming-and-identifiers", "name": "Names and identifiers", "description": "The names this thing goes by and the identifiers that survive translation and time.", "findings": [ { "id": "preferred-name-and-aliases", "name": "Preferred name, aliases and local names", "description": "Which name to use, which names mean the same thing, and which merely sound similar.", "questions": [ { "id": "preferred-name-and-aliases-q01", "text": "What identifies and describes the name of a booting, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "preferred-name-and-aliases-q02", "text": "Who or what asserted this about the name of a booting, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "preferred-name-and-aliases-q03", "text": "What may an agent decide or do once the name of a booting is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] }, { "id": "stable-identifiers", "name": "Stable identifiers and external keys", "description": "Identifiers that keep pointing at this kind of thing across systems and languages.", "questions": [ { "id": "stable-identifiers-q01", "text": "What identifies and describes an identifier for a booting, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "stable-identifiers-q02", "text": "Who or what asserted this about an identifier for a booting, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "stable-identifiers-q03", "text": "What may an agent decide or do once an identifier for a booting is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "classification-and-granularity", "name": "Classification and granularity", "description": "Where a booting sits among kinds, and how finely a task needs to cut it.", "findings": [ { "id": "kind-and-parents", "name": "Kind, parents and neighbouring kinds", "description": "The classes this thing belongs to and the ones it is next to.", "questions": [ { "id": "kind-and-parents-q01", "text": "What identifies and describes the kind of a booting, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "kind-and-parents-q02", "text": "Who or what asserted this about the kind of a booting, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "kind-and-parents-q03", "text": "What may an agent decide or do once the kind of a booting is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] }, { "id": "distinguishing-features", "name": "Distinguishing features", "description": "What separates a booting from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a booting, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "distinguishing-features-q02", "text": "Who or what asserted this about what distinguishes a booting, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "distinguishing-features-q03", "text": "What may an agent decide or do once what distinguishes a booting is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "state-and-lifecycle", "name": "State and lifecycle", "description": "The states a booting passes through and the events that move it between them.", "rationale": "Most decisions about a thing depend on what state it is in now, which is a claim with a time on it, not a property.", "layers": [ { "id": "lifecycle-stages", "name": "Lifecycle stages", "description": "From coming into existence to ceasing to be one of these.", "findings": [ { "id": "stages-and-transitions", "name": "Stages and transitions", "description": "The stages worth naming and what moves a booting between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a booting, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "stages-and-transitions-q02", "text": "Who or what asserted this about the lifecycle of a booting, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "stages-and-transitions-q03", "text": "What may an agent decide or do once the lifecycle of a booting is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "observations-and-status", "name": "Observations and current status", "description": "What is observed about a booting, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a booting is recorded so that it can be superseded rather than overwritten.", "questions": [ { "id": "observation-record-q01", "text": "What identifies and describes an observation of a booting, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "observation-record-q02", "text": "Who or what asserted this about an observation of a booting, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "observation-record-q03", "text": "What may an agent decide or do once an observation of a booting is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "process-and-outcome", "name": "Process, inputs and outcome", "description": "How a booting proceeds, what it needs and what it leaves behind.", "rationale": "An activity is known by its steps and its results, and both have to be recordable while it is still running.", "layers": [ { "id": "steps-and-sequence", "name": "Steps and sequence", "description": "The steps of a booting, their order and what may run in parallel.", "findings": [ { "id": "steps-and-preconditions", "name": "Steps, preconditions and completion", "description": "What has to be true before each step of a booting and what marks it done.", "questions": [ { "id": "steps-and-preconditions-q01", "text": "What identifies and describes a step of a booting, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "steps-and-preconditions-q02", "text": "Who or what asserted this about a step of a booting, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "steps-and-preconditions-q03", "text": "What may an agent decide or do once a step of a booting is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "inputs-and-results", "name": "Inputs, resources and results", "description": "What a booting consumes and what it produces.", "findings": [ { "id": "inputs-and-outputs", "name": "Inputs, outputs and side effects", "description": "The resources a booting takes and the results it leaves, wanted or not.", "questions": [ { "id": "inputs-and-outputs-q01", "text": "What identifies and describes the inputs and results of a booting, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "inputs-and-outputs-q02", "text": "Who or what asserted this about the inputs and results of a booting, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "inputs-and-outputs-q03", "text": "What may an agent decide or do once the inputs and results of a booting is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "definitions-in-contest", "name": "Definitions and who holds them", "description": "What booting is taken to mean, and by whom.", "rationale": "When a field disagrees about a concept, the disagreement is the content. A model that picks one definition silently destroys the information.", "layers": [ { "id": "competing-definitions", "name": "Competing definitions", "description": "The main readings and the traditions behind them.", "findings": [ { "id": "definition-map", "name": "Definitions and their holders", "description": "Each definition with the school or body that holds it.", "questions": [ { "id": "definition-map-q01", "text": "Which definitions of booting are in use, and which tradition or body holds each?", "kind": "definition" }, { "id": "definition-map-q02", "text": "What turns on the difference between them in practice?", "kind": "boundary" } ] } ] }, { "id": "operationalisation", "name": "Operationalisation", "description": "How it is measured or applied when it has to be.", "findings": [ { "id": "operational-record", "name": "Measures and proxies", "description": "Instruments and indicators used to stand in for it.", "questions": [ { "id": "operational-record-q01", "text": "How is booting operationalised or measured in practice, and by what instrument?", "kind": "measurement" }, { "id": "operational-record-q02", "text": "What does that operationalisation leave out, and when does that matter?", "kind": "boundary" } ] } ] } ] }, { "id": "instances-and-use", "name": "Instances, use and consequence", "description": "What counts as an instance of booting and what follows from calling something that.", "rationale": "Applying a concept is an act with consequences, so a model must say what the label licenses and what it does not.", "layers": [ { "id": "instances", "name": "What counts as an instance", "description": "Clear cases, borderline cases and non-cases.", "findings": [ { "id": "instance-tests", "name": "Tests for an instance", "description": "What would settle whether something falls under it.", "questions": [ { "id": "instance-tests-q01", "text": "What would settle whether something is an instance of booting?", "kind": "boundary" }, { "id": "instance-tests-q02", "text": "Which borderline cases are argued about, and on what grounds?", "kind": "definition" } ] } ] }, { "id": "consequence", "name": "Consequence of application", "description": "Rights, duties or decisions that follow from the label.", "findings": [ { "id": "consequence-record", "name": "What the label licenses", "description": "What an agent may do once something is classified this way.", "questions": [ { "id": "consequence-record-q01", "text": "What follows practically once something is treated as booting?", "kind": "action" }, { "id": "consequence-record-q02", "text": "What must an agent not infer from the label alone?", "kind": "action" } ] } ] } ] }, { "id": "provenance-and-evidence", "name": "Provenance, evidence and time", "description": "Where every claim about a booting came from and when it held.", "rationale": "A claim without a source and a time cannot be superseded, only overwritten, and an agent that overwrites loses the ability to explain itself.", "layers": [ { "id": "source-and-authority", "name": "Source and authority", "description": "Who said it, on what evidence, and how strongly.", "findings": [ { "id": "claim-provenance", "name": "Claim provenance and confidence", "description": "The authority behind each claim about a booting and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a booting, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "claim-provenance-q02", "text": "Who or what asserted this about a claim about a booting, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "claim-provenance-q03", "text": "What may an agent decide or do once a claim about a booting is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "time-and-versions", "name": "Time, versions and supersession", "description": "When a claim was true, when it was learnt, and what replaced it.", "findings": [ { "id": "validity-and-supersession", "name": "Validity period and supersession", "description": "How an old claim about a booting is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a booting, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "validity-and-supersession-q02", "text": "Who or what asserted this about the validity of a claim about a booting, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "validity-and-supersession-q03", "text": "What may an agent decide or do once the validity of a claim about a booting is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] } ] }, "statistics": { "bundles": 6, "layers": 12, "findings": 14, "questions": 38 } } } }