question.group · the multi-organization address of the question.* family · Powered by question.technology
Several independent organizations can adopt Question together without pooling their data. A group is not a row in this system — every response is anchored to exactly one owner, enforced by the database — and this page names what that does and does not buy you.
There is no group parent row, no cross-owner rollup report, and no group billing, 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.
Provable now
The honest answer is that a group is not a row. Every question set and every response is anchored to exactly one owner, and a database constraint enforces that it is exactly one. For a collection of independent organizations, that is not a limitation to apologise for — it is the property that lets members share a contract without sharing a database. Each card below names the constraint or symbol that enforces it, so the claim can be checked rather than believed.
Enforced by the database today
A question set or a response belongs to exactly one owner: one studio organization, or one school. Not both, and not neither. A database CHECK enforces it, so a row that tried to belong to two members of a group would be rejected by the database before any application code had an opinion about it.
Evidenceck_qt_*_exactly_one_owner (migration 1140): (owner_org_id IS NOT NULL) <> (owner_school_id IS NOT NULL).
Enforced by the database today
A member's owner anchor is resolved server-side from the authenticated session. There is no field in any request body or query string that names an owner, so one member of a group cannot address another member's data by guessing or editing an identifier.
EvidenceanchorOf(scope) returns disjoint anchors ({ownerOrgId, null} or {null, ownerSchoolId}); pinned in question-technology-authoring.gate.test.ts.
Enforced by the database today
Per-owner row-level security is the backstop, and the route still scopes every write to the caller's own anchor rather than leaning on it. Two independent walls have to fail together for one member of a group to read another's responses.
EvidenceRLS: owner_org_id = current_studio_id() OR owner_school_id = ANY(current_school_ids()); the route owner-scopes every write regardless.
Enforced by the database today
Every member composes from the same closed set of answer shapes the database itself enforces: open text, a 1-to-5 scale, single choice, ranking, and a forced-choice trade-off. Choice, ranking and conjoint each need at least two distinct options; text and scale carry none. No member gets a private dialect.
EvidenceQT_QUESTION_TYPES = text|scale|choice|ranking|conjoint (ck_qt_question_type); ck_qt_question_choice_has_options widened in migration 1164.
Enforced by the database today
There is no per-owner type-registry table, and the route that would create one answers 501. That is deliberate here: a closed vocabulary is why one member's export is readable by another member's analyst without a translation step or a private schema.
EvidencePOST /question-types -> 501; the vocabulary is the built-in TYPE_CATALOG, not an insertable per-owner row.
Enforced by the database today
There is no delete route. A question or a set is retired by moving it to an archived status, so a response already attached to it never dangles and a member leaving a group cannot silently strip history another member relied on.
EvidenceNo DELETE route by design (the 1085 forms-builder rule); retire via PUT status archived.
These properties do not weaken as a group grows. The constraint that separates two members is the same one that separates a member from an unrelated organization on the engine.
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.management is one district: a single owner spanning several buildings inside it.
question.company is the venture behind the family: who builds it, how it operates, and its honest stage.
question.group — this page — is the multi-organization facet: several INDEPENDENT members, each its own owner, with no parent above them. If you are one district with many buildings, question.management is your page, not this one.
Powered by question.technology. A group pays for the underlying platform and the capabilities its members select, not repeatedly for the same engine wearing different brands.
Radically legible about our stage
A consortium page is the easiest place to imply a hierarchy the schema does not have. 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 group account with member organizations nested under it | There is no group parent row and no consortium object. Each member is its own owner anchor, and the group exists in our agreement with its members, not in the database. We would rather say that than draw an org chart the schema does not have. |
| A consortium dashboard comparing member to member | There is no cross-owner aggregate report. The owner anchor isolates members from each other by construction, which is exactly why no rollup view falls out of it for free. If a group wants a comparison, that is a request to us and a conversation about what each member consents to share. |
| A platform-staff console rebadged as a group report | There is a cross-owner feed, and it is platform-staff only, behind the owner gate. Calling it a group feature would be selling you a console you will never be given a login to, so we name it and rule it out instead. |
| Group billing with pooled seats and per-member invoicing | There is no group billing, no seat pool, and no per-member invoice run. Money is off on this page entirely. Commercial terms for a group are a direct conversation, because the billing machinery a group would need has not been built. |
| One sign-on across every member organization | There is no shipped SSO or roster-sync connector for Question. Staff accounts are provisioned by hand on request, per member, and that is real work on our side rather than a switch we decline to flip. |
| A member roster, logo wall, and adoption count | There are no member logos or adoption counts on this page, because none are citable, and inventing one would be exactly the thing this page exists to avoid. |
Naming the gaps is how the provable parts above stay believable. A group that reads this page knows exactly what it is buying and exactly what still requires an email.
How a group adopts, today
There is no signup wizard for a group, and step two is the one that surprises people. This is the real process, in the order it actually happens, so a director can plan against reality rather than an assumed hierarchy.
Step 1
One conversation for the whole group, rather than each member starting from the beginning. There is no group signup form, because there is no group object to create.
Step 2
Every participating organization gets its own owner anchor. This is the step that people expect to be a nested hierarchy and is not one: the members sit beside each other, not underneath a group row.
Step 3
We provision staff accounts on request for each member. There is no SSO or roster-sync connector shipped, so this is manual work on our side rather than an automated import.
Step 4
Each member authors and runs question sets inside its own anchor, using the same five answer shapes as every other member, with no visibility into any other member's responses.
Step 5
If the group wants a comparison across members, that is a request to us and a conversation about what each member agrees to share. It is not a button, and it is not something we can do quietly on the group's behalf.
The edge we will not smooth over
Groups are the situation where one person belongs to more than one member organization, so this is the edge most likely to affect a group and least likely to appear on a page like this one. It is flagged in our own source, and it is named here for the same reason.
If one person's session carries more than one school, the write anchor is the first school on that session. They do not get to pick which member organization a new question set is authored under, and there is no chooser in the product today.
The database backstop admits reads for any school on that session, while the write anchor stays singular. So a shared staff member can see across their own memberships but cannot author across them, and those two behaviours are deliberately not the same shape.
A group is the exact situation where shared staff are common, so this is the edge most likely to bite a group and least likely to appear on a page like this. It is flagged in our own source, and leaving it off this page would make the rest of the page less believable, not more.
If a chooser for the write anchor matters to your group, tell us. It would be built as a real change to the authoring gate, and we are not going to describe it here as though it already exists.
A multi-organization page is read by a consortium director, a member organization worried about being absorbed, a data-protection officer, 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 cooperative or consortium director | What a group is here, then What we are honest about | See that the isolation between your members is a database constraint, then read what a group does not get. |
| An education service center evaluating a joint purchase | How a group actually adopts this | Walk the real steps, in order, so a timeline is planned against what happens rather than an assumed console. |
| A member organization worried about being absorbed | Trust & data, then The edge we will not smooth over | Check the wall between members, and the one place a shared staff account behaves asymmetrically. |
| An IT or data-protection officer | What a group is here, then Trust & data | Read the exact constraints and the scoped custody register before signing anything. |
| A parent or guardian at a member organization | Trust & data | See how a minor's record is handled: consent-gated and not publicly browsable, unchanged by the group. |
| 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 in a group is mostly trust between its members, not only trust in us. Rather than an absolute promise, here is the same scoped custody register the rest of the family states, applied to a collection of independent members.
The owner anchor separates every member of a group from every other member with the same constraint that separates them from an unrelated organization. Joining a group does not lower the wall between its members.
The response row has no field for a name, email address, IP address, account, fingerprint, or session, at any member and at any size of group.
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.
The authoring routes admit staff only. Students and parents were excluded from all ten of them by a tightening landed on 2026-09-04, so a group's question sets cannot be edited by a session that merely carries a school id.
Responses and question sets are held on infrastructure we run inside the estate. Each member 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. That is the standing rule across the estate and it does not loosen because several organizations bought together.
FERPA does not certify products, so we claim no certification and make no blanket compliance claim. The product is designed to support each member's obligations, and its data practices are documented for review.
What if a member needs an export or a deletion? Both exist today, by direct request: a member can ask for a full export of its own question sets and responses, or for its data to be deleted, and either is handled by a person on the team rather than a self-serve button. A member does not need the group's permission to ask.
This describes the data model at group 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. There is no group billing, no pooled seat count, and no per-member invoice run, so terms for a group are a direct conversation rather than a table.
This page offers no group price, checkout or payment action. Contacting the team does not purchase seats, create a subscription or issue an invoice through this page.
Isn't this just a way to avoid naming a number? No. The honest reason there is no price table is that the billing machinery a group would need — pooled seats, per-member invoicing — has not been built, and publishing a number this page has no way to charge on would be worse than saying so.
FAQ
Not as a database object. Each member organization is its own owner, and the group exists in our agreement with its members rather than as a parent row above them. We would rather tell you that than show an org chart the schema does not have.
No. Every question set and response is anchored to exactly one owner, enforced by a database CHECK, and the route scopes every write to the caller's own anchor with row-level security underneath it. Two independent walls would have to fail together.
Not through the product today. The owner anchor isolates members from each other by construction, which is precisely why no cross-member rollup falls out of it. If your group wants a comparison, ask us, and it becomes a conversation about what each member consents to share.
No, and it is worth being blunt about it. That feed is platform-staff only, behind the owner gate, and no member of a group is given a login to it. Presenting it as a group feature would be selling you a console you cannot reach.
Their reads and their writes behave differently, and we would rather you heard it here. The write anchor is the first school on their session, so they cannot choose which member a new question set is authored under; the database backstop still admits reads for any of their schools. There is no chooser for this in the product today.
Not as a shipped connector. We provision staff accounts by hand on request, per member. If your group needs SSO or roster sync, tell us and it would be built as a real integration rather than implied here before it exists.
Five answer shapes, enforced by the database: open text, a 1-to-5 scale, single choice, ranking, and a forced-choice trade-off. Choice, ranking and conjoint each need at least two distinct options. Every member gets the same five, so no member ends up with a private dialect another member cannot read.
Both are handled by a person on the team, by direct request: an export of that member's own question sets and responses, or deletion of that member's data. Nothing is hard-deleted by the product itself, because there is no delete route; a question set is retired to an archived status so an attached response never dangles.
The same way it is handled for one organization: a response carries no identity column, its stored time is coarsened to the hour, authoring is staff-only, data sits on our own infrastructure, each member retains control of its records, and a minor’s record is consent-gated and not publicly browsable. We claim no FERPA or COPPA certification — the product is designed to support each member’s obligations.
No. Nothing here is AI. No model writes a question, scores a response, or grades a student, for any member of any group.
There is no price on this page and no checkout on it. Money is off here. There is no group billing, no seat pool, and no per-member invoice run, so terms for a group are a direct conversation rather than a table.
question.management is one district: one owner, many buildings inside it. question.group is several independent organizations: many owners, and no parent above them. The difference is a database boundary, not a change of tone.
The evidence lines above name the exact constraints, symbols, and migrations, so those claims can be checked rather than believed. Any other claim here can be raised with us directly.
Contact
Whether you are a consortium director weighing a joint purchase, a member organization checking the wall between you and your peers, 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 question set and response is anchored to exactly one owner by a database constraint. That is the strongest true thing here, and it is the whole basis for offering this to a group at all.
There is no group parent row, no consortium object, no cross-owner rollup report, no group billing or seat pool, and no SSO or roster-sync connector. A group adopts by contacting us directly, and staff accounts are provisioned by hand, per member.
The cross-owner feed that does exist is platform-staff only and is not a group report. A shared staff account writes to its first school and reads across all of them, and we would rather print that asymmetry than let a group discover it.
There is no member logo wall and no adoption count, because none exist to cite 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.