The Input Machine

The Input Machine is the mandatory ingest gate through which all documents and text enter os-console workflows. It occupies the F12 key slot permanently across all keyboard configurations. Every cartridge in os-console depends on the Input Machine for its source material. No workflow bypasses it.

[edit]Why the position is permanent

F12 occupies the boundary position on the function-key row, physically separated from F1–F11 by a wider gap on most keyboards. This positioning is deliberate. The Input Machine is not a workflow feature; it is a boundary control. It must be immediately and unambiguously locatable regardless of which cartridge is currently active.

System architecture decision SYS-ADR-10 establishes F12 as the mandatory human checkpoint for all ingest operations. The assignment cannot be bypassed by another pane and cannot be remapped. These constraints are enforced in the `app-console-keys` event dispatcher rather than by convention.

[edit]What happens when F12 is pressed

Pressing F12 at any point in os-console suspends the currently-active cartridge and opens the Input Machine modal. The operator completes the ingest workflow. The cartridge then resumes.

The ingest workflow runs as follows:

1. A modal presents the file path input field.
2. The operator enters and confirms the path. Passive submission is not accepted — explicit confirmation is required.
3. The Input Machine validates that the file exists and is readable.
4. The validated file is sent to service-input on the Totebox Archive.
5. service-input classifies the document and determines the routing target.
6. service-input routes the document to the appropriate service — for example, to service-proofreader for editorial content or to service-fs for archiving.
7. An immutable audit log entry is written: timestamp, file path, classification, routing target, and operator identity.
8. The active cartridge resumes with the ingested document available in its context.

[edit]service-input: the Ring 1 boundary service

service-input is a Ring 1 service in the Three-Ring Architecture — a per-tenant boundary ingest service that handles generic document ingestion. It is the server-side counterpart of the Input Machine cartridge.

Ring 1 placement means service-input is per-tenant, a data-ingest boundary through which data flows in but never out, and an MCP server implementing the Model Context Protocol boundary.

service-input performs three functions: classify the document type and appropriate processing pipeline; route the document to the correct Ring 2 or Ring 1 service; and write an immutable record of the ingest event to the ledger.

service-input performs no AI inference. Classification uses deterministic rules per SYS-ADR-07, which states that structured data does not pass through AI inference. This ensures the audit trail is reproducible and not dependent on model availability.

[edit]The audit trail

Every document that passes through the Input Machine generates two audit trail entries.

A local SQLite log on the os-console machine records the timestamp, file path, classification, and routing target. This local record persists even if the Totebox Archive is unreachable.

A canonical record in the service-input ledger on the Totebox Archive is written as an immutable append. Together these entries ensure that every document that entered a workflow is logged with when it arrived, how it was classified, where it was sent, and who submitted it. This dual-entry approach mirrors the WORM ledger discipline used across the platform.

[edit]The app-console-input cartridge

app-console-input is the F12 cartridge crate in pointsav-monorepo. It implements the Input Machine workflow on the os-console client side: it renders the file path input modal, sends the POST to service-input on the Totebox Archive with a 30-second timeout, writes the local SQLite audit entry, and returns control to the previously-active cartridge after ingest completes.

app-console-input is always installed and the modal is always reachable via F12. This is not configurable.

[edit]ADR-07 compliance

SYS-ADR-07 states that no structured data passes through AI inference. The Input Machine enforces this at the ingest boundary. service-input's classification is deterministic — it uses file extension, MIME type, and structural signatures. Given the same file, service-input always produces the same classification. The audit record is not dependent on model versions or inference availability.

[edit]The Zero-Form architecture

The Input Machine is the foundation of what operational documentation describes as the Zero-Form architecture. Traditional document workflows require forms — the operator fills in fields to contextualize a document before it enters a system. The Input Machine inverts this: the operator provides a document and the system classifies, routes, and contextualizes it automatically. The only input required is the document itself and an explicit confirmation of intent to submit.

Explicit confirmation is a compliance design choice. It means the audit trail reflects a deliberate human decision, not an accidental submission.

[edit]Routing across cartridges

Each cartridge uses the Input Machine for its source material. The routing decision — which cartridge receives the document after ingest — is made by service-input based on classification, not by which cartridge was active when F12 was pressed.

• F4 (Content): submitted documents become the source text for proofreading or draft generation.
• F5 (Minutebook): meeting notes and resolution documents are processed by the governance workflow.
• F6 (Bookkeeper): financial documents enter the ledger pipeline.
• F7 (BIM): IFC model files are routed to service-bim.

[edit]See also

• console-os — the platform context for the Input Machine
• machine-based-auth — the authorization mechanism os-console uses
• three-ring-architecture — service-input Ring 1 placement
• os-console-platform — the cartridge architecture and F-key map
• worm-ledger-design — the append-only ledger discipline for audit records