TG://CHARTER
OPERATING_DOCTRINE
ENTITY_TYPELIMITED_LIABILITY_COMPANY
JURISDICTIONUNITED_STATES
ESTABLISHEDMMXXIV
DOCTRINE_STATUSACTIVE
ENCRYPTIONENFORCED
════════════════════════════════════════════════════════════════════════════════

What Talos Group is, and what it stands for.

TALOS GROUP LLC | OPERATING CHARTER & ARTICLES OF DOCTRINE

════════════════════════════════════════════════════════════════════════════════

Talos was not a soldier. That distinction matters.

In Greek mythology, Talos was a giant of bronze. Forged by Hephaestus, the god of the forge, and set to guard the island of Crete. He was not a weapon of conquest. He was a guardian. He circled the shoreline three times a day. He did not seek enemies. He deterred them. The difference between a guardian and a weapon is purpose, and Talos was purpose-built to protect rather than to threaten. We named the company after that distinction.

Hephaestus was not a god of war either. He was a craftsman. The only Olympian who worked with his hands, who built things, who solved problems with materials and fire and precision. The Greeks respected him not because he was powerful, but because what he made was made correctly. It did what it was built to do. It did not fail. It did not compromise.

That is the inheritance we are claiming. Not the mythology of the warrior, but the discipline of the forge. We build things that work exactly as specified, that do not conceal what they cannot do, and that protect the people who use them as their primary engineering objective. The name Talos is a reminder, written into the company's identity, of what we are supposed to be building toward every time we open a codebase.

────────────────────────────────────────────────────────────────────────────────

Most software is not built for you.

It is built for the company that makes it. The interface is designed to maximize engagement, not usefulness. The data model is designed to capture as much as possible, not as little as necessary. The update schedule is designed to maintain dependency, not deliver improvement. The terms of service are written to protect the company from you, not to protect you from anything at all.

This is not a conspiracy. It is an incentive structure. If a company's revenue comes from advertising, then its product is your attention and its customer is the advertiser. If a company's valuation depends on growth metrics, then engagement is an engineering target regardless of whether it serves you. The business model shapes the product, and the business model of most software is not aligned with the interests of the person using it.

The result is software that extracts from you rather than serves you.
That monitors you rather than protects you.
That treats your data as inventory and your behavior as a signal to be sold.

The mobile device in your pocket runs applications that report your location, your contacts, your usage patterns, and your behavioral fingerprint to servers you have never seen, under agreements you never read, in the service of interests that are never disclosed to you. This is the industry baseline. It is not a bug. It is the architecture.

We build in direct opposition to that architecture. Not because we believe we can fix the industry. We cannot. But because we believe it is possible to build software that does not participate in it, and that there are people who want that software, and that those people deserve it.

────────────────────────────────────────────────────────────────────────────────

Three things we hold as first principles, not policies.

Policies can be changed. First principles cannot. The distinction is important because policies are revised under pressure. By lawyers during fundraising, by compliance teams during acquisition, by executives during difficult quarters. First principles are what you build the architecture around. You cannot revise the principle without redesigning what was built on it.

LOCAL-FIRST IS NON-NEGOTIABLE.

Your data does not leave your device unless you send it. We do not sync it to our servers for backup, convenience, or cross-device access. We cannot see it because we designed the architecture so that we cannot. This is not a feature you can turn off. It is the foundation the software is built on.

SECURITY IS ARCHITECTURAL, NOT A FEATURE.

Security added after a product is designed is a patch over a gap. Security designed in from the beginning is a different product. We start with the threat model. The architecture follows. We do not add encryption to a finished product. We build encryption into the design of the system from day one.

PRIVACY IS NOT A POLICY PROMISE.

A privacy policy is a document. A document can be amended. Privacy enforced by architecture cannot be amended without rewriting the software. We do not ask you to trust our policy. We build the systems so that your privacy does not depend on us keeping our word.

────────────────────────────────────────────────────────────────────────────────

We do not optimize for speed of delivery. We optimize for correctness.

