Sidecat System 0.1.0 — working specification

Status: review draft, updated 25 September 2026. This specifies the intended agreement among Sidecat applications and the facilities that make them one usable System. It does not claim the present Gen5 code implements the agreement. The existing 13-chapter research draft supplies rationale and unresolved cases; this document and its base author profile are the review target. No Gen1–Gen5 data migration or compatibility obligation is assumed.

In this draft, must marks a proposed conformance obligation, may an allowed choice, and should a default whose exception must be declared. A complete-System claim, an individual app claim, a selected profile claim and an installed-product observation have different scopes. None is implied by a passing schema validator. The draft is not adopted until its open profiles and independent trials are resolved.

1. Purpose and conformance

Sidecat is a programmable, federated working environment for people and AI agents in organizations, including a one-person organization. It prepares a participant with relevant context and tools, lets that participant do and continue useful work, and lets the organization understand and steer what happened. The original control-plane thesis remains central: a model's fluent report, an approved decision, an attempted effect, and an observed result are different things. A system must preserve those distinctions when they matter without making exhaustive custody the price of an ordinary call.

A complete Sidecat installation supplies the core and the official application capabilities below, and a way to select optional profiles and further applications. An optional profile is not enabled merely because the installation can offer it. An individual application need only implement the parts of the common contract that apply to its declared behavior.

“Application” means a named, independently understandable and testable unit of behavior with a public interface. A package can distribute applications, Lisp modules, human or model guidance, workflow definitions, schemas, examples and documentation in a declared combination; a guidance-only package needs no handler. A suite selects contributions for a job or organization. A runtime hosts and routes the executable ones. These are distinct boundaries: many small applications can run as handlers in one resident Go runtime, while a risky application can run in a separate process. An application does not imply one process, permanent goroutine, service, or database client. Size in lines is not a conformance measure; a bounded set of interacting decisions and a reproducible independent test are.

The basic topology is:

people and many agent harnesses → CLI / Lisp / MCP / native clients
                              → prepared context and typed lowering
                              → registry + AAuth binding + call/event router
                              → independently owned applications and stores
                              → selected federation and outside effect owners

The System specification is about common meanings and interfaces. It does not prescribe an app for every noun or a universal business process. Software development is an early proving use, not the product's domain limit. The same contract must work for a research group, a supplier quality process, a training program, and a software team.

2. The small shared vocabulary

These are the primitives an application may rely on without importing another application's private code or database.

A note, message, Work definition, plan, invoice, experiment or employee is an application-owned type built from this vocabulary. The System does not impose one “record” table or one lifecycle state on all of them. In particular, a reusable Work definition need not have global open/closed state: a plan or board can own a particular occurrence, schedule and disposition. A conversation message is a stably identified, authored conversation event with provider-declared ordering or view semantics; it is not reduced to a note merely because both may carry text. A request derived from a message may cite the exact message and a bounded conversation range while recording its own admitted purpose.

An occurrence owner declares whether a referenced reusable definition is live or fixed for each consequential judgment. A completed occurrence or decision preserves the exact definition revision or resolved fields against which it was made; later edits to a reusable Work, training requirement or research protocol do not silently change that historical meaning. A live relationship can deliberately follow the current definition and reports its current version and freshness. If the promised older revision is unavailable, the owner says so rather than substituting the new one. This is an obligation of the app that makes the judgment, not a universal history table.

3. Application agreement and independent authorship

Every installed application publishes one machine-inspectable descriptor. The descriptor is inert to read and has a stable application ID and version, supported System profile, public interface IDs and versions, input/result schemas, operation effects, named failures, required permissions, events and their delivery classes, object protocols, dependencies, resource class, and a concise purpose/help description. A separate activation record binds the descriptor to an exact package artifact and admitted handler build, avoiding a self-referential descriptor hash. An app may declare no durable objects. Internal helper functions need no System descriptor. A role-oriented app may expose several related operations; roles are a design aid, not a class hierarchy.

An author can use these behavior profiles to choose the applicable obligations; they are not a fixed taxonomy of jobs or a requirement to split one coherent app solely to fit a row:

An application may combine these behaviors and several public interfaces when one bounded authoring unit remains clearer. A descriptor declares operation-level effects and guarantees; its category is not inferred from its friendly name.

For each public operation, the agreement states:

1. Who owns the change and what the operation can affect: pure calculation, read, local mutation, external effect or continuing work.
2. Input and output types, missing/null behavior, page and size bounds, possible failures, and required permissions.
3. Whether retry with the same key is safe, whether a timeout or cancellation can leave an applied effect, and how a caller reconciles an unknown outcome.
4. Its atomicity and ordering scope, version/conflict rule, and any event or retained-history promise.
5. Its cost class or declared admission limits when it may block, use a model, use the network or consume scarce compute.

The provisional base author profile supplies a concrete descriptor, portable values, local frame, host behavior and negative fixtures for the first author trial. Its choices are not qualified interoperability claims yet. The descriptor's stable interface identity is separate from a friendly alias and a running instance. Discovery must distinguish declared, installed, active, reachable and currently callable. Exact-name lookup and bounded search by type, purpose and capability are required. A prepared session receives a small selected working set; the full catalog remains pageable. Alphabetical first pages cannot masquerade as “what changed” or “what matters now.” Reading a catalog does not install or execute a package.

The common rule is that an application controls its own schema, index, transaction and upgrade through public operations. Other applications cannot query or write its private store. A shared runtime or storage library does not make domain schemas shared. Cross-app atomicity is never inferred from a common process, bus or machine: a workflow that spans owners records each step and its recovery or compensation.

For the first Go host profile, an independently authored native app registers through a public host interface generated from its released descriptor. The host gives it immutable typed input, verified runtime context, cancellation and bounded resource admission; it may invoke other public apps but cannot hold an app write transaction or exclusive Lisp session lock while waiting for them. A released Go package can be linked by a generic assembler without editing core dispatch code. A long-lived external worker can implement the same logical operations when process separation is chosen. A stateful app normally owns a separate SQLite database in this profile; a stateless app has none. This is an engineering default to keep app development independent, not a cross-language System conformance rule or an assertion that one file per app is always the fastest layout. An app may select another storage engine while satisfying its public contract.

