On It
Stage: Pre-launchDocumenting interest only — no money is being collected. No securities are being offered.Phase 1 · Arkansas-onlyWhat's real today →

Member Data Charter

Last updated: 7/4/2026

Pre-launch document. This charter describes the data commitments the cooperative intends to adopt at entity formation. It is the public draft that will be proposed for ratification into the cooperative's bylaws — not a current contract.

Why this exists

The defining trick of extractive software is to lock your data inside a vendor's interface, then make leaving expensive. As AI agents start replacing app frontends, that trick is about to get worse — incumbents will try to force every member onto their captive agent. We want to commit, in writing and in the bylaws, that the cooperative will not play that game.

The five commitments

  1. Plain-text export, on demand. Any member (Class A Patron, Class B Worker, or Class C Community) is intended to be able to export their own data — service history, ledger entries, telemetry summaries, communications — as standard files (CSV, JSON) at any time, at no cost.
  2. Open, documented schemas. The shape of every member-facing record is intended to be published — table names, column names, units, and meaning — so a member (or their agent) can understand the export without reverse-engineering it.
  3. Read-only API tokens. Members are intended to be able to issue scoped, revocable tokens that let their own AI agents, scripts, or third-party tools read their own data directly — without going through a cooperative-controlled UI.
  4. No agent lock-in. The cooperative's own dashboards are intended to be one reference UI, not the only one. Members may use third-party agents against the published schemas. The cooperative will not condition service on a member using a specific agent or app.
  5. You can take your data and walk. If a member ends their relationship with the cooperative, they are intended to retain a usable copy of their own data — and the cooperative is intended to delete the original on a published schedule, except where law requires retention.

What this does not cover

  • Aggregated, de-identified operational data the cooperative needs to run the platform (route optimization, hardware reliability statistics, settlement math). The cooperative intends to retain and use this in service of member benefit.
  • Other members' data. Your export is your data. Privateer assignments, neighbor service history, and aggregate ledger data belong to the cooperative or to the other member.
  • Settlement engine internals. The cooperative intends to publish the interface (schemas, results, audit trail) but versions and governs the policy code itself, since incorrect splits or bounty math would harm members.

Schema versioning and deprecation

Every public, machine-readable surface the cooperative publishes (under /api/public/*) is intended to follow semantic versioning so agents and integrations have a stable contract:

  • MAJOR.MINOR.PATCH. MINOR and PATCH changes are additive and backward compatible (new fields, bug fixes). They are intended to never break an existing consumer.
  • MAJOR = breaking change. A breaking change to any public dataset is intended to come with a 12-month deprecation window during which the prior version remains available at /api/public/v{N}/….
  • Version exposed in-band. Each public response is intended to include an X-Schema-Version response header and a schema_version field in the JSON body, so an agent can detect drift without out-of-band coordination.
  • Changes are announced. MAJOR changes and deprecation countdowns are intended to be posted to the public Changelog with the effective date.

The point of this commitment is the same as the rest of the charter: an agent built today against our public surface should keep working tomorrow, and a member who delegates work to that agent should not have their integration silently broken by a vendor change.

Bylaws integration (planned)

At entity formation, this charter is intended to be proposed as a bylaws addendum so a future board cannot quietly walk away from it. Material weakening would require a member vote across all three classes — the same mechanism that protects against a buyout.

Related

Questions

leads@onitrobotics.com