Console input application

@@ -7,12 +7,12 @@ type: app
content_type: topic
quality: complete
index_group: input-and-developer-surfaces
short_description: "app-console-input is the F12 surface in os-console — the structured input gate through which raw external files enter a Totebox before being sealed into the verified ledger."
short_description: "app-console-input is the F12 surface in os-console — a path, a confirm prompt, and a submission, through which raw external files enter a Totebox before being sealed into the verified ledger."
status: active
audience: vendor-public
bcsc_class: public-disclosure-safe
language_protocol: PROSE-TOPIC
last_edited: 2026-05-15
last_edited: 2026-08-22
editor: pointsav-engineering
paired_with: app-console-input.es.md
cites:
@@ -27,63 +27,42 @@ references:
    url: "https://www.iso.org/standard/82875.html"
---

`app-console-input` is the F12 surface in [[console-os|os-console]] — the only path through which raw external files enter a [[totebox-os|Totebox]] before being sealed into the [[worm-ledger-design|WORM ledger]]. The surface routes every incoming document through a structured human verification step, holding the operator accountable for each [[service-extraction|extracted]] claim before it advances to verified status. Unlike a [[service-slm|language model]] interface or autosave pipeline, it presents binary choices — the system proposes, the operator confirms or rejects — so every fiduciary decision carries an operator signature in the [[worm-ledger-design|audit trail]]. By the end of this article, a reader will understand the F12 workflow, the Verification Surveyor pattern, and the audit properties the gate enforces.
`app-console-input` is the F12 surface in [[console-os|os-console]] — the only path through which raw external files enter a [[totebox-os|Totebox]] before being sealed into the [[worm-ledger-design|WORM ledger]]. The surface holds the operator accountable for every file that enters the ledger: nothing is submitted without an explicit, keyboard-confirmed operator decision, so every fiduciary act carries an operator signature in the [[worm-ledger-design|audit trail]]. By the end of this article, a reader will understand the F12 workflow and the audit properties the gate enforces.

## How the F12 session unfolds

**Correction (2026-08-02):** the 5-step table below does not match the real cartridge. Real `InputState` (`app-console-input/src/cartridge.rs`) is a simple `Entry → Confirm{path} → Submitting → Done/Error` flow — free-text file-path entry, confirm, single HTTP POST — with no Chart of Accounts routing step, no per-claim entity/theme Yes/No verification UI, and no drag-and-drop (the real widget is a text `PathInput`; a drag-drop mockup exists only in an unused static HTML file, never wired into the shipped TUI). The real POST (`ingest.rs`) sends only `{path, submitted_by, tenant, source}` — no entity-review payload. This is the same general shape of fabrication already found on `security/verification-surveyor.md` (2026-07-30) — a detailed human-in-the-loop workflow invented for a different real service — though the specific claims differ. **Flagged, not resolved.**

A typical F12 session has a deterministic five-step shape. Each step has a clear boundary; the operator does not skip forward or batch decisions.
A session moves through four states in order: **Entry**, where the operator types the file's path; **Confirm**, a single yes/no prompt showing the exact path back; **Submitting**, while the cartridge posts to the ingest endpoint and waits; and **Done** (or **Error** on failure). Cancelling from Entry or Confirm returns to Entry with nothing submitted.

| Step | Operator action | System response |
|---|---|---|
| 1 | Drag a file from the desktop into the F12 window | The system computes a content hash and strips execution permissions |
| 2 | Select a category from the [[archetypes-and-chart-of-accounts|Chart of Accounts]] (Profile → Domain → Sub-Domain) | The system prepares a routing destination |
| 3 | Review the entities and themes the system pre-extracted via [[service-extraction]] and [[service-content]] | The system displays a Yes / No verification prompt for each claim |
| 4 | Approve or reject each claim with single keystrokes | Approved claims advance to L5 verified status; rejected claims are quarantined |
| 5 | Confirm the routing destination | The file is sealed into service-minutebook or service-bookkeeper; a ledger entry is written; the [[worm-ledger-design|audit log]] captures the operator identity, timestamp, and routing decision |

### Sequential discipline and per-claim audit granularity

The interaction is keyboard-only and intentionally fast. The operator does not type filenames, fill out metadata forms, or compose database queries. [[service-extraction]] and [[service-content]] have already done the computational work; the operator's role is to verify or reject each claim in sequence, then confirm the destination.

This sequential structure is deliberate. Bundling multiple steps into a single confirmation would reduce the resolution of the [[worm-ledger-design|audit trail]] — each claim would inherit the same timestamp rather than carrying its own decision record. The five-step gate preserves per-claim audit granularity.

## The Verification Surveyor pattern — binary choices over open forms

The F12 interaction model is sometimes described as the Verification Surveyor: rather than presenting the operator with a blank form, the system presents a binary choice — "I extracted this fact; is it correct? Yes or No." [^1]

The pattern has three properties:

| Property | Effect |
|---|---|
| Low cognitive load | The operator processes a stream of Yes/No decisions rather than authoring structured data |
| Fiduciary clarity | Every claim that enters the verified ledger carries an explicit operator decision, not a system default |
| Audit completeness | The [[worm-ledger-design|audit record]] captures the exact decision on each claim, not only the final routing destination |
| Entry | Type a file path | The cartridge accepts free-text path entry |
| Confirm | Press Y to submit, N or Esc to cancel | The cartridge shows the exact path back for a final yes/no decision |
| Submitting | Wait | The cartridge posts the file's path, the operator's identity, and the tenant to the ingest endpoint over HTTP |
| Done | — | The cartridge records the result — success, a warning, or an error — to a local audit log, and extends a local rolling ledger with the submission |

### Boundary between platform and operator
### Every submission is signed and chained