A new author must be able to build an app with only the public author kit, its declared dependencies, and test fixtures. It must be possible to replace the provider with a compatible implementation without editing a client app's domain logic. The author kit includes descriptor validation, a fake bus/AAuth context, a deterministic event sink, failure/concurrency fixtures, examples, CLI and Lisp projections, and one independent client test. It is part of the System release, not an internal maintainer privilege.

The one-field authoring test

The reason for independent applications is to reduce the set of decisions a coding agent must hold together. The historical docs/codebase-report-2026-08-30.md in the Sidecat repository, based on c8e1daf4, measured a core-field change requiring 5–20 hand-synchronized sites and one schema successor requiring 1,847 insertions across seven files. Those are historical measurements, not a required target for a new app. The proposed boundary must be judged by an actual change, not its directory size.

Give an unfamiliar author only the public kit, one app's source and declared public dependencies. Ask them to add an optional nickname to the contact example, with distinct absent, null and string meanings. The app author may change that app's domain rules, its single logical interface declaration and private storage upgrade. Assembly may regenerate bindings and projections. The change must not require hand-editing the host router, a shared database or migration ladder, another app's source, or separate CLI, MCP and Lisp implementations of the same field. An older client and a newly written client must each observe the declared compatibility rule and a meaningful failure when they send a value they cannot express. Record every file the author had to read or edit, every repeated declaration, any private maintainer consultation, time to a working installed call, and the tests that actually ran. A clean schema diff alone does not pass.

If a real new behavior needs a shared facility, change the versioned System contract and its author kit deliberately, then test the affected apps. This exception cannot be used to hide routine app-local changes in core. Neither a line limit nor a ban on shared libraries follows: the useful boundary is whether a second agent can understand and change one app without reconstructing the whole product.

The lowering boundary

Each public entry point resolves a selected application, interface version and operation, validates the caller's expressible input, and lowers it to the same typed domain request before domain execution. The app owns the request's meaning; the CLI, browser, MCP adapter, Lisp binding and remote peer cannot each implement their own version of its business rule. Runtime context is bound from authenticated ingress and preparation, not copied from a caller-supplied actor field. A friendly alias resolves through a versioned registry entry; ambiguous names or conflicting package contributions refuse or require an explicit, inspectable precedence choice rather than silently changing with load order. The registry shows the selected contribution and the shadowed one in that alias scope without imposing a history ledger on every call.

text or structured surface  ──parse/resolve──>  typed operation request
          │                                        │
          └─ optional arrival provenance          ├─ bind verified context
                                                   ├─ select required assurance
                                                   └─ app-owned decision/effect

The domain request contains every meaningful input value, including nested ordered lists, maps, explicit null, exact numbers and typed references. Arrival provenance may record the original command or adapter shape under a selected retention profile, but never substitutes for a field in the request. A required connector has a generic structured-input path covering the entire base portable-value profile; a friendly shorthand may cover less. If a connector cannot represent a value or selected interface version, it refuses before the app sees the request. This directly revises Gen3's lowering design, which kept arrays, objects and null in invocation evidence while omitting them from normalized command flags.

Lowering is a bounded, side-effect-free translation from a surface form, resolved descriptor version and host-verified prepared target selection to (target app, owner?, interface, operation, typed input) or a typed refusal. The owner may be omitted only for a stateless operation or when the prepared selection resolves unambiguously before dispatch. Lowering does not create a universal Work/command record, decide domain authority, perform an effect or require historical capture. The host separately binds verified caller context, checks admission and selects any requested assurance; the app then applies its domain rule. A surface adapter may parse convenient syntax, but cannot silently invent an app default, turn absence into null, substitute a current revision for an exact revision, or interpret a caller-written actor as authentication. JSON Schema's default keyword is an annotation here; any actual default is declared by the app's versioned operation semantics and applied at one domain boundary.

The author kit tests the translation as a property, not only with examples. It generates valid nested requests in the shared expressible subset, renders each through at least two independent surface adapters, and compares the resolved target and typed input after lowering under the same prepared selection. It also generates values a shorthand cannot express and requires an explicit refusal or a move to that surface's generic structured path. Invocation text, call IDs, timing, optional provenance and selected retention may differ. Authority and effect equivalence is tested by sending the lowered requests through the same verified principal, version, target and policy snapshot; it is not inferred from byte-identical history records. This retains Gen2/Gen3's useful shared meaning while avoiding Gen3's universal-record pressure and scalar-flag loss.

For example, invoice.submit may receive ordered lines with exact decimal prices and a customer note explicitly set to null. A Lisp form and a structured CLI call that denote this same request must deliver the same line order, price values and null to the invoice owner. The app's accepted/refused result and effect meaning are equivalent when both calls use the same verified principal, target, expected version and policy state. Their call IDs, arrival text, trace timing and optional evidence need not be identical. A scalar-only CLI shorthand is allowed, but it cannot accept the invoice while silently dropping its lines or note. The base author profile pins the portable JSON forms; equivalent-surface property tests and intentionally unsupported-value cases belong in the author kit.

4. Local bus: calls, events and effects

The bus follows the useful D-Bus separation of named providers, interfaces, addressed calls, replies, errors and selectively delivered signals. It adds Sidecat's own authority, retained work and federation semantics; no D-Bus wire format or object-path hierarchy is required. A registered app name maps to an active provider instance, while the app's identity and an object's owner survive process replacement. A name collision, missing provider, stale route or incompatible interface is explicit. No inspection call runs installation hooks or automatically activates untrusted code.

A logical call has the following shape. Field names here are part of the proposed logical profile; transport bindings must preserve their meanings.

Call {
  call_id, target_app, target_owner?, interface_id, interface_version, operation,
  input, deadline?, retry_key?, requested_guarantees?,
  runtime_context: {caller, represented_actor?, authority, organization?,
                    session?, cause_id?, correlation_id?}
}

