# Why loqy starts local and private by default

Most workplace software begins with an account, a server, and a promise that the vendor will take good care of whatever you upload. loqy begins somewhere else: on your computer, close to the files and tools that already make up your work.

That starting point changes the product. A useful local experience cannot be a decorative offline mode or a restricted preview of a cloud service. It must let you do meaningful work without first creating an account, moving a document to someone else’s infrastructure, or accepting an opaque data boundary.

## Local-first is a control boundary

“Local” describes where a model or tool runs. “Local-first” describes who remains in control when the product grows. loqy is designed so the local path remains a complete foundation: your working context stays close, the model choice stays explicit, and a cloud capability is something you add deliberately.

This matters because an AI agent does more than answer a question. It may read files, browse public sources, execute code, prepare a deliverable, or ask to take an external action. Each step has a different risk. Treating all of them as one broad permission would be convenient for the software and confusing for the person using it.

loqy instead keeps the authority boundary visible. The agent can prepare work inside its isolated environment, but a consequential effect still needs the right capability and, when required, a precise human decision. Choosing a cloud model does not silently move every tool or file to the cloud.

## Privacy needs honest limits

Local-first does not mean that a desktop application is magically invulnerable. The operating system, the models you install, the providers you connect, and the permissions you grant all matter. It would be misleading to turn “local” into a blanket security claim.

The useful promise is narrower and stronger: data placement should be understandable, network use should be explicit, credentials should not be handed to the agent, and work should not leave the device merely because that is the easiest implementation. When an online provider is selected, loqy should make that choice and its consequences clear.

## Why open source belongs here

Privacy claims are easier to trust when the architecture can be inspected. loqy’s open-source core is intended to make the local authority, permissions, and evidence model reviewable rather than asking people to rely only on a landing page.

The project is still in pre-launch. Some release details will evolve as the application is qualified on real hardware. The principle will not: local and private by default is the starting point, and cloud remains a choice.