Product Mechanics: Commands, Files, Records, and Reconstruction

1. Product mechanics are semantic custody

On a personal device, AIOS begins with familiar objects: notes, research, drafts, plans, folders, and commands. A person opens or creates a file, invokes a named movement, receives a judgment or proposed change, inspects what will happen, and leaves behind an artifact, companion metadata, lineage, and an operation receipt. The machinery is valuable only if those ordinary acts preserve the system’s larger relationships among purpose, evidence, authority, action, and renewal.

One person may maintain several self-contained domain knowledge systems—for example, research, professional practice, health, education, or a private creative project—each with its own sources, vocabulary, standing, permissions, and model-routing policy. The mechanics described here operate within the active domain and cross between domains only through explicit disclosure, import, and acceptance boundaries.

The application layer is not a neutral afterthought. It determines whether a semantic judgment:

• receives the intended context;
• remains separate from mechanical vocabulary;
• lands in the correct artifact;
• waits for person authorization;
• survives process termination and reload;
• becomes legitimate future ground;
• can be traced, corrected, and superseded.

The central product-design problem is therefore semantic custody: machinery must carry meaning accurately without quietly becoming the author of meaning.

This chapter is where the preceding architecture becomes executable. Promotion defines which results may become future ground; the Atlas projects relationships and effects; and epistemic maintenance defines how accepted ground changes. Product mechanics must implement those meanings without collapsing proposal, authorization, execution, acceptance, and truth into one event.

2. One end-to-end composition

Watch the proposal remain inert until the target and revision are resolved and authority and preconditions pass. Execution is followed by post-state verification, receipt, standing, and reintegration; the final reload tests whether transient state ever acted as hidden authority.

Every transition has an owner and a failure condition. No successful model call, parser result, file save, interface screenshot, or isolated test proves the whole composition by itself.

3. Closed actions rather than ambient inference

The governing interaction pattern is a closed action:

1. a person acts, or a previously authorized bounded event occurs;
2. one capability owner admits the work;
3. declared sources are read;
4. a purpose-shaped context is composed;
5. a semantic judgment is requested;
6. the result lands with explicit standing;
7. structure, semantic fit, target identity, and authority are evaluated separately;
8. the exact proposed effect is rendered from the resolved target and revision;
9. effects remain inert unless authorized;
10. execution, post-state verification, and receipts settle;
11. acceptance and reintegration occur where the effect changes governing ground;
12. the interface projects the resulting state.

This avoids passive semantic watchers that constantly infer what a person “must mean” from every edit. Background services may detect mechanical facts—file changes, invalid syntax, stale hashes—but semantic consequences require an admitted capability and an authority path.

These are complementary layers, not competing models of the application. The substrate can observe, synchronize, validate, and reconstruct declared state. Intelligence moves through that substrate when a bounded semantic movement interprets the situation, produces a judgment, or proposes a consequence. Mechanical observation does not become intent merely because it is current, and semantic judgment does not acquire operational authority merely because it is intelligent.

4. Commands are named entry points, not intelligence

Commands provide discoverable, testable entry points to capabilities such as:

• continue thinking;
• create or open a durable artifact;
• admit an existing artifact or source into declared local custody;
• run a named review;
• request a plan or workflow continuation;
• accept, defer, dismiss, or revise a recommendation;
• commission bounded delegated work;
• integrate a return;
• register or promote candidate knowledge;
• rebuild a derived registry;
• inspect lineage or impact;
• reconstruct current state.

A command should bind to one real owner. It should not route through a universal bridge that infers semantic intent from labels, keywords, or UI location.

The hub represents responsibility, not intelligence. Several parts of the interface may invoke the same capability, but they must resolve to the same owner and contract so source selection, landing, authorization, and evidence do not vary with the entry point.

The same capability may be invoked from several surfaces, but all surfaces should converge on the same owner and contract.

Admission is a representative closed action. The system may inspect enough mechanical information to render the object, intended custody operation, destination, provenance treatment, and expected consequences. A person then authorizes the exact operation; deterministic software performs and verifies it; and the admitted object remains inactive until a later context-selection judgment finds it relevant. A model may optionally orient or summarize the object, but that semantic product remains separately governed and cannot decide whether the custody operation occurs.

5. Five validity layers and the trusted effect path

A well-formed model response can still be wrong in meaning, aimed at the wrong object, unauthorized, or incorrectly executed. AIOS therefore treats validity as five distinct questions:

The trusted path is therefore:

semantic proposal
  → structural validation
    → semantic review proportionate to consequence
      → canonical target and version resolution
        → trusted preview of the computed effect
          → authorization and precondition checks
            → exact execution
              → post-state verification and receipt
                → settlement of accepted standing and reintegration where required

No single layer can confer the validity of another. An authorized action can still serve the wrong purpose; a semantically excellent proposal can still lack permission; a receipt can faithfully document a harmful or mistaken change.

Separation of semantic and mechanical layers

The model should receive the intellectual situation, not internal paths, IDs, command names, parser vocabulary, or receipt formats unless those mechanics are themselves under analysis.