The runtime binds runtime_context from authenticated ingress and preparation. A client-supplied input field named “actor” cannot override it. A stateful call selects an owner namespace; an omitted owner is resolved only from an unambiguous prepared context or the call refuses. A relation to a foreign object may name a different owner in domain input; it does not redirect the target operation. The app receives the effective context and checks its own domain permission at the operation's declared decision point. Direct in-process dispatch, a Unix socket client, a Lisp call and a remote binding produce the same operation meaning. No shell or fresh interpreter is needed for each small app call.

A call returns exactly one of: completed with typed output; refused with a stable code, current-state explanation and next action when known; accepted with a durable continuation reference and read/cancel operations; or unknown with a reconciliation reference when an effect may have occurred but no definitive result is known. Before acknowledging accepted work, its owner records the next eligible wake/dependency, dispatch identity, recovery rule and enough purpose/context to continue. The resident runtime resumes eligible work after restart without the originating harness. Worker allocations and completions are fenced so a replaced worker's late report cannot advance the current attempt. A transport failure does not mean the domain action failed. An effectful caller retries only under the operation's declared retry rule and key scope. Cancellation requests stop future work but do not roll back an already committed domain change or external effect.

Events have three profiles:

A subscription names its declared source, event/interface type, permitted filter, and count, byte and in-flight bounds. Retained delivery additionally names a start cursor or read/watch handoff; a transient signal has no replay cursor. Authorization is checked for delivered content as well as registration. A retained cursor belongs to one source, filter and visibility scope; expiry or a changed scope yields an explicit gap/reset. The bus must not claim a global order over all apps. If an app promises a retained event for a committed mutation, it writes the dispatch intent atomically with that mutation in its own store, or demonstrates an equivalent recovery rule. Delivery may repeat; consumers must not infer exactly-once effects. A signal never substitutes for retained chat history.

A retained event binds its payload to an event schema version and exact schema digest. A replaying client retrieves that schema closure for the event's declared retention horizon; it cannot decode yesterday's event under a changed current descriptor without noticing. An invalidation carries an owner-issued watermark rather than pretending to be a replayable event history.

An event-to-call binding is inspectable, versioned routing data owned by a workflow or automation application. It names a declared source and permitted filter, including the source owner where the delivery class requires one, the selected event guarantee, a target interface/operation and version, a pure declared transformation or pinned method, the identity/delegation under which a call will be attempted, retry/reconciliation behavior, and fan-out/resource budgets.

Installing or enabling a binding is a distinct authorized action. A binding does not grant its target permission: the destination checks current domain authority and any selected gate at its own consequence boundary. A chat message containing imperative text cannot become an effect merely because it matches a pattern.

Only a retained source can support restart replay; a signal binding makes no recovery claim. A delivered event and a committed target result are different acknowledgments. A cause chain and bounded work budget limit cycles and broad fan-out; disabling a binding stops new attempts while retaining the status of already accepted work. These rules allow changes to percolate through independently built apps without making every app import a common workflow engine or another app's store.

The runtime admits calls through bounded queues by app/resource class and caller scope. It reports busy/overload without silently dropping accepted work, protects one slow subscriber from blocking unrelated calls, and budgets nested calls to avoid deadlock or recursive binding storms. Relevant metrics include queue depth, admission refusal, event lag, fan-out, latency and time spent waiting for an app's storage. Numeric limits are configurable and must be measured under a declared workload before a capacity claim is made. The number of installed apps is not the number of concurrent active calls.

5. Values, objects, semantics and content

The base portable value profile distinguishes scalar, ordered sequence, map/record under its declared schema, object address, exact revision, content/blob reference and foreign reference, plus a typed opaque extension. A cursor is a scoped opaque token supplied by the operation or subscription that issued it, not an unqualified global object ID. A live session handle has a separate nonportable profile and cannot be turned into a federated reference by printing it. A transport binding defines exact encodings and rejects ambiguous or unsupported variants. Large bodies travel by blob reference, not by copying them through every call and notification. A session may hold richer Lisp values; crossing a node boundary requires an explicit portable representation or a clear unsupported result.

Every object write is routed to its owner and preserves the owner's invariant. A current read returns the owner, type and current version when the owner offers conditional writes. A compare-and-swap operation tests its expected version at the same atomic boundary as the change. An app can instead declare append, owner-serialized command, set update or another exact rule. The System does not assume every object is mutable or versioned. A query declares scope, ordering, pagination, visibility and consistency. A derived inverse index declares which owners and relationships it covers and how fresh it is; it cannot answer “all references everywhere” without such coverage.

A connector may own a typed link to an outside system with provider, external object type and ID, observed version/status, sync direction, currency and conflict state. That link is neither a Sidecat object address nor permission to mutate the outside system. An outside observation may inform local work but does not silently override an app owner's record; a selected connector operation owns any synchronization effect and its unknown outcome. This retains the useful Gen2 planning-link boundary without making Linear, GitLab or any one business tool the universal Work model.

A facet is a typed named property with a declared value shape, multiplicity, scope and owner. A facet definition can be an addressable semantic object shared by apps. An intrinsic facet belongs to the subject owner; an external assignment belongs to the context owner. Thus two boards can attach different stages to the same Work definition without changing Work or manufacturing a global completion state. A relation with its own lifecycle, roles or evidence can itself be an app-owned object with explicit create, revise, retract and recovery behavior. A simple link can remain a field. A predicate's spelling does not create a reciprocal write or authorize either endpoint.

The semantic service supplies discoverable vocabulary terms, type/facet descriptions, named directional mappings and validation profiles. Authoring tools can show an app developer existing terms and command shapes, propose aligned names, and report a collision before admission. Similar spelling alone does not make two operations equivalent; a mapping declares direction, version, information loss and the owner of any transformation. It may use RDF, ShEx, ShapeMaps and existing vocabularies where helpful. It does not force all domain data into triples or equate structural type fit with permission, meaning or successful invocation. Unknown domain values can be carried inertly by a component that does not interpret them.

