program
(computer science) a sequence of instructions that a computer can interpret and execute
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 computer program, assess whether its instructions can achieve an intended result in a given environment, and determine which execution or modification actions are justified.
A computer program is a finite, ordered body of instructions together with any associated data definitions, expressed in a programming language or in machine code, that a processor or language processor can interpret or execute in order to perform a specified computation or to control a digital process.
It can be Inspect instructions and identify their execution boundaries and entry points.; Check whether a specified environment satisfies preparation and runtime requirements.; Prepare an executable form through the applicable compilation, linking or interpretation route.; Execute under authorised permissions and explicit containment and resource limits.; Test observable behaviour against stated expectations and record failures.; Compare or modify revisions and determine which existing evidence must be renewed..
Distinguishing features
Its content has an instruction interpretation for an identified computer execution mechanism; ordinary prose describing an algorithm does not by itself meet this test.
It can remain the same program artifact across multiple executions; a process denotes a particular running instance.
It expresses a computation through instructions, whereas a dataset supplies values unless an execution mechanism explicitly interprets those values as instructions.
Its instruction boundary can be identified within a package or product; the enclosing distribution may also contain documentation, data and multiple programs.
It has an identifiable execution or invocation route, which may require an interpreter, compilation, linking or a host rather than a standalone executable file.
Scope
+ Instruction content, representation and program boundaries
+ Intended behaviour, inputs, outputs and observable effects
+ Execution entry points, dependencies and environmental requirements
+ Conditions governing execution, failure and resource use
+ Revision identity and evidence supporting execution or modification decisions
- A running process's current memory, scheduling and resource allocations
- The computer or virtual machine that executes instructions
- Programming languages and their general semantics
- A software product's commercial packaging, roadmap and support organisation
- Datasets consumed or produced by the program as independently managed things
- Broadcast programmes, event programmes and organisational programmes
Characteristics
- Instruction representation
- Source text, bytecode, machine code, mixed representation, other specified representation or unknown Determines how instructions can be inspected and what preparation they require before execution.
- Revision identity
- Association with an exact source revision or artifact digest, with any human-readable version label Binds behavioural and safety evidence to the instructions actually being considered.
- Execution mechanism
- Identified processor architecture, interpreter, virtual machine or host, including relevant versions Establishes which mechanism assigns executable meaning to the instructions.
- Invocation form
- Command invocation, hosted invocation, event callback, continuous execution or other specified form Identifies how execution begins and how inputs and completion are exposed.
- Execution readiness
- Unknown, preparation required, blocked, ready for a specified environment or incompatible Separates possession of instructions from having the prerequisites needed to execute them.
- Effect surface
- Declared and observed effects on files, networks, persistent stores, devices, subprocesses and external services Supports containment, permission and reversibility decisions.
- Required authority
- Required permissions, credentials and capabilities scoped to operations and resources Allows an agent to assess whether execution is authorised and whether privileges can be restricted.
- Observed resource demand
- Elapsed seconds, processor seconds, peak memory bytes and I/O bytes for a stated workload and environment Supports capacity and limit decisions without treating one measurement as a universal bound.
- Behavioural verification status
- Unassessed, evidence supports specified claims, conflicting evidence or known failure, scoped to revision and environment Prevents successful execution or isolated tests from being mistaken for general correctness.
Analytical facets
- substance
- information
- origin
- conceptual
- agency
- operable
- mobility
- not-applicable
- scale
- not-applicable
- affordances
- operable, readable
Also called
+56
Where this came from
oewn:2024 · CC BY 4.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 6 bundles · 11 layers · 18 findings · 28 questions.
Instruction identity Identifies which instructions constitute the program and how their executable meaning is established.
An agent must distinguish the program from its packaging, supporting data and individual executions before attaching claims to it.
Program boundary
Locates the instruction sequence and its included components.
Instruction membership
Records the artifacts or instruction regions treated as this program and the basis for including them.
- Which files, modules or instruction regions constitute this program? definition
- Which adjacent resources are separate programs, libraries, configuration or input data? boundary
Instruction interpretation
Establishes the representation and mechanism that give the instructions computational meaning.
Execution semantics
Records the language, instruction format and execution mechanism on which interpretation depends.
- What language or instruction format expresses the program, and which execution mechanism interprets it? definition
- Which version-specific or implementation-specific behaviours could change the meaning of these instructions? boundary
Behavioural contract Describes the computation the program is intended to perform and the observations that would support that claim.
A program's state cannot be judged from executability alone; the agent needs expectations against which its behaviour can be assessed.
Invocation and inputs
Defines how the program starts and which supplied or ambient values influence its computation.
Entry and preconditions
Records callable entry points, input meanings and conditions required for an invocation to be valid.
- Through which entry points is the program invoked, and what arguments, streams, events or ambient state does each consume? definition
- Which input constraints and preconditions separate supported invocations from invalid or unspecified cases? boundary
Results and completion
Defines expected observations and the meaning of success, failure or continued operation.
Observable outcomes
Records expected outputs, persistent effects and completion conditions, including permitted variability.
- Which outputs and state changes constitute the intended result for a valid invocation? definition
- How are success, failure and intentional continued operation distinguished, and what outcome variability is permitted? measurement
Execution feasibility Captures the prerequisites and operating limits under which the program can run.
Instructions may be valid yet unusable because preparation steps, dependencies or execution capacity are missing.
Preparation and dependencies
Connects the available instruction artifacts to an executable form and a compatible environment.
Execution prerequisites
Records necessary transformations, dependency versions and platform requirements.
- What compilation, linking, generation or loading steps are required before these instructions can execute? action
- Which runtime components, dependency versions, platform features and external services are required for the proposed use? boundary
Resource and progress conditions
Captures resource demand and expectations about progress for specified workloads.
Operating envelope
Records measured consumption, configured limits and known conditions for blocking, exhaustion or nontermination.
- What time, memory and I/O consumption has been measured, for which workloads and execution environments? measurement
- What evidence supports progress or termination expectations, and what timeout or cancellation action is appropriate when those expectations fail? action
Effects and execution control Makes the program's access requirements and consequences usable in execution decisions.
Executing instructions can alter external state, so an agent needs to understand authority, containment and recovery before running them.
Access and side effects
Identifies resources the program can access and operations it may perform.
Authority and effect map
Connects required capabilities to expected or observed operations on external resources.
- Which files, network destinations, stores, devices or subprocesses can the program read, create, change or invoke? boundary
- Which permissions and credentials are needed for the intended operation, and can execution use narrower authority? action
Containment and recovery
Describes controls for limiting effects and handling interruption or partial completion.
Controlled execution
Records applicable isolation, interruption, retry and compensation conditions.
- Which sandbox, dry-run mode or resource restrictions can constrain this execution while preserving its intended behaviour? action
- If execution fails or is interrupted after partial effects, what can be rolled back, compensated or safely retried? action
Revision and behavioural evidence Binds program identity and change history to evidence about actual behaviour.
Trust in one revision or environment does not automatically transfer to another, and an agent must know which claims remain supported.
Artifact lineage
Identifies the exact instruction artifacts and their relationship to source and transformations.
Source-to-executable trace
Records revision identifiers, artifact digests and available evidence connecting source to executable content.
- Which revision identifiers or digests identify the instructions being inspected and the artifact proposed for execution? provenance
- What evidence connects the executable artifact to its claimed source, build inputs and transformation process? provenance
Verification and change impact
Tracks supported behavioural claims, known defects and the implications of instruction changes.
Claim and evidence coverage
Associates behavioural expectations with tests, analyses or observations and identifies where changes require renewed assessment.
- Which tests, analyses or execution observations support each behavioural claim, and which revisions, inputs and environments do they cover? provenance
- Given known defects or a proposed instruction change, which uses should be restricted and which checks must be repeated? 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.
Reported evidence
Findings from the breadth pass, kept separate from the structural claims.
Kinds and varieties
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- source program
- object or executable (binary) program
- application program
- system program (kernel, driver, utility)
- script (interpreted automation or glue)
- firmware
- embedded or real-time program
- concurrent or distributed program
- Which of these kinds and varieties hold for the sense of program this model covers, and on what evidence? provenance
Identifiers and schemes
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Wikidata - Q40056 - Item for computer program in the computer-science sense.
- CPE 2.3 - cpe:2.3:a:<vendor>:<product>:<version>:*:*:*:*:*:*:* - NIST Common Platform Enumeration for named application programs as products.
- Package URL (PURL) - pkg:<type>/<namespace>/<name>@<version> - Cross-ecosystem locator for packaged programs and libraries (npm, Maven, PyPI, and others).
- Software Heritage SWHID - swh:1:(cnt|dir|rev|rel|snp):<hash> - Content-addressed identifier for source artifacts of programs archived by Software Heritage.
- Which of these identifiers and schemes hold for the sense of program this model covers, and on what evidence? provenance
Standards and regulation
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- ISO/IEC 2382 Information technology - Vocabulary (ISO/IEC)
- ISO/IEC/IEEE 24765 Systems and software engineering - Vocabulary (ISO, IEC, IEEE)
- ISO/IEC 12207 Software life cycle processes (ISO/IEC)
- ISO/IEC 25010 Systems and software Quality Requirements and Evaluation - product quality model (ISO/IEC)
- Directive 2009/24/EC on the legal protection of computer programs (European Union)
- Berne Convention for the Protection of Literary and Artistic Works, as applied to software as a literary work (WIPO)
- IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems (IEC), for safety-related programs
- Which of these standards and regulation hold for the sense of program this model covers, and on what evidence? provenance
Real-world use
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Installed and launched as applications on phones, desktops, and servers.
- Built from source in continuous-integration pipelines and shipped as binaries, packages, or container images.
- Loaded by an operating system as one or more processes with an entry point.
- Resident in non-volatile memory of microcontrollers in vehicles, appliances, and medical devices.
- Run as long-lived network services behind APIs.
- Published as source repositories that others clone, fork, and rebuild.
- Which of these real-world use hold for the sense of program this model covers, and on what evidence? provenance
Typical measurements
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- source size (lines of code) - 10-10 000 000 - lines
- installed binary size - 1 KiB-10 GiB - bytes
- cyclomatic complexity per routine - 1-50 typical; higher values are treated as a maintainability risk - McCabe complexity
- resident memory of a running instance - tens of KiB (embedded) to several GiB (desktop/server applications) - bytes
- execution duration - microseconds (short tools) to unbounded (services and embedded controllers) - seconds
- Which of these typical measurements hold for the sense of program this model covers, and on what evidence? provenance
Failure modes and hazards
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Defects that produce wrong results while the program still terminates.
- Abnormal termination (crash, unhandled exception, panic).
- Non-termination (infinite loop or deadlock).
- Resource leaks and exhaustion of memory, file handles, or other quotas.
- Security vulnerabilities in the program or its dependencies (injection, memory-safety errors, privilege escalation).
- Supply-chain compromise of source, build tools, or distributed binaries.
- Unsafe behaviour when the program is used to control physical processes (avionics, medical, industrial control).
- Malicious programs (malware) written to harm systems or data.
- Which of these failure modes and hazards hold for the sense of program this model covers, and on what evidence? provenance
Regional variation
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- In computing usage, both British and American English write program; British English reserves programme for events and broadcasts.
- Copyright is the default worldwide protection (Berne; EU Software Directive; national copyright acts); patentability of computer-implemented inventions differs sharply between the EPO and the USPTO.
- Some cryptographic and dual-use programs are export-controlled (for example US EAR and the Wassenaar Arrangement), so distribution practice is jurisdiction-dependent.
- Locale, character encoding, and decimal/date conventions change source text, identifiers, and the observable I/O of the same program.
- Which of these regional variation hold for the sense of program this model covers, and on what evidence? provenance
Neighbouring kinds and how to tell them apart
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- algorithm - An algorithm is an abstract procedure independent of any particular encoding; a program is a concrete encoding that a machine can interpret or execute.
- software - Software is the broader product (one or more programs plus data, configuration, and often documentation); a program is the instruction sequence itself.
- process - A process is a running instance of a program with state and resources; the program is the static artifact from which that instance is created.
- library or module - A library is reusable code meant to be called; it is a program only when it also has a standalone entry point that a machine can launch.
- script - A script is a program written to be interpreted, often for automation; every script is a program, but compiled binaries and firmware are programs that are not scripts.
- firmware - Firmware is a program stored in a device's non-volatile memory and bound to that hardware; not every program is firmware.
- source code - Source code is the textual form of a program; the same program may also exist only as object code or as a loaded image.
- instruction - An instruction is a single executable step; a program is a finite sequence of such steps (plus data definitions) that together specify a computation or control task.
- Which of these neighbouring kinds and how to tell them apart hold for the sense of program this model covers, and on what evidence? provenance
Sources
- IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990) - Classic engineering definition of a computer program as instructions plus data definitions that enable hardware to perform computational or control functions; later folded into ISO/IEC/IEEE 24765.
- Systems and software engineering - Vocabulary (ISO/IEC/IEEE 24765) - Current consensus vocabulary for program, software, and related software-engineering terms used in the kinds, neighbours, and standards fields.
- Information technology - Vocabulary (ISO/IEC 2382) - IT vocabulary treating a program as a syntactic unit of a programming language composed of the declarations and statements needed to perform a function or solve a problem.
- Directive 2009/24/EC on the legal protection of computer programs - EU legal characterisation of a computer program as a literary work (including preparatory design material) and the copyright regime that governs it in the Union.
- Wikidata item Q40056 (computer program) - Stable public identifier and alias set for the computer-science sense of program.
What the second pass must settle
- Does the registry treat libraries, individual functions and hosted scripts as programs in their own right, or as components unless separately registered?
- What identity rule should relate source code, compiled artifacts and modified revisions to one program rather than separate registered things?
- Where should this registry place declarative queries, configuration with executable expressions and dynamically generated instructions at the program-data boundary?
- Which neighbouring models own dependency packages and running processes, and what references should connect them to this model?
- What evidence threshold should justify readiness for a particular use when dependencies, environmental behaviour or effects remain only partially characterised?