6. File classes and responsibilities

AIOS uses multiple complementary file classes.

Person-owned artifacts

Notes, documents, plans, drafts, decisions, and other objects people directly read and edit. These should remain clean and useful outside the application.

Companion metadata

Operational structure such as identity, epistemic standing, work and effect state, lineage, relationships, acceptance, and revision. It exists beside an artifact, not as a replacement for it.

Authored context documents or regions

Editorially composed natural-language ground for recurring kinds of judgment. They define what the model should understand, while a compiler determines the smallest complete selection for a particular call.

Prompt and role assets

Named cognitive movements and response contracts. Roles should specify the judgment required, not perform broad procedural ownership.

Assignment and return records

Bounded commissions, source lists, output contracts, authority limits, completion evidence, integration state, and unresolved questions.

Workflow and recommendation definitions

Reusable stages, guidance, accepts/produces relationships, follow-ons, menu relationships, and proposal semantics.

Derived registries and indexes

Rebuildable projections for navigation, impact, search, validation, and visualization. They are not parallel canonical sources or artifacts and do not independently acquire accepted standing; they must not write authority back into owner files.

Receipts and evidence

Records that an operation occurred, what it touched, what settled, and which verification was run. A receipt proves an event, not semantic quality.

Provenance has the same boundary. It establishes origin, transformation, identity, and lineage. It does not establish truth, adequate evidence, legitimate authority, or beneficial consequence.

7. Artifact and companion metadata

Where operational metadata would pollute a person-owned document, AIOS uses:

• a canonical artifact for human meaning and composition; and
• a companion metadata record for state, lineage, source relationships, workflow position, and machine-readable custody.

The pair must remain reconcilable. An orphaned companion metadata record, missing artifact, mismatched revision, or ambiguous canonical owner is an explicit failure—not an opportunity for silent repair.

8. Context compilation

The context compiler should:

1. receive an explicit purpose and requested cognitive movement;
2. resolve declared context sources;
3. check standing, scope, version, and meaningful absence;
4. select the smallest complete ground;
5. order it as an intelligible composition;
6. retain attribution and source descent;
7. disclose material loss when using compression;
8. keep implementation machinery outside ordinary model prose;
9. emit an inspectable record of what was used.

It must not rebuild context ad hoc at every call site. Caller-specific parallel capsules create semantic drift that is difficult to detect and impossible to govern consistently.

9. Response contracts and parsers

Response contracts can require fields such as:

• judgment or proposed continuation;
• rationale;
• assumptions;
• evidence or source references;
• uncertainty;
• alternatives;
• bounded effect proposal;
• follow-on options.

The parser may determine that required fields are present, types are valid, reference fields are well formed, and the response is safely bounded. A separate trusted resolver establishes canonical identity and version. Neither can decide that an argument is true, a recommendation is good, a document is complete, or a person has accepted an effect.

Structural validity is necessary and semantically weak.

10. Person authority and effect boundaries

The interface should distinguish:

• judgment — what the system presently concludes;
• proposal — a possible next movement;
• authorization — the person’s bounded permission;
• effect — the actual change performed;
• acceptance — the epistemic or intentional standing granted to the result;
• renewed ground — what becomes available to future reasoning.

Collapsing these stages makes fluent model prose act like an invisible command language. The system instead makes consequence explicit.

A result may be saved durably as an inert proposal, quarantined external return, rejected candidate, or historical record without becoming accepted future ground. Storage, indexing, registration, and interface visibility do not cross the memory-acceptance boundary described in Chapter 19.

For a consequential effect, the approval surface should be rendered from the resolved canonical target, its current revision, the exact parameters, and the computed delta—not from the model’s narrative description of what it intends to do. The authorization must bind to the same effect that executes. This keeps human authority practical rather than ceremonial.

11. Persistence, ordering, and concurrency

Durable movements require clear ordering:

1. validate the operation binding;
2. read current revisions;
3. perform bounded semantic work;
4. validate structural output;
5. review semantic fit at the level required by consequence;
6. resolve the exact target and confirm that source revisions have not changed incompatibly;
7. compute and render the proposed effect;
8. validate authority, policy, and preconditions;
9. execute the bounded effect;
10. verify post-state and write the result, companion state, and receipt;
11. wait for required writes to settle;
12. publish derived projections;
13. admit dependent continuations.

Concurrent changes should produce a visible collision, merge request, or retry path. The system must not let last-writer-wins behavior masquerade as semantic integration.

Ordinary files remain the preferred canonical semantic ground, but atomic multi-writer invariants may justify a narrowly scoped transactional operational store. When that exception is used, its ownership, synchronization, export, and reconstruction relationship to person-owned artifacts must be explicit. It must not quietly become the sole memory of purpose, knowledge, or authority.

12. Reconstruction is the test of durable state

A reconstructable system can terminate all transient processes and recover from a declared source snapshot and compatible readers:

• the current artifact revision;
• accepted and candidate ground;
• active plan or workflow stage;
• pending recommendations and their standing;
• assignments and unintegrated returns;
• source and decision lineage;
• authorized but incomplete effects;
• available next movements;
• meaningful errors or missing ground.

