Skip to content

Section 32: Process Execution and Operating System Interaction

TECHSPEC-32 — Section 32 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Operating System Philosophy

Interactions with the operating system must be explicit, permission-controlled, and observable.

The language must prevent AI agents from accidentally executing unauthorized commands, exposing sensitive environment data, or creating uncontrolled processes.

External process execution must never be treated as an ordinary function call.

2. Process Effects

Operating system interactions must declare their effects.

Supported effects include:

  • PROCESS.CREATE: Start a new process.
  • PROCESS.TERMINATE: Terminate a process.
  • PROCESS.INSPECT: Retrieve process information.
  • PROCESS.SIGNAL: Send a signal or control instruction.
  • SYSTEM.ENVIRONMENT: Access environment variables.
  • SYSTEM.CONFIGURATION: Read or modify system configuration.
  • SYSTEM.IDENTITY: Access operating-system identity information.

Effects must propagate through the call graph.

3. Explicit Process Execution

External programs must be launched through a dedicated standard-library API.

Example:

FUNCTION runCompiler(
    sourceFile: FilePath
) -> Result<ProcessResult, ProcessError>

    REQUIRES: sourceFile.exists
    EFFECTS: PROCESS.CREATE, PROCESS.INSPECT

    RETURN Process.execute(
        executable: "/usr/bin/compiler",
        arguments: ["build", sourceFile]
    )

END FUNCTION

This example is illustrative. The final process API and argument syntax remain to be defined.

Rules: - Executable paths must be explicit or resolved through a documented mechanism. - Arguments must be passed as structured values. - Shell interpretation must not occur implicitly. - Process execution requires explicit permission. - Executable identity and provenance should be recorded where available. - Working directory and environment inheritance must be explicit.

4. Command Injection Prevention

The language must discourage unsafe construction of executable commands.

Rules: - Arguments must be passed separately from executable names. - Untrusted input must not automatically become executable code or shell syntax. - Shell execution must require a separate explicit API and permission. - Dynamic command construction must undergo appropriate validation. - Escaping must be specific to the execution context. - The compiler should flag unsafe shell construction where detectable.

5. Process Lifecycle

Every created process must have a defined lifecycle.

Rules: - Processes must have identifiable owners. - Process handles must follow ownership and resource-lifetime rules. - Processes must be awaited, monitored, or explicitly detached. - Detached processes require separate authorization. - Cancellation and termination behavior must be defined. - Process cleanup must be attempted on applicable failure paths. - The runtime must not silently abandon owned processes.

6. Process Results

Process execution must return structured information.

A process result should distinguish:

  • Whether process creation succeeded.
  • Whether execution started.
  • Whether execution completed.
  • Exit status.
  • Standard output.
  • Standard error.
  • Termination reason.
  • Timeout or cancellation.
  • Whether the final outcome is known.

Rules: - A process starting successfully does not imply successful completion. - Exit status must be interpreted according to the executable's documented behavior. - Standard output must not automatically be treated as trustworthy. - Process failures must remain observable. - Incomplete execution must not be reported as successful completion.

7. Environment Variables

Environment access must be explicit.

Rules: - Reading environment variables requires declared permission. - Missing variables must produce an explicit result. - Environment values must be treated as untrusted input. - Secret environment values must be protected from ordinary logging. - Modifying environment variables must declare its scope. - Child processes must not inherit sensitive environment values automatically.

8. System Permissions

Operating system permissions must follow least-privilege principles.

Rules: - Access to system resources must be declared. - Administrative privileges require separate authorization. - Process execution permissions must be scoped where possible. - System configuration changes require explicit permission. - Permissions must not be inherited automatically by unrelated dependencies. - Permission checks must occur at the point of access.

9. Resource Limits

Processes consume operating system resources.

The runtime should support documented limits for:

  • Execution time.
  • Memory.
  • CPU usage.
  • Number of child processes.
  • Output size.
  • Open file handles.
  • Concurrent process count.

Resource exhaustion must produce observable failures where recoverable.

10. Compiler and Runtime Responsibilities

The compiler and runtime must: - Enforce declared process and system effects. - Require explicit process permissions. - Track process ownership and lifecycle. - Prevent accidental shell interpretation. - Enforce structured argument handling. - Protect sensitive environment values. - Report process outcomes accurately. - Detect abandoned owned processes where possible.

11. Verification Limitations

The language cannot guarantee that an external executable is safe, correct, or free from vulnerabilities.

Verification reports must distinguish:

  • Process permission declared.
  • Permission granted.
  • Process creation attempted.
  • Process successfully started.
  • Process completed.
  • Exit status received.
  • Expected output validated.
  • External behavior not independently established.

A successful exit status does not prove that the executable performed its intended task correctly.

12. Design Goal

An AI agent must be able to determine exactly which external programs a system can execute, what permissions they require, what resources they consume, and what is actually known about their execution.

Operating system access must never be an invisible or unrestricted capability.

Source file: TECHSPEC-32.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.