A blob service offers put, get and verify of exact bytes under a named digest profile, plus declared retention and access rules. A digest alone identifies bytes; it does not locate an available copy or grant read access. A fetchable remote blob reference additionally names its serving owner or a foreign locator, and the received bytes are checked against the digest. Git is a candidate backing for immutable blobs, named snapshots, packages and distribution; its object identity, reachability and namespace rules must be mapped explicitly. Git refs can select a snapshot but are mutable names, and a Git repository is not the universal mutable-object database. A Git effect application binds publication to an exact package-owned repository record and derives its local target from that record; a caller-supplied unrelated path cannot redirect a governed effect. A note may use a blob for its body while its app owns the note's current head, title and revision. Mirroring exact blobs or selected roots can support recovery or distribution; a recovery claim also names what mutable roots, keys and permissions were covered and shows a restore.

6. Authority, claims and selected assurance

AAuth integration is present from the first complete System installation. AAuth also remains independently usable outside Sidecat: a deployment consumes its public role and resource contract without confusing authority with package admission, credential custody, action execution, receipt or outcome. The identity application can enroll, bind, suspend, rotate and revoke principals for people, agents, services and harnesses.

Several harnesses under one Unix account must retain distinct attribution and replay-fenced consequences. An agent, the harness running it, the model it used and the person or organization it represents are distinguishable identities or attributed facts; a model name is not an authorization principal by itself. A managed Agent Provider profile can issue short-lived portable agent identity while a customer's node verifies and maps it locally, receives signed revocation where a negotiated recipient-notification extension exists, and observes explicit expiry limits during provider outage. Provider availability never grants an otherwise denied operation.

A stable actor and enrollment survive credential rotation. Identical allowed retries under that enrollment retain their original intent and result identity; replacing a signing credential cannot remap the actor or create a fresh effect from the same retry key. Suspending an enrollment or revoking a credential invalidates affected sessions and advances a consequence fence: a not-yet-attempted effect cannot begin after the acknowledged change under the old authority, while an already-running effect keeps its actual applied, not-applied or unknown outcome. This is cooperative same-UID attribution, not isolation from a hostile process that can read a sibling's credential.

The runtime authenticates a principal at ingress; delegation/representation is explicit and bounded by resource, operation, scope and expiry. An app enforces its domain rule where the consequence becomes committed. A package manifest, friendly name, claimed author or foreign peer statement cannot confer that permission. Remote calls are rechecked under the receiving owner's policy. The chosen implementation must state when a permission is evaluated for a long-running or queued call and what happens if it is revoked before effect.

An agent launcher that is told to start a particular enrolled harness must compare that independently selected actor/harness identity with the identity returned by Sidecat's authenticated preparation before the first Work write. An inherited environment variable that points a Codex process at Claude's valid credential must not silently attribute Codex's work to Claude. If a client cannot establish the actual harness beyond the credential it received, it reports only the authenticated credential actor and does not claim that the named model performed the work. This prevents accidental misbinding by a prepared launcher; it is not a claim of protection against a hostile process sharing the same Unix account and secrets.

The complete distribution advertises a named, version-pinned AAuth interoperability profile with an exact role, flow and source-version matrix. It includes self-hosted or managed Agent Provider operation, Agent proof of possession, independently administered Person Server and Resource access, and Authorization Server federation where the selected Resource uses it. The Agent-side adapter can negotiate the Core access modes; each Resource declares and implements the modes it actually accepts.

Enrolled bootstrap and credential renewal must not require a prepared launch profile to retain a reusable AAuth bearer token. The named AAuth profile states the client-held proof material, renewal exchange, expiry and recovery behavior; a failed renewal cannot silently extend authority. Sidecat and a standalone Person Server can restart independently, with re-established access distinguished from a cached claim. This obligation does not select an AAuth endpoint or token format before the current author-source profile is pinned.

Sidecat app authors consume a host-verified binding rather than independently parsing every token and HTTP signature. That binding separates local actor, AAuth role, token issuer, issuer-qualified Agent or person subject where actually disclosed, representing Person Server/namespace, proof key, selected access mode, target Resource and verified Resource account, grant scope, expiry and revocation freshness. The destination honors the verified account restriction; it cannot replace it with a prepared Sidecat organization or an input-supplied account string.

In some modes a Resource has a verified person and key but no verified Agent subject; local attribution must not be relabeled as a claim verified by that Resource. A local same-UID harness handshake is distinct from an AAuth exchange.

The current AAuth source comparison shows that the author's current editor text differs from the older AAuth Go implementation baseline. Before freezing 0.1.0, the exact support matrix and installed cross-role tests must be pinned to source digests; neither the old Go package's existence nor a local Ed25519 test vector is evidence of current-protocol conformance.

The common claim vocabulary distinguishes source material, attributed observation, inference, proposal, decision, execution attempt, provider receipt and observed outcome. A model answer is an attributed claim. A published artifact is an effect. An exact source reference can preserve why a request arose without copying an entire private conversation into each agent's context; permission to disclose the source is checked when it is read. When an agent says it tested or published something, that statement is not itself evidence of the test or publication.

Strong custody is a selectable enhancement. A call may request named guarantees. The consequence owner resolves them against applicable organization requirements and reports the effective selection before execution; it refuses before effect if a required guarantee is unavailable.

A nested call uses its service identity unless an explicit delegation carries the original actor's limited authority. Apps and effects declare which assurance profiles they support. An offered gate must bind the exact candidate content, target, expected version and responsible owner before effect; a prior coordinator approval alone cannot authorize changed content.

A selected workflow may make progress conditional on current scoped attestations, with explicit exceptions and historical validity rules. The selected rule applies to that workflow transition, not to every record in the System. The result reports supported, selected, applied and unavailable modes separately.