This model reflects a deliberate boundary between platform and operator. [[service-extraction]] and [[service-content]] handle entity detection, theme classification, and routing suggestion. The operator handles the binary gate. Institutions subject to continuous-disclosure obligations [ni-51-102] [osc-sn-51-721] and electronic-record standards [^2] can point to a specific, timestamped operator decision for every document that enters the verified ledger.
The interaction is keyboard-only and deliberately narrow: one path, one confirmation, one submission. There is no bulk-import mode and no metadata form — a document is either submitted through this exact sequence or it never enters the ledger.

The pattern differs from AI-assisted autofill, where a model populates fields and the operator accepts by omission. In F12, silence is never acceptance. Every claim that advances to verified status requires an explicit affirmative keystroke from the operator.
Two audit trails record every submission, not one. Locally, the cartridge maintains a rolling hash — each successful submission's ledger entry is chained onto the previous one (`new_root = SHA256(prior_root ‖ payload_id)`), so the local sequence of submissions is independently verifiable end to end, entry by entry. The cartridge also writes a local audit record — timestamp, operator, tenant, path, ledger reference, and outcome — viewable at any time from the Entry screen. Separately, the file itself is appended to the platform's ledger service, which returns its own ledger reference back to the cartridge.

## Why the verification step is architecturally mandatory
## Why the confirm step is architecturally mandatory

If [[service-extraction]] or [[service-content]] were to route a source document into the wrong account without human confirmation, the downstream verified ledger would carry a mathematically compromised entry from that point forward. Re-sorting the document later does not repair the audit trail — the original entry already carries a verification timestamp that records a decision no human made.
If a file entered the ledger without an operator explicitly confirming it, the ledger would carry an entry with no accountable human author from that point forward. There is no later step that repairs this: the entry already carries a timestamp asserting a decision no human made.

### Architectural decisions enforcing the gate

[[architecture-decisions|SYS-ADR-10]] makes F12 mandatory precisely because this failure mode is structural, not probabilistic: any architecture that delegates the final routing decision to an automated system creates a ledger entry without an accountable human author. [[architecture-decisions|SYS-ADR-07]] extends the principle to structured data more broadly — no AI-produced record enters a verified ledger without a human confirmation step. [[architecture-decisions|SYS-ADR-19]] closes the remaining path — no automated publishing to verified ledgers, regardless of confidence score.
[[architecture-decisions|SYS-ADR-10]] makes F12 mandatory precisely because this failure mode is structural, not probabilistic: any path that lets a file reach the ledger without an explicit operator confirmation creates an unaccountable entry. [[architecture-decisions|SYS-ADR-07]] extends the principle to structured data more broadly — no AI-produced record enters a verified ledger without a human confirmation step. [[architecture-decisions|SYS-ADR-19]] closes the remaining path — no automated publishing to verified ledgers, regardless of confidence score.

Institutional fiduciaries — asset managers, lawyers, regulated financial entities — require an audit trail they can defend under examination. The F12 gate is what makes that defense possible: every entry in service-minutebook and service-bookkeeper traces to a specific operator, a specific decision, and a specific timestamp. [^2]
Institutional fiduciaries — asset managers, lawyers, regulated financial entities — require an audit trail they can defend under examination. The F12 gate is what makes that defense possible: every submission traces to a specific operator, a specific confirmation, and a specific timestamp. [^2]

## What the F12 surface is not

F12 is not a chat interface. The operator does not compose queries or converse with [[service-slm|the language model]]. The surface is structured: a file, a [[archetypes-and-chart-of-accounts|Chart of Accounts]] selection, a sequence of binary prompts, and a confirmation. All language-model work occurs upstream in [[service-extraction]] and [[service-content]] before the F12 session begins; the operator never sees raw model output.
F12 is not a chat interface. The operator does not compose queries or converse with [[service-slm|the language model]] — there is no model in this loop at all. The surface is a fixed sequence: a path, a yes/no confirmation, and a submission.

F12 is not an autosave surface. A document enters the [[worm-ledger-design|WORM ledger]] only when the operator explicitly confirms the routing destination. This protects the audit trail from partial writes and abandoned sessions. Drafts in progress do not accumulate in the ledger; a document only lands when the operator reaches step five and confirms.
F12 is not an autosave surface. A file enters the ledger only when the operator explicitly presses Y at the confirm prompt. Cancelling at any point before that leaves nothing recorded.

F12 is not a bulk-import interface. The operator may have a queue of documents to process, but each passes through the five-step gate individually, producing a distinct audit record per document. The sequential constraint is not a throughput limitation — it is an audit discipline. [[architecture-decisions|SYS-ADR-10]] is unambiguous on this point: the F12 boundary is mandatory per document.
F12 is not a bulk-import interface. The operator may have several files to submit, but each passes through the full path→confirm→submit sequence individually, producing its own audit record. The one-file-at-a-time constraint is not a throughput limitation — it is an audit discipline. [[architecture-decisions|SYS-ADR-10]] is unambiguous on this point: the F12 boundary is mandatory per file.

## See also

@@ -91,7 +70,5 @@ F12 is not a bulk-import interface. The operator may have a queue of documents t
- [[architecture-decisions|SYS-ADR-10]] — the architectural decision mandating F12 as the required input gate
- [[architecture-decisions|SYS-ADR-19]] — the architectural decision prohibiting automated publishing to verified ledgers
- [[console-os|os-console]] — the operating system that hosts the F12 surface
- [[service-extraction]] — the upstream entity and theme extraction engine
- [[service-content]] — the upstream classification and routing engine
- [[worm-ledger-design]] — the design principles behind the WORM ledger substrate
- [[machine-based-auth]] — the authentication layer that ties ledger entries to verified operator identity