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 platform.
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 packages/shared/src/question-technology.ts.
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.
Adult organizational planning / a manual example
A useful organizational request distinguishes the work someone wants from the work another person has agreed to do. Those statements often look similar in a short planning note. Please review the brief names a proposed task; Lee has agreed to review two questions names a narrower agreement. Neither statement establishes that the review is complete. Keeping the three stages separate gives colleagues an accurate starting point without making them reconstruct the history behind a reassuring word such as handled.
Consider an original fictional exercise involving Dana and Lee, two adult organisers of the Hillgate staff learning group. Dana is preparing a one-page brief for an adult discussion session. Lee has agreed to read two agenda questions for clarity. All people, documents and arrangements in this exercise are invented. This is a manual planning method to examine alongside the page's organizational discussion, not a description of Question carrying out the work or an invitation to treat the specimen as an operating service.
Dana's initial request combines several kinds of work: check the session details, improve the agenda questions and declare the brief ready. Bundling them makes the request sound efficient, but it hides who can resolve each part. Lee can read the wording without knowing which session time Dana intends to use. A clear note separates those responsibilities before someone interprets a narrow review as confirmation of the whole document. The relevant unit is the agreed task, not the length of the document.
In the fictional arrangement, Dana remains responsible for assembling the brief and resolving its session details. Lee accepts only the wording review of questions one and two. This named responsibility is a premise of the example, not a rule about who holds organizational authority. The useful habit is to name a person for a particular decision and preserve that limit. Calling Lee the reviewer does not also make Lee the owner of the timetable, the final editor or the person who decides whether the session proceeds.
Dana has draft A, labelled 18 May, with a 14:00 start, and draft B, labelled 18 May, with a 14:30 start. Both contain the same two agenda questions. No supplied note explains which time is intended. Lee has agreed to examine the two questions for clarity. Lee has annotated question one; question two remains unread. Dana has not resolved the time or assembled a final brief.
Please check the brief and get everything ready. Lee is reviewing it, so the details are covered.
Proposed scope: review the session details and both agenda questions. Agreed work: Lee will examine the wording of questions one and two only. Work performed: Lee has annotated question one; question two is unread. Dana owns the brief and the unresolved choice between 14:00 in draft A and 14:30 in draft B. No final brief is established by this note.
The revised specimen gives each statement a different job. Proposed scope preserves Dana's original intention, so the narrower agreement is visible rather than silently substituted. Agreed work records what Lee actually accepted. Work performed names the single annotation that exists in the fictional inputs. Keeping the unread question beside the completed annotation prevents a hurried reader from turning partial progress into a finished review. The note remains useful even if no further work happens immediately.
The annotation itself also needs a modest description. Suppose question one asks, Which arrangement works best? Lee writes, Name the arrangement and the purpose being compared. That is a wording observation, not a recommendation for one arrangement. Dana can use it to revise the question, but an annotation alone does not mean a revised version exists. If Dana changes the wording, the next note should identify that actual revision. It should not skip from a suggestion to a claim that every question is settled.
The competing times are a specific unanswered question. They are not a reason to treat the whole brief as unknowable, and they are not a detail Lee can resolve by choosing the later draft for convenience. The worksheet supplies no basis for preferring either time. Dana can retain the wording work while stopping any statement that presents one time as confirmed. This separates useful partial work from a conclusion the available material cannot support.
A sensible stopping point is therefore narrow: do not describe the brief as final while its start time is unresolved, and do not describe the second question as reviewed while it remains unread. The example does not prescribe a general approval procedure. It shows why the writer's next sentence must stay within the facts already given. If Dana discovers another adult owns the time decision, Dana should name that relationship accurately instead of assuming that assembling the brief confers every decision within it.
The output is a human-authored scope note. A colleague reading it can identify the broad request, Lee's smaller agreement, one completed annotation and two remaining items: the unread question and the unresolved time. The note does not perform the review, resolve the schedule or establish a final document. It makes those distinctions available for the next conversation without presenting preparation as completion.
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.
This page offers no district price, checkout or payment action. The contact link starts no purchase or subscription, and an inquiry is not a billing arrangement.
Isn't this just a way to avoid naming a number? No: self-serve district billing is not built. There is no price table or payment action for a district to use on this page.
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.