A stronger profile may retain prompt/context/provider finish reason, exact artifact bytes, approval, test observations, signatures and independent verification. Ordinary start, conversation, work and publication calls do not perform a whole-history audit or reconstruction as a precondition. Daemon readiness opens its stores, checks schema and store identity, and listens; integrity verification is an explicit operator action. A signature authenticates specified bytes under a verifier's key/trust policy; it does not prove content truth, current authority or a completed outside effect.

Simulation and retention are separate choices. When an app offers a sandbox or simulated backing, the call names that backing under a selected profile and the resulting outcome cannot be presented as an effect on the live owner or outside service. The simulation may itself be retained for later study. Conversely, a no-save Lisp session can still invoke a live app effect; the effect remains under that app's contract even if the session keeps no calculation history. An app that cannot simulate a requested effect refuses that backing instead of returning an apparent live success. This optional backing profile is not part of the provisional base call frame and does not require a simulation implementation from every app.

7. Lisp, packages, interfaces and many agents

A complete System ships a general-purpose Lisp and an interactive, resident REPL from day zero. The selected dialect and its conformance suite must be published; Sidecat Lisp cannot remain only a small command DSL. Sessions keep definitions, selected app vocabulary and live values; a participant can inspect, compose, evaluate, save, reopen and share methods. Retention is explicit: a pure no-save calculation creates no compulsory history, while an app effect remains durable under that app's contract. Forking a session copies declared environment state; merging is an explicit comparison/decision, never a blind concatenation of side effects. Short result indexes are session-bound pointers to exact references or view rows and must fail rather than retarget after a changed query, fork, restart or permission change. Partial evaluation/residual programs remain a candidate interaction profile until proven with the chosen full Lisp runtime.

The published language profile names one established complete runtime and version, its public language, Sidecat binding library and package ABI. The upstream runtime supplies recursion, closures, macros, code-as-data/eval, modules, rich numbers, errors and control behavior under its documented semantics; Sidecat does not quietly define a narrower similarly named dialect. A native app result becomes a Lisp value usable directly in the next computation, not only printed text or a copied JSON/ID. Untrusted interchange uses an inert data reader; package code, macro expansion and module initialization are executable and obey their declared process/effect boundary.

A full language or native Go package can also use OS filesystem, network or FFI capabilities if its process has them. Sidecat's app-operation gate does not intercept those ambient routes by itself. Package activation declares that trust boundary; a deployment that promises to restrict untrusted code must enforce the promise with an appropriate process/OS policy and test it. A locally trusted author may deliberately use the ordinary account boundary without turning every pure calculation into a governance ceremony.

A retained working frontier names exact data values, selected method definitions and dependencies, with visible omissions. Reopening reconstructs those selected values/methods without replaying old top-level work or outside effects; any constructor needed for a callable method runs under an effect-denied boundary.

Live-only closures, ports, threads, FFI handles and authority-bearing values remain usable in a live session but are not falsely promised as portable snapshots. Reader, macro expansion, evaluation, printing and result conversion have bounded admission and interruption behavior. Interrupting an evaluation does not undo an app effect; its typed outcome remains completed, refused, accepted or unknown. A fork transfers selected environment state, never a grant or earlier effect. The language research compares complete runtimes; Racket CS is a first qualification candidate, while a small resident-process probe found enough footprint difference from SBCL to require a fair installed-session test before selecting a language profile. Neither candidate has yet passed the Sidecat bridge, reopen or multi-agent trial.

Lisp, public projections and preparation

Activating an admitted application contribution extends the ordinary Sidecat environment: its operations appear as natural selected commands, MCP tools and bound Lisp values, with one underlying operation meaning. A caller supplies domain input without repeating an operation selector inside that input. The same registered operation is available through Lisp, a clear Linux CLI and man pages, a browser client, a native API and MCP projection. Generic projections can satisfy this availability; an app author need not build a bespoke browser screen, CLI parser or MCP server. Each public surface lowers its input into the same versioned, typed operation request. It must preserve every semantically meaningful field, including structured lists, objects and nulls; an adapter that cannot express a field or version refuses the call instead of demoting that field to mere invocation evidence. For equivalent requests in the expressible subset, authority, domain result, failure and effect meaning are equivalent. How a request arrived can be retained as separate provenance under the selected profile.

The first CLI profile has one generic path for every registered operation: sidecat operation call OPERATION_REF --input-file -, with --input-json for a short structured value. OPERATION_REF comes from bounded discovery and binds an exact app, interface version and operation rather than whichever friendly alias loaded last. Discovery returns that reference with a concise input/effect summary; sidecat operation describe OPERATION_REF gives full schema, failures and help when needed. The generic call returns a structured disposition. Prepared context and collision-checked generated aliases can make common calls shorter, but cannot introduce another interpretation of their input. A crowded-catalog trial must still let a newcomer discover and call one selected operation without paging alphabetically through every installed app or repeating launch credentials.

Sidecat can sit beside existing agent runtimes and orchestrators. Other harness adapters can be added without changing domain app code or making an agent's private transcript the authoritative work state.

A prepared workspace/session selects organization, project, role guidance, methods, tools and a bounded context packet once. A fresh agent using a different harness can recover purpose, active work, relevant sources, current results and unresolved decisions from Sidecat. A stable orientation alias may resolve to a bounded materialized summary with enough detail to act without recursive graph traversal. The view distinguishes accepted architecture, current maturity, proposals, feature state and live work when those are relevant. Selected context states its source, freshness and omissions. An agent's reinterpretation does not overwrite the operator's words.

The open-source repository has a separate fresh-checkout obligation. Published main exposes accepted architecture, subsystem maturity, reusable capabilities, feature intent, active proposals and contributor procedures to a person or agent without a prepared node session or private lead transcript. Generated pages identify their canonical source and revision. This repository intent does not assert that a proposed feature is installed or that a live Work item is complete; the authenticated node supplies changing execution state. An installed orientation view can link both but cannot replace the published contributor path.

