Tenet·Feature Guides 08 · Data & Storage ← All guides
Guide 08 · Data Ownership

Where District Data Lives

Tenet writes a district's analytics straight into storage the district owns, never our servers. This is the guide for the "where does our data live, and can we use our own?" conversation: the fast path, the enterprise path, self-hosted, and what it costs.

All tiers
The short version

Tenet never holds your analytics

Every usage and safety-analytics event the extension produces is written directly to a system the district owns and controls. Our servers don't read or retain those rows. The district chooses the storage; Tenet just routes the data into it.

Lead with this

"Your students' data goes into your storage, in your cloud account, under your control. We never pool it on our side."

Why your storage, not ours

A deliberate privacy choice

We made a deliberate choice not to pool student data on Tenet's servers. Student AI prompts are among the most sensitive records a school holds. Concentrating millions of them in one vendor's database would create a single, high-value target, a honeypot, and would make us the custodian of records that should stay with the people accountable for them: the district.

Writing analytics straight into storage the district owns keeps the data under their governance, their agreements, their state's requirements, and their retention policy. It is privacy by design and data minimization: we hold as little as possible, and the district keeps ownership and control.

If a prospect asks "do you sell or train on our data?"

"No, and we structurally can't: we never have it. Analytics live in your storage, and the sensitive work happens on the device. There is no central trove for us to sell, train on, or lose."

Two supported backends

A fast path and an enterprise path

Both keep the same privacy posture. They differ in setup effort, scale, and how much governance the district wants.

Option A · Google Sheets

Fastest setup; ideal for pilots and small-to-mid districts. A small Apps Script in the district's own Google Workspace receives analytics and writes them into a district-owned Google Sheet. Nothing leaves Google.

Strengths: live in minutes, no cloud account, no new bill, familiar to any Google admin.

Tradeoffs: daily quotas and row limits; the district owns its own backups and retention.

Option B · Enterprise object storage

Built for scale, retention, and governance. The extension writes objects directly into the district's own S3, Google Cloud Storage, or any S3-compatible bucket. Their account, their keys.

Strengths: effectively unlimited scale, automatic lifecycle and retention, IAM and audit, write/read key separation.

Tradeoffs: more setup; we ship a CloudFormation template and GCS bootstrap so it is deploy-a-template, not build-from-scratch.

What Tenet provides for the enterprise path

  • A ready CloudFormation template (AWS): a private encrypted bucket, lifecycle rules, and a least-privilege write key in one deploy.
  • The equivalent Google Cloud Storage bootstrap, plus step-by-step guides.
  • Setup becomes: deploy the template, copy the outputs, paste them into the managed config. About an hour with an existing cloud account; one to three hours from a brand-new one.
Cost

Low, and never paid to us

Tenet doesn't charge for storage. On the enterprise path the district pays its own cloud provider directly for what it uses, and never us for the data itself. Because analytics are almost entirely small text records, not images or video, the bill stays low: typically a few dollars a month for a small or mid-size district, into the low tens for very large, high-volume ones. There is no per-bucket fee; they pay only for what they store and the requests they make. The Google Sheets path has no storage bill at all beyond their existing Google environment.

Self-hosted & on-prem

"Can we keep it entirely on our own servers?"

Yes, for districts that want it. Because the storage path is S3-compatible, a district can point Tenet at its own self-hosted store, such as MinIO, running on hardware it controls, so the data never leaves its own infrastructure. The main consideration is reachability for take-home devices, and it is more involved to run, so we scope these as custom implementations. If a prospect raises strict data-residency or air-gap requirements, this is the answer: yes, and let's talk it through.

At a glance

The two paths, side by side

DimensionGoogle SheetsEnterprise object storage
Setup speedFastest, minutesGuided, ~1 to 3 hours
InfrastructureNoneA cloud bucket + keys
Scale headroomGood for small / midEffectively unlimited
Retention & lifecycleDistrict-managedAutomated
GovernanceBasicStrong (IAM, audit, rotation)
Ongoing costNone beyond GoogleA few $/mo, paid to their provider
Best forPilots, small / mid districtsGrowth & enterprise rollout
Objection handling

Say this when they ask

"Where does our data live?"
In your storage: your Google Sheet or your own cloud bucket, in your account. Tenet routes analytics into it and never retains them server-side.
"Can we use our own storage, or our own servers?"
Yes. Google Sheets or your own S3 / GCS bucket out of the box, and self-hosted S3-compatible storage (MinIO) as a custom implementation.
"What does it cost us?"
Nothing to Tenet for storage. The Sheets path is free; the cloud path is a few dollars a month paid to your own provider, low because it is almost all text.
"Do you sell or train on our students' data?"
No, and we structurally can't: we never hold it. There is no central database of student prompts on our side to sell, train on, or breach.
Honest limits

Say this before they ask

Set expectations

  • The district owns the operational side of whatever it picks: a Sheet needs a yearly roll and its own backups; a self-hosted server means running an internet-reachable, backed-up service.
  • Read credentials for dashboards stay local on staff devices, never in managed policy, so each district sets those up per admin or teacher device.
Keep reading

Related guides