question.management · the district-operations address of the question.* family · Powered by question.technology
What a district gets from Question today, in an org-scoped data model enforced by the database — and what a district administrator still has to ask us for by hand.
There is no self-serve district console, no SSO/roster-sync connector, and no cross-building rollup report shipped today, and this page names each of those plainly rather than let an absence read as an accident. Money is off here. Nothing here is AI.
The question.* family is one shared response engine with front doors aimed at different readers, all built by one team, on one security model, one support operation, and one roadmap.
question.technology is the engine: the shared question-authoring and response-collection surface the whole family runs on.
question.software is the classroom front door: the place a teacher writes questions, runs them with a class, and reviews the responses.
question.company is the venture behind the family: who builds it, how it operates, and its honest stage.
question.management — this page — is the district-operations facet: how a district administrator stands the engine up across more than one building today, and what the org-scoped model guarantees while doing it.
Powered by question.technology. A district pays for the underlying platform and the capabilities it selects, not repeatedly for the same engine wearing different brands.
Provable now
A district-operations claim is easier to trust when it can point at the table column that enforces it. Everything in this section is a property of the response engine that runs today, read off the real database and shared library — each card names where it is enforced so you can check it.
Enforced by the database today
The response table carries an owner_org_id column, and every row belongs to exactly one organization. A district that registers as a single organization has every question set and response walled off from every other organization on the engine by that column, before any application-level check runs.
Evidenceqt_submission.owner_org_id (NOT NULL); the shared question-technology library scopes reads and writes by it.
Enforced by the database today
A district-issued survey, an intake form, or a building-level poll all compose from the same three answer shapes the database itself enforces: open text, a 1-to-5 scale, and single choice. That holds identically whether one building uses it or twenty.
Evidenceqt_question.type CHECK IN ('text','scale','choice'); SCALE_RANGE = {min:1,max:5} in @homeroom/shared.
Enforced by the database today
The row a response is written to has four columns -- id, owner_org_id, submitted_at, moderation_state -- and none of them names a person. This does not change as a district adds buildings: there is still nothing for a later bug to accidentally fill in.
Evidenceqt_submission columns = id, owner_org_id, submitted_at, moderation_state. No identity column exists.
Enforced by the database today
A stored response keeps only the hour it arrived. A route that tries to store a precise timestamp is rejected by a database CHECK, not silently recorded -- the same wall named on question.company, unaffected by how many buildings share the organization.
Evidenceqt_submission.submitted_at DEFAULT date_trunc('hour', now()) with CHECK submitted_at = date_trunc('hour', submitted_at).
These guarantees hold identically whether a district has one building on the engine or twenty; owner_org_id is the same column at any scale.
Radically legible about our stage
A district-operations page is the easiest place to imply a console screenshot that does not exist. So here is the ledger, out loud. The left column is what a page like this usually implies. The right column is the honest version for Question.
| What this kind of page usually implies | The honest version for Question |
|---|---|
| A self-serve console to add ten buildings under one district account | A district is set up as one organization directly with us today. There is no self-serve multi-building wizard yet, and we will not screenshot a console that does not exist. |
| An SSO or SIS roster-sync connector | There is no shipped SSO or roster-sync integration for Question. If a district wants staff accounts provisioned from its own roster system, we do that by hand on request; it is a real service, not a flipped switch. |
| A cross-building comparison dashboard | owner_org_id proves the isolation between organizations; it does not by itself produce a rollup view comparing building A to building B, and no such report exists in the product today. |
| A vendor-portal / self-serve procurement packet | There is no self-serve data-processing agreement generator or automated vendor-portal submission. A district procurement office reaches us directly and we work the paperwork by hand. |
| A published uptime figure or SLA table | We do not publish an uptime number we have not measured to a standard we would stand behind. If a district needs an SLA, that is a conversation, not a marketing table. |
| A district logo wall and adoption count | There are no district logos or adoption counts to show yet, because none are cited-worthy yet, and inventing one would be exactly the kind of thing this page exists to avoid. |
Naming the gaps is how the provable parts above stay believable. A district that reads this page knows exactly what it is buying and exactly what still requires an email.
How districts onboard, today
There is no signup wizard for a district. This is the real process, described in the order it actually happens, so a district administrator can plan a timeline against reality rather than an assumed console.
Step 1
There is no self-serve district signup form. A district reaches us directly at the address below and tells us what it wants to run and how many buildings are involved.
Step 2
We create a single owner_org_id for the district. Every building the district wants on Question shares that one organization row today; there is no per-building sub-account.
Step 3
We provision staff accounts on request. There is no SSO or roster-sync connector shipped yet, so this step is manual work on our side, not an automated import.
Step 4
Once set up, staff build and run question sets the same way a single-building account would, all inside the one district organization and its data wall.
Step 5
There is no self-serve cross-building report today. If a district needs a comparison or a rollup, that is a request to us, not a button in a console.
A district-operations page is read by an administrator, a procurement officer, a building principal, a parent, and a reporter, and they do not want the same thing. Here is where each should start.
| You are | Start with | Because |
|---|---|---|
| A district administrator evaluating rollout | What is running today, then What still takes a request | See the org-scoped guarantee and exactly which steps are still manual before you plan a timeline. |
| A district procurement or IT officer | Trust & data, then How districts onboard | Check the custody register and the real onboarding steps before writing a requisition. |
| A building-level administrator inside a district | How districts onboard | Understand that your building sits inside one district organization, not a separate self-serve account. |
| A parent or guardian | Trust & data | See how a minor's record is handled: consent-gated and not publicly browsable, at any scale. |
| A reporter or analyst | What we are honest about | Check a claim against what we state plainly, then ask us to confirm it. |
Trust & data
Trust at district scale is mostly trust with data, spread across more people and more buildings than a single classroom. Rather than an absolute promise, here is the same scoped custody register question.company states, applied to a district organization.
A district's data is scoped to its owner_org_id. Every building inside that one district organization shares the same wall against every OTHER organization on the engine; there is no cross-organization read path.
The response row has no field for a name, email, IP address, account, fingerprint, or session, whether the reader answering it is in one building or fifteen.
Only the hour a response arrived is stored, enforced by a database check, so a precise moment cannot be matched against the moment a link went out.
Responses and question sets are held on infrastructure we run inside the estate. A district retains control of its own education records; we hold them to run the service, not to sell them.
A minor's name, face, and record are consent-gated and not publicly browsable, and consent can be withdrawn -- the standing rule across the estate, unchanged at district scale.
FERPA does not certify products, so we claim no certification and make no blanket compliance claim. The product is designed to support a district's obligations, and its data practices are documented for review.
What if a district needs an export or a deletion? Both exist today, by direct request: a district administrator can ask for a full export of that organization's question sets and responses, or for the organization's data to be deleted, and either is handled by a person on the team, not a self-serve button.
This describes the intended data model at district scale; it does not promise certified compliance, zero logging, or automatic deletion, and it claims no FERPA or COPPA certification.
Money, said plainly
There is no price on this page and no checkout on it. Nothing here takes a payment, captures a card, or converts anyone to a paid plan. Because there is no self-serve district tier today, pricing for a district is a direct conversation, not a table on this page.
When there is a published pricing structure for districts, it will be written down in one place, with the included capabilities and the terms, before any district is asked to pay. Until then, the only action here is to talk to us.
Isn't this just a way to avoid naming a number? No: the honest reason there is no price table is that self-serve district billing has not been built yet, and we would rather say that plainly than publish a number this page has no way to charge on its own today.
FAQ
No. There is no self-serve console with a per-building breakdown or bulk provisioning screen today. A district is set up as one organization directly with us, and we say that plainly rather than screenshot something that does not exist.
Yes. Every response and question set carries an owner_org_id column, and a district registered as one organization is walled off from every other organization on the engine by that column before any application-level check runs.
Not as a shipped connector today. We provision staff accounts by hand on request. If your district needs SSO or roster sync, tell us -- it would be built as a real integration, not implied here before it exists.
Not through a self-serve report today. The data model isolates your district's organization from every other organization, but it does not by itself produce a cross-building rollup view. Ask us if you need one.
The same way it is handled for one building: a response carries no identity column, its time is coarsened to the hour, data is stored on our own infrastructure, the district retains control of its records, and a minor’s record is consent-gated and not publicly browsable. We do not claim a FERPA or COPPA certification — the product is designed to support a district’s obligations.
No. Nothing here is AI. No model writes a question, scores a response, or grades a student, at any scale.
There is no price on this page and no checkout anywhere on it. Money is off here. Pricing for a district is a direct conversation, not a self-serve tier, because there is no self-serve district tier today.
question.company is the venture behind the whole family: who builds it, how it operates, whether it is funded. question.management is the operations page for a DISTRICT deciding how to run Question across more than one building: what the data model guarantees and what is still done by hand.
A district retains control of its own records, and export and account-closure procedures will be documented in the terms before adoption. We would rather write that down than promise a permanence we cannot honestly offer at this stage.
The evidence lines above name the exact table columns and constraints so those claims can be checked rather than believed. Any other claim on this page can be raised with us directly.
Contact
Whether you are a district administrator weighing rollout, a procurement officer checking the custody register, or a reporter checking a claim on this page, the door is the same one, and a person reads it.
Email [email protected]. There is no form on this page, no card asked for, and no student data requested — please do not send any.
You might worry this address queues into a ticketing system nobody reads. It doesn't: there is no ticketing system and no bot behind it, and a person on the team reads every message sent here.
Powered by question.technology · a Stanley Studios venture · money is off · nothing here is AI.
Question's response engine runs in production today, and every response is scoped to an organization column enforced by the database. That is the strongest true thing here.
There is no self-serve district admin console, no per-building breakdown screen, no bulk roster import, no SSO/roster-sync connector, and no cross-building rollup report. A district onboards by contacting us directly, and staff accounts are provisioned by hand.
There is no published SLA, no district logo wall, and no adoption count, because none exist yet and none may be invented to fill the space.
Money is off: no price and no checkout. Nothing here is AI. A minor’s record is consent-gated and not publicly browsable, and we claim no FERPA or COPPA certification.