Section 9: Side Effects and Permissions¶

TECHSPEC-09 — Section 9 · 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. Permission Philosophy¶

Every function must explicitly declare the external effects it may perform.

The language must distinguish between what a function is technically capable of doing and what it is authorized to do.

Undeclared effects must be rejected.

2. Effect Categories¶

The initial language defines these effect categories:

• READ: Read program state or external data.
• MODIFY: Change existing program state.
• CREATE: Create new data or resources.
• DELETE: Remove data or resources.
• FILESYSTEM: Access files and directories.
• NETWORK: Communicate with external systems.
• DATABASE: Read from or modify databases.
• SYSTEM: Interact with operating-system resources.
• TIME: Access clocks, timers, or time-based services.
• PROCESS: Start, stop, or manage processes.

More specific effect categories may be introduced as the standard library develops.

3. Effect Declarations¶

Functions must declare every effect they may perform.

Example:

```text id="d1q4st" FUNCTION saveReport( report: Report ) -> Result

EFFECTS:
    FILESYSTEM
    CREATE

IMPLEMENTATION:
    RETURN FILE.WRITE("report.txt", report)

END FUNCTION

Rules:
- Effects must be declared in the function signature or contract.
- Calling a function with effects requires the caller to account for those effects.
- A function cannot perform undeclared effects.
- Effects from called functions must be included in the caller's effective effect set.
- Declared effects do not prove that the operation is authorized.

## 4. Permissions and Authorization

Permissions determine whether a function may perform a declared effect.

Example:

```text id="t2v8la"
PERMISSIONS:
    FILESYSTEM.WRITE("reports/")
    NETWORK.CONNECT("api.example.com")

Rules: - Permissions must be explicitly granted. - Permissions should follow the principle of least privilege. - Permissions must be limited to the required resource or operation where possible. - A dependency cannot automatically inherit the permissions of its caller. - Runtime authorization must be enforced when the environment controls access. - Revoked permissions must not be treated as valid.

5. Permission Boundaries¶

External systems and resources must be treated as separate trust boundaries.

Examples include: - Files outside the application's managed directory. - Remote servers and APIs. - Databases. - Operating-system services. - User accounts and credentials. - Other processes.

Rules: - Crossing a permission boundary requires authorization. - External input must be validated before being trusted. - Credentials must not be exposed through ordinary program output. - Permission failures must produce explicit errors. - A declared permission must never be presented as proof that access succeeded.

6. Effect Propagation¶

Effects must be tracked across function calls.

Example:

```text id="m4g7pk" FUNCTION generateReport() -> Result

EFFECTS:
    FILESYSTEM
    DATABASE

IMPLEMENTATION:
    LET records = loadRecords()
    LET report = buildReport(records)
    RETURN saveReport(report)

END FUNCTION ```

Rules: - The compiler must inspect effects of called functions. - A caller must account for all effects that can occur through its call chain. - Conditional execution does not remove an effect from the function's possible effect set. - Unresolved or unknown effects must not be silently treated as harmless.

7. Compiler Responsibilities¶

The compiler must: - Verify declared effects against function implementations. - Track effects across function calls. - Reject undeclared effects. - Validate permission declarations. - Detect unauthorized access where statically possible. - Preserve runtime authorization checks where static validation is insufficient. - Report declared, inferred, and actually exercised effects separately.

8. Design Goal¶

AI agents must know exactly what a function can affect, what it is authorized to access, and which operations require runtime permission checks.

The language must never confuse declared capability, granted permission, and successful execution.

Source and related sections¶

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