Everything downstream—interface, next context, and repair notices—comes from reconstructed state. Terminating transient processes should not alter that state; if reload differs, hidden session memory was acting as authority or a declared source is missing or incompatible.

Reload is therefore a continuity test. If the system looks correct before reload but reconstructs a different declared state afterward, transient state was acting as hidden authority. Reconstruction establishes recoverability of the recorded system state; it does not establish that the claims stored in that state are true.

13. Interface regions as projections of semantic state

The exact surface layout is replaceable, but several semantic regions recur:

• open thinking and inquiry;
• project direction, purpose, and plan;
• guided workflows and stage progression;
• writing and artifact composition;
• structural organization and relationship inspection;
• proposals, active work, returns, and accepted ground;
• memory, sources, lineage, and correction.

These regions are not separate minds. They are views onto the same distributed semantic situation, optimized for different movements.

14. Provider adapters and portability

The provider layer should translate a stable internal invocation contract into a model-specific API or local runtime:

• supported message and tool formats;
• context-window and token constraints;
• streaming behavior;
• structured-output mechanisms;
• retry and failure semantics;
• privacy and retention settings;
• model identity and version evidence.

Provider portability does not mean identical behavior across models. It means durable knowledge, authority, artifacts, and workflow definitions do not have to be surrendered to one model vendor. Adapters and evaluation are still required.

Local canonical files also do not imply that every inference is local. If a remote model receives composed context, that selected data leaves the device according to the provider’s technical and contractual controls. Honest sovereignty claims must distinguish local custody of durable state from local execution of every computation.

Model selection therefore occurs in two stages. First, a deterministic policy gate decides which routes are eligible given sensitivity, disclosure permission, jurisdiction, required tools, consequence, and data-egress constraints. Only then may the system compare eligible on-device, local-network, confidential-compute, specialized, or frontier API routes for capability, evidence, latency, energy, and cost. A learned quality router cannot become the system’s privacy authority.

15. External agent systems

The same explicit contracts can mediate work with larger external-agent environments. An outbound commission can specify:

• purpose and scope;
• minimum necessary context;
• source permissions;
• allowed tools and effects;
• output and evidence contract;
• time and cost boundary;
• confidentiality classification;
• callback or return channel;
• acceptance and integration owner.

The external system returns a bounded artifact and evidence, not implicit authority over the local knowledge system. This creates an architectural membrane between locally governed semantic custody and outside computational scale.

16. Honest failures

Failure states should preserve meaning:

Meaningful absence is better than fabricated continuity.

17. Vertical-slice verification

A feature is accepted as one composition across intelligence, interface, and implementation. Its evidence should include:

1. exact person purpose and gesture;
2. current semantic situation;
3. requested cognitive movement;
4. declared context sources and provider-visible ground;
5. prompt and response contract;
6. structural and semantic review evidence;
7. durable landing with explicit standing;
8. canonical target, version, and computed-delta preview;
9. authority, preconditions, and bounded effect;
10. post-state verification and operation receipt;
11. acceptance evidence where governing ground changed;
12. interface projection;
13. file settlement, collision, and recovery mechanics;
14. continuation into renewed ground;
15. reload reconstruction;
16. negative-authority proof showing what did not happen automatically.

The person appears twice for two different transitions: first to request a semantic continuation, later to authorize a bounded effect. The file-native ground preserves proposal, lineage, artifact, companion, and receipt so renewed state remains the same after transient processes terminate.

18. Failure modes

19. Evaluation program

20. Research connection

Research on structured model output makes the five-layer distinction concrete. In Planetarium, generated planning descriptions were 96.1% parseable and 94.4% solvable, but only 24.8% semantically correct. Structural validity is useful, yet semantically weak. This supports preserving uncertainty and open semantic reasoning before packaging a result as a bounded, non-authoritative proposal for target, authority, and effect validation. The AI-native architecture brief develops the evidence and limits.

Security research independently supports keeping authorization and effects outside the model. Agent Security Bench finds attack surfaces across prompts, tools, memory, and external content. The CaMeL and Progent preprints explore capability, information-flow, and privilege enforcement outside the model. Their assumptions and results do not prove an AIOS implementation secure; they support the architectural rule that semantic recommendation cannot be its own authorization boundary.

Hybrid execution has a related ordering requirement. RouteLLM demonstrates quality–cost routing between model tiers, while PalmBench shows that useful on-device inference depends on task, device, latency, memory, power, and thermal conditions. Neither determines whether data may leave a domain. AIOS therefore places disclosure eligibility before capability optimization, as summarized in the local-sovereign AI brief.

21. What this page contributes to the whole

Product mechanics are the trusted membrane between distributed intelligence and durable consequence. Commands admit bounded movements; files and companion metadata preserve local ground; models contribute semantic proposals; validation separates structure, meaning, identity, authority, and effect; receipts record what occurred; and reconstruction tests whether the same declared state survives interruption. Chapter 23 now follows these relationships through complete human–model–artifact journeys rather than testing components in isolation.