A package may contribute versioned procedural guidance, such as a SKILL.md with examples and resources, separately from a machine-readable workflow definition. Selection of guidance says what a participant was offered; reading it does not prove the participant followed it, grant an operation, or enable a gate. A workflow owner selects and versions enforceable criteria explicitly, with the consequence owner applying any selected effect rule. The package can link the two contributions so a prepared agent receives useful instructions without mistaking prose for policy. An installation or upgrade must report which guidance and which workflow definitions changed; neither silently activates the other. This recovers the useful Gen2 Skills separation without compiling every suggestion into mandatory governance.

Model calls and durable turns

A managed model-call application can invoke providers, state which model and input selection were used, report finish reason and partial output, and deliver the outcome only to its intended caller or continuation. A clipped or otherwise partial provider response is typed as partial at that boundary; an adapter cannot present it as a completed deliverable or automatically promote it to a consequential effect. The caller or selected workflow decides whether to continue, revise, reject or use the partial result, with the selected effect owner still enforcing its own rule. If the model-call app promises restart recovery or a retained trace, it stores the exact information needed for that promise under the selected retention profile. A workflow or turn coordinator owns sequencing and budget decisions; the model adapter does not silently become the organization's work ledger.

The resident daemon can repeatedly allocate bounded turns to replaceable agents, deliver exact current context and delegated authority, accept fenced results, and advance durable work across waits and restarts without a lead harness staying alive. A durable allocation distinguishes requested capability and provider from effective allocation observed by the runtime, the reporting source of each observation, authenticated worker principal if one was actually established, and the dispatch/completion fence. A parent agent's report that it spawned a worker is a claim, not independent authentication of that worker. Conflicting observations are retained as distinct claims; a changed allocation is a successor with a new identity, not an overwrite. Messages, output and work decisions cite the exact allocation they concern. Full prompt traces remain selected retention, not a prerequisite to allocate a turn.

A coordinator or Work Plan app can issue a bounded assignment to a visiting agent. Its public record names the parent occurrence, useful outcome, selected source revisions and tools, allowed consequence scope, budget, stop or ask condition, expected result shape, return owner and who assesses it. The prepared packet is small enough for the assigned work, not a copy of the entire organizational history. A worker can request an expansion rather than silently widening scope; the owner can grant a successor assignment without rewriting the original. The returned artifact or report is attributed to that allocation and remains a claim until the responsible owner accepts or assesses it. The declared scope governs Sidecat operations; an OS isolation claim requires a separately enforced profile. This is not a mandatory sealed sandbox or a fixed small/medium/large taxonomy. In a qualification trial, a fresh agent receives only the assignment and selected public references, finishes a real bounded task, and the owner can judge the result without the parent harness transcript.

Packages and marketplaces

Packages distribute exact artifacts through public, private, organizational or curated registries. Acquisition and static inspection are inert; build hooks, installation, activation and native-code loading declare their effects and trust boundary. A package signature authenticates its artifact under a trust policy, while local admission and per-call AAuth remain separate decisions.

Registry discovery, download, admission, installation, activation, task selection, invocation and deactivation are distinguishable states.

Public deactivation stops new admission for the selected activation and declares how in-flight calls, accepted continuations and retained event/outbox delivery are drained, suspended or made reconcilable; it does not make a committed effect vanish. A replacement may resume a continuation only under an explicitly compatible activation and app-owned state-upgrade rule. Each app declares its store retention and upgrade policy; exact old activation and package identity remain inspectable for unresolved work.

Each executable contribution declares the host profile it needs; a guidance-only package needs no runtime handler. A Lisp module can become callable in a prepared language environment; a native Go handler may require exact static release assembly or a supervised long-lived worker. Fetching a descriptor or artifact does not hot-load arbitrary native code. Installation reports when a build/restart is required, and discovery reports a provider as callable only after its exact activated handler is reachable. A native worker can be started on demand and admitted under bounded resource limits; installed app count is not permanent process count. Unsupported host profiles remain inspectable but cannot be falsely activated.

A marketplace reports purpose, compatibility, provenance and relevant evaluations without treating popularity or publisher prose as proof. Release assembly selects exact package artifacts and their source provenance. Package source, semantics, behavior tests and installed qualification can be built and checked apart from core; official packages have no private operation or install shortcut. One public author kit and the same interface profile serve official, community and commercial apps.

An unfamiliar service or kind of work need not begin with a finished app. An agent may use a selected exploratory session to retain the assumptions, surprising responses, credential scope, verified calls and failure cases that actually helped; a second agent can then turn the working path into a package candidate with a descriptor, examples and tests. The candidate is inspectable and revisable before admission, and a later run tests whether it avoids the earlier blind attempts. Capturing every exploratory call is not the default, and neither a successful probe nor package installation grants authority over the service. This is a route from useful work to deterministic reusable behavior, not a requirement that every domain be anticipated by the initial System release.

8. Federation, messaging and organizational work

Federation is a normal deployment topology. An authenticated peer handshake identifies the peer, supported System profiles, route, authority binding and negotiated limits. A declared public artifact or catalog endpoint may permit a request with no authenticated origin peer or caller; that does not make a protected read or effect public. The owner-qualified address remains stable across endpoint movement; a new route must be bound to the same owner by an authenticated continuity rule. Remote reads and calls use the same logical interface but expose unavailable, stale, denied, pending and unknown outcomes honestly. No automatic cross-node database transaction, globally complete search or universal broadcast is implied. A node can offer selected remote execution with signed capability and local admission; a foreign model result is still an attributed claim. A job split across two independently owned stores may continue through disconnect, restart and placement movement; evidence returned by a remote worker remains a claim until the accepting owner verifies or records its actual disposition.

Full System federation comprises more than remote RPC or a chat bridge. The complete distribution must offer these independently testable shared capabilities; a particular app declares only those it uses:

These are capability obligations of a complete System, not mandatory tables, event streams or remote procedures in each app. The federation source study gives the protocol comparisons and the larger cross-node qualification case.

A foreign organization's message, plan or proposed terms are its attributed claim, not the receiver's acceptance. An interface that says two parties made a shared commitment must bind each party's assent to the same exact terms and version. Similarly, feedback sent across a node boundary does not change the recipient's Work until its responsible owner accepts or disposes of it; a fresh agent sees that disposition, or an explicit pending/stale result during partition.

