# Own your work: portability, open formats, and freedom to leave

A team spends eighteen months preparing an investment case. The project contains contracts, spreadsheets, public sources, three versions of the financial model, and the reasoning behind the final recommendation. Then the service that organized the work becomes unavailable.

The team still has the PDF shown to the investment committee. Can it recover the sources, understand the calculations, return to an earlier revision, choose another AI model, and continue the project in different software?

That test separates access from ownership. **Work remains under your control when its authoritative copy, readable representations, evidence, and exit path stay accessible to you.**

## Five layers of ownership

Legal ownership of a file, technical access, and software authority are different questions. A work product should be examined through five layers.

1. **Access.** A person can open and retrieve the content without an active subscription or a remote interface.
2. **Authority.** They can modify, version, export, and delete the copy they control.
3. **Readable representation.** Useful content is not reduced to an opaque database or a screenshot.
4. **Replaceability.** A model, provider, or tool can change without erasing the project history.
5. **Exit.** If the product disappears, the work, evidence, and necessary formats make it possible to continue elsewhere.

Each layer fixes a weakness in the one before it. View-only access gives no authority. A proprietary export may move bytes without making them useful. A readable file without its sources or history preserves the result but not the reasoning needed to revise it.

![Five layers show how access grows into authority, readable representations, replaceable components, and a verifiable exit](/assets/blog/ownership-layers.svg "Ownership is built in layers. Each layer adds the capability needed by the next.")

## loqy's starting point: a local working copy

In loqy V1, the agent engine, canonical history, and authority over the work live on the Mac. The application works without an account and its primary operation does not depend on a loqy server. [The local foundation and its hosted complements](/blog/why-loqy-starts-local/) explains the exact limits of that design.

This local foundation is organised into four distinct spaces:

- an explicitly selected connected folder, whose ordinary files stay in place;
- a Project workspace for sources and results shared within that Project;
- a private workspace for each conversation that performs work;
- temporary Run scratch space that can be removed without losing durable state.

This separation bounds the agent's disk access and preserves the origin of admitted sources. Revisions, Project publications, deliverables, and source references keep distinct identities.

An operation on a real file remains explicit. Producing a new revision in private workspace preserves the original. Updating a connected file follows a separate path with conflict checking. That difference matters more than it may appear: the software knows which copy has authority, and the user decides when that authority changes.

## A useful export preserves work beyond its database

Application data encodes implementation choices. A Turso database, a vector index, or an agent's internal directory may be local while remaining difficult to understand outside the software that created it.

loqy's logical export separates content from storage engines. `Export everything…` writes a dated local folder. Conversations are represented in Markdown. Deliverables retain their native formats. Projects, memory, profile, and skills use JSON or Markdown according to their structure. Material objects preserve their identity, relationships, and the provenance references needed to understand their role.

The export preserves each format's native structure. A workbook remains a workbook with its qualified sheets and formulas. A document, presentation, or PDF retains the revision that was actually delivered. Markdown, CSV, JSON, JSONL, XML, YAML, and other qualified text formats remain directly inspectable. User-supplied files are retained when they are required to understand or reconstruct the work.

Secrets follow a different rule. API tokens and credentials remain in macOS Keychain. An export report identifies their reintroduction as an authentication step with the next service.

## Conversation references have an exact scope

loqy can also import bounded current Claude and ChatGPT exports, then export selected conversations as versioned reference files. These files carry messages and their provenance. Their scope covers the conversation reference; Runs, permissions, attachments, tools, and external effects remain specific to the source application.

Portability states what moves and what the receiving software can interpret. The file supports reading or reusing conversation content, with an explicit scope for native history.

## Change the model without changing the project

Lock-in can come from storage, but it can also come from the AI model. If instructions, sources, tool results, and deliverables exist only inside a provider-specific conversation, changing the model means starting again.

In loqy, the model is a component selected for a Run. The local agent engine retains the conversation, plan, rules, tool calls, evidence, and deliverables. A local or hosted model receives admitted context for the request, not authority over the complete project.

The exact model remains attributed to its output. Moving from local Qwen to Claude, Mistral, Umans, or another configured provider preserves history and the attribution of earlier responses. The route remains fixed during the run; a failure is reported to the user.

Replaceability preserves the project when models differ. The product retains authority, attributes each result to the exact model, provider, and configuration, then permits a new explicit choice without moving the authoritative copy.

## Connect source code to the distributed binary

loqy's code is open under a documented license split: MPL-2.0 for open-core implementation and Apache-2.0 for explicitly public interoperability packages. This allows people to inspect the design, propose changes, and rebuild covered components.

Verification then connects the downloaded application to this code, its dependencies, and its build options.

The path from source to application provides its own evidence: locked build inputs, a software bill of materials, licences, provenance, signatures, and reproducible comparison of the unsigned payload. An Apple signature identifies the distributor and protects download integrity; provenance relates the artefact to published source.

Ownership therefore gains a property that cuts across the five layers: verifiability. A credible exit path relies on documented formats, digests, manifests, and tools that can read them independently. [An agent's evidence chain](/blog/why-ai-agents-need-evidence/) applies the same requirement to each work revision.

## The continuity test after a service disappears

The scenario is deliberately severe. The loqy website, update service, and optional services stop responding. The team still has its Mac and export folder.

A complete exit path follows five operations:

1. retrieve working files, deliverables, conversations, and evidence;
2. verify formats, manifests, and any stated omissions;
3. select another model, provider, or tool;
4. use a compatible reader or rebuild the software from documented source and dependencies;
5. continue the project without asking the disappeared service to reauthorize the data.

![A five-step continuity path starts with files, deliverables, and evidence, verifies readability, replaces technical components, and continues the project](/assets/blog/service-exit-path.svg "The continuity test checks a practical outcome: readable data, separately restored credentials, and replaceable software or components keep the project usable.")

Continuity depends on formats: a complex spreadsheet uses specific functions, an interactive page needs its code and dependencies, and a Web source may disappear. The export preserves enough information to identify those dependencies. [European sovereignty](/blog/building-a-european-ai-agent/) extends that exit test across data, software, models, infrastructure, law, and skills.

Rights also shape the scope: a document shared by an organisation, a third-party subscription, or a licensed database keeps its own rules. Portability covers data the actor is authorised to export and reports omissions explicitly.

## Six questions for evaluating work software

Before entrusting a durable project to a product, ask:

1. Where is the authoritative copy, and who can change it?
2. Can I export without maintaining a subscription or contacting support?
3. Is the content readable independently of the product's internal databases?
4. Do sources, revisions, and evidence stay connected to deliverables?
5. Can I change model or provider without losing history?
6. What software, documentation, and evidence let me continue if the vendor disappears?

Ownership requires all six answers. Local storage becomes strong with readable formats, a verifiable binary, and replaceable services.

For loqy, exit shapes workspace separation, revision identity, deliverable formats, model choice, evidence retention, and the build chain from the start. The criterion is concrete: after the vendor disappears, the team should be able to understand what it holds and resume the work.

## Sources

- loqy V1 product requirements
- Desktop experience: data ownership and export
- Local data and logical export architecture
- ADR for the portable open data archive
- ADR for bounded conversation retention and interchange
- Reproducible builds, provenance, and software bills of materials
- Repository license