The Function11 Manual

fn — The Completed U*IX

1. Overview

Function11 (fn) is a minimalist operating shell and control system designed for:

• secure system administration,
• human–AI collaboration,
• elimination of supply-chain risk,
• complete transparency of execution.

fn replaces:

• traditional shells,
• Model Context Protocol (MCP),
• opaque AI tool-calling systems,

with a single, file-oriented, command-driven environment inspired by UNIX, Plan 9, and early X systems.

Function11 is not a framework. It is not a package ecosystem. It is a system substrate.

2. Core Principles

Function11 obeys five axioms:

1. Everything is a command
2. Every interface is a filesystem
3. State is inspectable
4. Execution requires approval
5. Discovery replaces configuration

If a feature violates these axioms, it does not belong in fn.

3. System Model

3.1 The Kernel

The fn kernel is a long-lived Node.js process that:

• maintains sessions,
• enforces approval,
• dispatches commands,
• exposes a virtual filesystem.

The kernel does not:

• manage users,
• enforce permissions,
• auto-execute AI output,
• hide state.

3.2 Sessions

Each connection to fn creates a session.

A session has:

• its own namespace,
• its own /proc,
• its own approval state,
• isolated command execution.

Sessions are namespaces, not users or processes.

4. Filesystem Layout

Function11 exposes a virtual filesystem rooted at /.

/
├─ bin/        Executable commands
├─ man/        Command manuals
└─ proc/       Runtime control and state

Nothing exists outside this structure.

5. /bin — Commands

5.1 Command Definition

Each command is a JavaScript ESM module exporting:

export const meta = {
  name,
  description,
  approval
};

export async function run(ctx) {}

Commands:

• are discoverable via ls /bin
• document themselves via man
• may request approval
• may expose streams or filesystems

5.2 Command Composition

Commands may:

• pipe output to other commands,
• mount filesystems,
• expose streams,
• request privileged execution.

There are no hidden APIs.

6. /man — Documentation

Each command has a corresponding manual:

/man/<command>.md

The man command renders these files.

Manuals are:

• human-readable,
• AI-readable,
• authoritative.

If a command lacks a manual, it is incomplete.

7. /proc — Control Surfaces

/proc is the primary control and introspection interface.

It is bidirectional.

7.1 /proc/self

Session-scoped control.

/proc/self/
├─ status     Session state
├─ approve    Approval gate
├─ stdin      Input stream
├─ stdout     Output stream
└─ kill       Terminate session

A session always has access to its own /proc/self.

7.2 /proc/sys

Global system state.

/proc/sys/
├─ uptime
├─ loglevel
└─ sessions

Writes to /proc/sys affect the kernel globally.

8. Approval System

8.1 Purpose

No command may:

• execute host commands,
• run containers,
• modify the system,

without explicit approval.

Approval is not a prompt. It is state.

8.2 /proc/self/approve

Read

cat /proc/self/approve

Outputs:

• idle if no request is pending
• otherwise, a structured approval request

Write

echo yes > /proc/self/approve
echo no  > /proc/self/approve

Resolves the request.

Approval is:

• session-scoped,
• blocking,
• auditable,
• impossible to bypass.

9. Human Interaction

9.1 Interactive Shell

Humans interact with fn via:

./fn --interactive

The shell:

• uses readline,
• supports pipelines,
• resolves commands via /bin,
• reads state via /proc.

The shell is not special. It is just a client.

10. AI Interaction

10.1 AI as a Client

AI systems interact with fn exactly as humans do.

They may:

• list commands,
• read manuals,
• inspect /proc,
• propose actions.

They may not:

• self-approve,
• bypass /proc/self/approve,
• invent commands.

10.2 AI Discovery Model

AI learns capabilities by:

ls /bin
man <command>
ls /proc

No tool schemas. No MCP. No prompt engineering.

11. Security Model

Function11 achieves security by:

• eliminating dependency chains,
• removing hidden execution paths,
• enforcing approval structurally,
• making state visible.

There are:

• no background privileges,
• no implicit trust,
• no invisible side effects.

12. Design Lineage

Function11 draws directly from:

• UNIX — composability and text streams
• Plan 9 — namespaces and file interfaces
• Inferno — supervised concurrency
• Early X — minimalism and pixel clarity

It intentionally rejects:

• package ecosystems,
• opaque tooling,
• global mutable state,
• cloud-dependent AI systems.

13. What Function11 Is Not

• Not a package manager
• Not an AI agent framework
• Not a container platform
• Not a desktop environment (yet)

It is the substrate those things may rest upon.

14. Status

Function11 is:

• conceptually complete,
• incrementally implementable,
• hostile to supply-chain attacks,
• legible to both humans and AI.

Everything beyond this manual is refinement, not reinvention.

Closing Note

Function11 does not attempt to be clever.

It attempts to be honest.

Honest systems are inspectable. Inspectable systems are secure. Secure systems can trust AI.

That is the point of fn.