The same separation holds locally. Feedback names the exact proposal, plan, result or explanation revision it addresses and its authenticated submitter. A feedback owner can acknowledge receipt while the selected plan is unchanged, then record an answer or decline by an actor with the relevant decision right. Only the authorized plan or occurrence owner can adopt feedback into a new selected revision or hold; an agent's own answer cannot lift an authorized human hold. A hold that supersedes an active allocation fences acceptance of that allocation's late completion; an already applied outside effect is still reported as applied or unknown, not undone. A bounded work view shows the current plan and feedback dispositions with each owner's source revision and currency. It may show a clearly dated mixed view when owners changed concurrently, but it cannot call that an atomic global snapshot or hide pending feedback from the next prepared agent. The work-change flow is the candidate journey behind this invariant; exact public operations and owner placement still need qualification.

Durable federated messaging is an official application family, not bus signals. A conforming first release has authenticated direct and room messaging, membership and permission changes, stable event identity, bounded history/catch-up cursors, edit/redaction and reply/thread relations, attachment references, offline retry and duplicate handling, and a stated confidentiality profile. A local direct-query or channel owner promises stable target-scoped order and a bounded cursor. A distributed room with a partially ordered event graph offers a named, stable view and cursor without inventing one global total order.

Direct-query and channel histories have distinct target identities and provider-declared order/view scopes; a target-specific catch-up does not concatenate unrelated rooms into permanent context. Membership, target policy, source context and authorization epochs fence send, read, wait, acknowledgment and response transitions at their declared owner boundaries. The messaging app supports bounded target-specific backlog/query and search with declared coverage, exact context stamps and distinct delivered, read, acknowledged, attention and response states; none is inferred from another. Completed or expired low-priority attention stops appearing as current work without deleting retained target history. Federation failure does not erase locally accepted messages.

The message app can point to an admitted request and back to a permitted source range, allowing later triage or review to inspect the originating discussion without asking an agent to reconstruct it. It must say when source content is inaccessible, redacted, expired or undecryptable, without pretending that a retained event ID guarantees readable content. Presence and notification delivery declare separate coverage and freshness.

End-to-end encryption and device/key-recovery behavior must be advertised and qualified under a named profile; it is not silently inferred from transport encryption. A Matrix-backed provider, native provider or IRCv3 client gateway can be evaluated against this Sidecat-facing behavior, but an IRCv3 client gateway by itself does not establish server federation.

A source-context stamp names the conversation provider and stable target/event anchors plus a bounded before/after window or provider-issued cursor and the view/observation under which it was selected. It does not copy a whole private channel into a Work item or agent prompt. A later reader follows the stamp under its own current permission and gets the available range, coverage, currency and explicit gaps; an edit or redaction does not silently rewrite the content already admitted into a separate request. A selected authorized excerpt, if retained, is a new exact record with its own disclosure rule, not an invisible backup of every chat.

The complete System also includes independent applications for organizational or company purpose, values, north stars and principles; structure and membership; portfolios, products, services, capabilities, maturity and ongoing operations; projects, reusable work and particular plans; workflow definitions and runs; decisions, evaluations and effects. These applications expose current state and lineage through typed public operations so a person or fresh agent can see how one work item serves a larger organizational aim without reading internal database tables.

A software-development suite can use these public interfaces for architecture proposals and disposition, roadmap revisions with lineage, qualified work cycles, Git commit/publish and parity, research claims and publication, and QA/release; these are specific applications of the wider System.

A research suite can govern budgets across literature, experiments, negative results, assessments and publication without rebuilding claim state from chat. Those are product capabilities, not fields every app must carry.

A principle or value is a named statement with rationale; it does not become an enforced gate until an authorized workflow or policy app adopts a rule. A workflow can have stages, criteria, questions, independent assessment and receipts; selected enforcement is evaluated before its named consequential transition.

A workflow run names the selected rule version, the occurrence and candidate being assessed, the actor permitted to decide, and which observation or receipt type satisfies each selected criterion. A test report authored by the implementer is an attributed claim; a QA app can record its own installed observations and judgment against the exact candidate. When the selected rule requires that judgment, the transition waits or refuses until it exists and is current. Changing the rule for a later run does not retroactively mark an earlier run as having passed it. The workflow app coordinates these facts without taking ownership of the product, research finding, supplier case or outside effect. An ordinary note, message or pure Lisp calculation need not enter a workflow.

Software QA and release are one possible suite built with these applications. Other suites can organize supplier audits, research, employee training or civic services.

Role-aligned apps are encouraged when a real role's vocabulary improves use and review, without requiring every component to represent a job title. Scrum, OKRs, research programs, standards work and other methods can be packages or selected profiles; the kernel does not impose one management method.

Evaluation apps connect a repeated failure to diagnosis, corrective proposal, reviewed change and recurrence evidence so learning changes the working system.

9. Qualification and revision rule

A System 0.1.0 claim requires more than compiling its core. The minimum independent trial uses: one small stateful app written against the public author kit; a second separately authored client; an installed local runtime; two different agent harnesses and a person sharing and correcting actual work; a full Lisp session calling the app; a package fetched and admitted from a second registry; and a nonsoftware workflow.

The federation suite uses independently administered organizations and three serving nodes: two exchange a message and authorized app call, then one owner moves to the third while the other still holds an exact reference and a subscription.

It also exercises authorized discovery, foreign resolution, selective sharing, change reconciliation, remote package admission, cross-organization work and disconnected local operation. If a Matrix-backed conversation is the chosen provider, its federation is tested across two independently administered homeservers and its room ordering is reported as a provider view, not global Sidecat order.