The pressure in modern software development is relentless and consistent: ship faster, iterate in public, move before you are ready, treat version one as a learning exercise. This is reasonable advice for products built around growth metrics and venture timelines. It is catastrophic advice for products built around security.

A security application that ships with a flaw does not get to iterate its way out of the consequence. The consequence may already have occurred. The file may already have been accessed. The key may already have been exposed. There is no sprint retrospective that addresses a breach. You build it right, or you do not ship it.

This is how we build. Slower, on purpose. With testing protocols that would be considered excessive by most teams. With a refusal to place a feature in front of a user until we can defend the security properties of that feature under examination. We do not call something a vault if it is a lockbox. We do not call something encrypted if the implementation has known weaknesses.

Design PriorityCorrectness first, speed second
Cryptographic StandardNIST-current, no legacy fallback
TelemetryNone. Not anonymized. None.
Data RetentionMinimum required. No more.
Threat ModelingPublished. Limitations named.
ObfuscationRejected. Clarity is security.

The Hephaestus principle: what we make is made correctly, or it is not shipped. Feature count is not quality. A tool that does five things correctly is worth more than a tool that does fifty things with asterisks. We build the five things. We defend them. We tell you what they cannot do.

────────────────────────────────────────────────────────────────────────────────

In classical law, a commission is a formal grant of authority. A document that specifies what an agent is permitted to do and, by implication, what they are not. The privateer's letter of marque authorized them to act against designated targets while prohibiting all others. The commission defined the operator. Our commission follows the same logic: it defines precisely what Talos Group is authorized to do and what it explicitly refuses.

ARTICLE I
WE BUILD FOR PEOPLE, NOT METRICS.

We will not instrument our applications to report behavioral data back to us. We will not track how you use our software to improve our conversion rates, optimize our engagement loops, or sell the intelligence to anyone. What happens inside our tools belongs to you. We built them so that we cannot see it even if we wanted to.

ARTICLE II
NO BACKDOORS. NO EXCEPTIONS.

We will not weaken our software at the request of any party. Government, law enforcement, or investor. A backdoor that exists for one exists for all. There is no such thing as a trusted vulnerability. Requests of this nature will be refused regardless of legal framing or political pressure.

ARTICLE III
LOCAL-FIRST IS AN ARCHITECTURAL COMMITMENT.

Your data does not leave your device unless you send it. Not because we have a good privacy policy. Because we built the architecture so that it cannot. Policy can be changed. Architecture that cannot store data cannot be compelled to surrender it.

ARTICLE IV
WE TELL YOU WHAT OUR SOFTWARE CANNOT DO.

Security theater is worse than no security. It creates false confidence in the people who need real protection. We publish our threat models and our known limitations. We do not sell promises we cannot back with architecture. We do not call something encrypted unless it is encrypted to a standard we can defend.

ARTICLE V
WE HOLD OURSELVES TO THE HIGHER STANDARD.

The legal minimum and the ethical minimum are not the same thing. A company can be fully law-abiding and still harvest your data, monetize your behavior, and sell your attention to the highest bidder. We do not. We hold ourselves to the standard above what is merely permissible — not because it is required, but because that is the only bar worth building to.

────────────────────────────────────────────────────────────────────────────────

There is a line between what is legal and what is right. We find it. We hold it.

The legal minimum and the ethical minimum are not the same thing. A company can be fully law-abiding and still harvest your data, monetize your behavior, and sell your attention to the highest bidder. All of that is perfectly legal. None of it is what we are here to do.

We hold every protection available to our users as a standard to be met — not a ceiling to be negotiated down. We find the line between what is permissible and what is right, and we build on the right side of it, at maximum protection for the person using our software.

That is what Talos was built for. A guardian, not a weapon. A craftsman's creation, not a soldier's. The bronze giant who circled the island not to attack but to make attack not worth attempting. We build software with the same intent: to make the cost of compromising your data not worth paying.

Built with precision. Held to standard. Uncompromising by design.

════════════════════════════════════════════════════════════════════════════════