The trial forces stale-version conflict, revoked permission, app restart after commit before event delivery, slow subscriber, remote partition and an uncertain external effect. It deactivates an app with pending work, restarts and explicitly reactivates or replaces it without losing the status of an accepted consequence. Its nonsoftware case revises a reusable training definition after one employee's fixed-revision completion and checks that the earlier judgment does not change. It reports actual completed, refused, accepted and unknown outcomes through the public interfaces. Capacity tests declare workload, concurrent active calls, app mix, database layout, latency, memory and queue limits; an app-count estimate alone is not a stress result.

The AAuth part of the installed trial includes a real four-party grant across independently administered Agent Provider, Person Server, Authorization Server and Resource roles for one exact Sidecat operation. It then runs useful local work with governance off and one exact candidate effect with a selected governance gate. It distinguishes permission, domain admission, application/unknown outcome and audit delivery. The named AAuth profile, rather than this common paragraph, pins its source digests, endpoints, algorithms, vocabulary, key lifecycle and selected failure behavior.

The same trial rotates one enrolled harness credential and repeats an identical permitted request key: actor, enrollment and effect identity stay stable. It then suspends that enrollment between admission and consequence, checking the declared fence and preserving an already-running effect's honest outcome. A fresh launch profile contains no reusable AAuth bearer token; renewal and access recovery are exercised across independent Sidecat and Person Server restarts. Messaging qualification reads separate direct-query and channel histories, races an authorization-epoch change with send/read/wait/acknowledgment/response, and lets low-priority attention expire while retained target history stays readable under permission.

The first product qualification also walks one actual Sidecat development cycle through the installed System: Agent A records a sourced request, clarified work, plan and progress; a person corrects that exact work; after a restart, fresh Agent B receives the accepted correction with source and disposition and changes its next action.

Independent implementer and QA observations are recorded with their actual origin; a release decision applies the selected criteria to an exact versioned candidate; the Git effect owner publishes or reports unknown; another fresh agent sees the result, feedback and next work without a lead transcript. A test that only shows the correction in a view that B never uses fails.

The QA role assesses behavior, help and installed use, not merely whether smoke or regression tests passed. A separate supplier or research journey uses the same common facilities without pretending its outcome is a software release.

The independent-author trial changes one optional contact field without hand-edited shared runtime code, then has old and new clients exercise the declared version rule. An installed guidance-only package can be selected for a visiting agent without enabling a gate; a separately selected workflow rule can govern its named transition. A fresh visitor finishes one bounded nonsoftware assignment from its prepared packet, and a crowded catalog still offers a generic exact operation call with concise discovery. If a simulation backing is offered, its result is distinguished from a live effect while retention is selected independently. These checks test the recovered Gen2/Gen3 ideas as product behavior, not as a compulsory trace for every ordinary call.

A fresh Linux install exercises the documented one-command curl-to-shell installer, --help, per-app help and man pages, then a person and an unfamiliar agent try the resulting product. Public README and installed behavior must agree. A schema pass or headless test alone cannot count as this user test.

A separate fresh checkout of published main, without node credentials, must lead a contributor to accepted architecture, current declared maturity, feature intent, proposals and contribution instructions. The reader must be able to tell those repository declarations from current authenticated Work and installed behavior.

An application conformance claim is narrower: its descriptor and public schemas validate; its operations satisfy their declared effects, failures, versions and event promises; it can be tested without another app's private source or store; and its CLI/Lisp/MCP projections call the same operation. A pure function does not need a database, event stream or evidence ledger. A stateful owner does need to prove the exact promises it advertises. A package claim is separate from an installed product claim.

A System version changes when a shared meaning, required field, error class or interoperability guarantee changes. App owners version their own public interfaces. Additive compatible revisions are possible; incompatible semantics require a new interface version rather than a silent reuse of a name. This draft is not an adoption decision. An independent author trial and the open profile decisions below should revise it before it is frozen.

Pattern choices behind the contract

This table is rationale, not an extra set of app obligations. The source-specific analysis and limits are in the research chapters.

10. Decisions to close before freezing 0.1.0

1. Qualify or revise the provisional base author profile: its descriptor schema, JSON value rules, local socket frames and host interface need independent app/client implementations and cross-language negative testing. Complete the missing subscription-control, filter, acknowledgment, gap and socket-concurrency rules as part of that trial. The current local fixture set is not that trial. CBOR remains an optional later value/signature profile, not an assumed replacement for the first JSON binding.
2. Qualify or revise the base profile's locally minted owner namespace; select the authenticated federated route relocation, fencing and key-rotation rule. Owner identity cannot be a transient process ID, DNS address or unqualified key fingerprint.
3. Select the public owner and disposition rule for feedback against exact ongoing work. A person's correction must be accepted, held or refused by the responsible owner and affect the next agent's preparation; a message that was merely sent does not prove the work changed.
4. Publish the full Lisp dialect and its session/fork/retention profile. Measure resident sessions and concurrent evaluations before choosing one Lisp process per session or shared worker pool.
5. Bind selected assurance and AAuth checks to exact operation/effect timing, including queued calls and revocation.
6. Fix the day-zero federated messaging feature profile and its interoperability/permission test. Naming Matrix or IRCv3 alone does not define Sidecat behavior.
7. Run an independent small-app author and client trial, then adjust the common contract. Freeze an interface only after it removes private guesses for that author.
8. Pin the package contribution metadata and selection rules for guidance versus workflow, the public bounded-assignment interface, and the optional simulated-backing profile. Exercise their installed journeys and the generic CLI under a crowded catalog before calling them interoperable.

Research basis: current Sidecat VISION and Gen5 feature ledger; authored Gen1–Gen4 literature and Insight Forge control-plane and Work Ledger records; Sidecat Micro and ShapeEngine investigations; primary D-Bus, etcd, JetStream, JSON Schema, Git, RDF and messaging specifications. Historical implementations are comparators, not authorities over this draft.

The Gen5 and domain coverage map lists each present Gen5 capability and feature against the clause that must support it. The May 7 Insight Forge control-plane essay and Work Ledger capability page are authored historical roots; the latter labels itself a probe with partial and next criteria, not a current runtime qualification. The D-Bus specification supplies the local routing comparator.