Preset · the module configuration layer for a network of schools · a description, not a console
In a network of schools, someone decides which schools reach which parts of the platform. Preset is the page that says how that decision is made, and who cannot undo it.
A district signs one agreement and then runs forty buildings that are not the same as each other. One high school runs athletics and a storefront; one elementary runs neither. A charter network wants a module switched off across every campus and wants it to stay off when a well-meaning building administrator finds the switch. That decision — which node reaches which module — is not a preference pane. It is the boundary the whole platform is enforced against, and it is the only thing this domain is about.
The inheritance rule described below is in the database and the gate that reads it is what the platform’s routes are written against. This domain serves this page and nothing else: no sign-in, no console, no configuration written from here, no charge taken here. Both halves of that sentence are said before anything else on the page.
What this page refuses to claim, in the present tense
You cannot sign in here. preset.network resolves to this page and stops. There is no console on this domain, no account is created here, no key is issued here, and no configuration row is written from here. Today a change to a node’s module configuration is an operator action against the platform’s own API, requested in a conversation with a named person. That is the whole mechanism, and describing it as anything more would be a promise this domain cannot keep.
There is no saveable, re-appliable named preset. The domain is called Preset and the obvious reading — save a bundle once, stamp it onto forty schools in one action — is an intention, not a table. What exists is one row per node per module. Forty schools is forty rows. The bundle has its own section further down, headed as an intention, because the moment it is described in the same voice as the built part it stops being honest.
Money is off here. The configuration row does carry price columns, and it would be easy to show them as a pricing table. The schema annotates them as the catalogue or display price and never the charged amount, and annotates the model itself as display and configuration only with no charge path. So there is no pricing table, no checkout and no live charge on this page, and the reason is a property of the data model rather than a preference.
This page makes no artificial-intelligence claim in either direction. Module configuration is a decision a person makes and a gate enforces. Nothing here is inferred, suggested or scored.
What is built today, named by the thing it actually is
Each card below corresponds to a table or a module in the platform that a reader could ask us to show them. None of them describes a screen, because the screen is the part that does not exist.
In the schema today
A module registry, not a feature list
Every module the platform can gate has an identity row: a stable code that other tables key against, a display name, whether it is active, and — the part that matters to a network — whether a node is permitted to toggle it at all, and whether its catalogue price may be overridden below the top tier. A module marked not-togglable is not a module a building administrator can reach, whatever else is configured beneath it.
In the schema today
One dated decision per node, per module
The configuration row names a tier, a node (a partner organisation or a school), and a module code, and records that node’s decision. It carries an effective-from and an effective-until, an active flag, and a source field recording how the row got there. A configuration change is therefore a dated, attributable record rather than a mutated setting, which is what a district needs when it is asked in June what was switched on in October.
In the schema today
Four tiers, and a rank that is not the obvious one
The tier enum is platform, studio, rep, school. The resolver order is documented on the model itself and deliberately puts rep above studio, which is not the order the enum is written in — a distinction that exists because a reseller relationship and a studio relationship are different kinds of authority over the same school. The comment says so explicitly so nobody re-derives the wrong order from the enum.
In the API today
The gate the rest of the platform is written against
A single entitlement check stands in front of the routes a module unlocks, and the platform’s route surface calls it rather than each route inventing its own test. Program-level entitlements delegate to the same module check first, so there is one place where the answer is decided. Configuration that no route consults is decoration; this configuration is the thing requests actually meet.
In the API today
Deny-by-default, with its own gate file
The strict posture is not a slogan: it is a named module in the API with exported predicates for whether deny-by-default is on, what strictness a given plan resolves to, and whether a leaf is covered — and it ships next to its own continuous-integration test file for the catalogue. A fail-closed default is only worth anything if something goes red when it stops being fail-closed.
In the schema today
The network shape it hangs off
Schools belong to a district, and a district may carry a white-label parent organisation. That is the tree the four tiers resolve down. It is worth saying plainly that the tree is small and boring by design: a configuration layer that invents its own org chart is a second source of truth about who a school reports to, and that is a problem, not a feature.
The inheritance rule, which is the actual product
Almost every configuration system a district has met is two-valued: a switch is on or it is off, and whoever touched it last wins. That is exactly the model that fails a network, because there is no way to express I have not decided, ask my parent and no way to express this is decided above you and you may not revisit it.
The configuration column here is three-valued, and the three values are the whole design:
- Unset — inherit. The node has expressed no opinion. The answer falls through to the plan and the catalogue default. This is the value most rows should have, and a network where every row is explicitly set has usually lost track of why.
- Set on, or set off — this node’s own decision. Recorded against that node, dated, with a source. A school that turned something on can be shown the row that did it.
- Set off at the top tier — a stop the tiers beneath cannot undo. Not a strong default, not a recommendation: a node below cannot re-enable it. This case is deliberately asymmetric, because the failure a network fears is a building-level override quietly re-opening something a district closed on purpose.
That asymmetry is the part worth checking us on, and it is worth being precise about where it lives. It is a documented property of the column in the schema, next to the resolver order, rather than a rule written in a runbook that a later change could contradict without anything going red. When we say a district-level stop holds, the sentence has a column behind it.
One honest limit on that claim: the rule is expressed in the data model and the gate reads the model. This page does not claim a district can watch itself being enforced from a dashboard on this domain, because there is no dashboard on this domain. What a district can do is ask us to show the row.
Who this is for, and what their first week actually looks like
The reader this page is written for is the person in a district or a charter network who will be asked, in front of a board, which of their schools can reach what. Usually a chief technology officer, a director of operations, or the one assistant superintendent who ended up owning the vendor relationship. Not a teacher; not a family. If you are a building administrator, the honest answer is that this page describes a decision made above you.
Their first week with us is deliberately unglamorous, and here is the whole of it:
- Day one, an inventory. We list the modules that exist and, against each, whether it is togglable by a node at all. Several are not, and the reason is usually that they are structural rather than optional. Knowing which is which is most of the value, and it is a conversation, not an onboarding wizard.
- Day two, the stops. The network names the things it wants closed everywhere and closed durably. Those become top-tier decisions, and we say plainly which ones are structurally capable of being that and which ones are not.
- The rest of the week, the exceptions. The high school that runs athletics, the elementary that does not, the one campus with its own arrangement. Each becomes a dated row against that node with a recorded source, so the exception has a paper trail from the day it is made.
- The end of the week, a written statement of the boundary. Which node reaches which module, and which of those are stops rather than preferences. That document is what a board actually asks for, and producing it is the point of the exercise.
What does not happen in week one: nobody is given a console on this domain, because there is not one. The work is done by an operator against the platform’s API with the network in the room. That is slower than a self-serve screen and we are not going to describe it as anything else.
The objections a network actually raises
These are the six we have had to answer, written as they were asked rather than as they would be easiest to answer.
This is a settings table. Why is it a product, let alone a domain?
Because in a single school it is a settings table and in a network it is the compliance boundary. The question a board asks is not which switches exist, it is who decided and who can change it back. A two-valued switch cannot answer either half. Once the answer has to survive four tiers, a dated record and an override that genuinely holds, it stops being a preference pane and becomes the thing every other claim we make is scoped by.
Our student information system already has permissions. Why is this separate?
Permissions answer what a person may do. This answers what a school may reach. They fail differently: a correct permission model still lets a building administrator turn on a module the district closed, because the administrator genuinely has the role. Module configuration is the tier above the role, and collapsing the two is how a district ends up unable to explain a capability that appeared without anyone doing anything wrong.
You have described a database. Show me it is enforced.
That is the right challenge, and the answer is that the routes are written against one shared entitlement check rather than each route testing for itself, and program-level entitlements delegate to that same module check first. Configuration nothing consults is decoration. We would rather be asked to show the call than be believed on the strength of a diagram.
What happens on the day you get this wrong and close something we needed open?
The failure is visible rather than silent: a request that meets a closed gate is refused, not quietly degraded, and the row that closed it is dated and attributable to a source. We would rather a network hits a refusal it can trace in one query than discovers six months later that a capability was half-on. A fail-open default would make that week smoother and the audit impossible.
You are asking us to trust the interesting parts to a conversation with your staff.
Yes, today, and that is a real cost rather than a feature. A self-serve console is the obvious answer and it does not exist, so the honest trade is that changes are slower and every change has a person’s name on it. A network that needs same-day self-serve control of its own module configuration should weigh that against us now, not discover it in October.
Is any of this a way to sell us more modules?
The configuration row does carry catalogue price fields, and pretending otherwise would be worse than naming them. What they are not is a charge: the schema annotates them as display and configuration only, with no charge path, and a charge is decided server-side elsewhere. This page sells nothing and takes nothing. If a module has a price, that is a conversation with a person, not a table on a marketing page.
An intention, labelled as an intention: the named bundle
This section is about something that does not exist. It is kept separate, and headed as an intention, so that nothing in it can be mistaken for the built part above.
The domain is called Preset, and the reading the name invites is a bundle: a named set of module decisions, saved once, applied across a network in one action, versioned, and diffable against what a school is running now. That is a genuinely good idea and it is not in the schema. What is in the schema is one row per node per module, which means a forty-school network is forty decisions and forty rows.
We are naming the intention rather than hiding it, and we are naming what would have to be true for it to exist: a bundle identity the rows could point at, a rule for what happens when a bundle is re-applied over a node that has since made its own decision, and an answer for whether re-applying a bundle can re-open something a top-tier stop had closed. That last question is the hard one, and it is the reason this is a design problem rather than a screen.
Until those are answered, the honest description of Preset is the layer, not the bundle. A network deciding today should decide on the layer.
The data this layer touches, and the data it stands in front of
What a configuration row holds: a tier, a node identifier — a partner organisation or a school — a module code, a decision, some dates, and a source. That is the entire record. No student, no guardian, no roster, no image, no grade. The schema says this about itself in the model’s own comment, which is the right place for it, because a comment on the model is read by the next person to change it.
What it stands in front of: a good deal of student data, which is exactly why the layer matters. The surfaces that hold a minor’s record sit behind the entitlement check this configuration feeds. A school that has not been granted a module does not reach the data behind that module; the boundary is enforced at the gate rather than in the interface.
The rule this platform does not bend: a minor’s data is consent-gated and never public. Module configuration cannot grant an exception to that, and nothing on this page should be read as a way to widen it — opening a module opens a capability, and the consent gates inside that capability still apply, unchanged, to every family in it. A configuration switch is not a consent.
Nothing on this domain collects anything. This page carries no form, sets no cookie, and asks for nothing. The only outbound path is a link to a contact page on another host.
Where this sits among our other school-network sites
Preset belongs to a family of sites about how a network of schools works rather than what happens inside one classroom. The family shares a voice and a typeface and very little else, on purpose: each site is its own brand, and a reader should be able to tell them apart by what they refuse as much as by what they offer.
Two boundaries worth stating so nobody has to guess. Preset is not a district operations pitch — it does not describe scheduling, attendance, transport or any module’s own behaviour, and a reader who wants those should go to the site for the module in question. And Preset is not a plans-and-pricing page: it is about which modules a node reaches, which is a different axis from what anything costs.
The one axis Preset owns is reach. If a question can be phrased as “can this school get to that”, it is ours. If it can be phrased as “what does that do once they are in it”, it is not.
Money, in the present tense
No price is shown on this page, no plan is offered, no checkout exists here and no live charge is taken here. That is a statement about today, not a schedule.
The reason is worth giving rather than asserting, because a page that says money is off without saying why is asking to be trusted. The per-node configuration row does carry price and revenue-share fields, and it would be trivially easy to render them as a rate card. The schema annotates each of them as the catalogue or display figure and never the charged amount, and annotates the model as display and configuration only with no charge path. Charging is server-authoritative and decided elsewhere. Rendering those fields as a price a reader could act on would be putting a number in front of a school that no system on our side has agreed to honour.
What a module costs a network, if anything, is worked out in a conversation with a person. We are a for-profit vendor and we are not pretending otherwise; we are declining to quote from a table that is explicitly not a quote.
Questions we are actually asked
Can I sign in here and change my district's settings?
No. preset.network serves this page and nothing else. There is no sign-in on this domain, no console, no key issued here, and no configuration row is written from here. A change to a school’s module configuration is an operator action against the platform’s own API, and it starts with a conversation.
What part of this is actually built?
The data model and the gate. A module registry holds each module’s identity, whether a node is permitted to toggle it at all, and whether its catalogue price may be overridden. A per-node configuration row records one node’s decision about one module, dated, with a from and an until. And the platform’s route surface is written against a single entitlement check, so the decision in that row is what a request actually meets.
What does inheritance mean here, exactly?
Four tiers — platform, rep, studio, school — and a three-valued switch. A row that says nothing inherits: the answer falls through to the plan and the catalogue. A row that says on or off is that node’s own decision. And one case is deliberately not symmetric: an off set at the platform tier is a hard stop that no tier beneath it can turn back on. That asymmetry is the safety property, and it is written into the column, not into a policy document.
Can I save a preset and stamp it onto forty schools at once?
Not today, and that is the honest shape of the gap. The rows are per node and per module: forty schools is forty decisions, each one dated and attributable. A named bundle saved once and applied across a network in a single action is the intention behind this domain’s name. It is written on this page as an intention, in a section that says so in its own heading, because it does not exist in the schema.
Does a configuration row hold anything about a student?
No. The configuration row identifies a node and a module — a partner organisation or a school, and a module code. It holds no student, no guardian, no roster and no image. The schema records this about itself in the model’s own comment. The surfaces that do touch a student record are the ones the entitlement check stands in front of; a school that has not been granted a module does not reach the data behind it.
There are price columns on that row. Am I being charged?
No, and the schema is explicit about why. Those columns are annotated as the catalogue or display price and never the charged amount, and the model itself is annotated display and configuration only, with no charge path. A charge is server-authoritative and happens elsewhere. Money is honest-off on this page: no pricing table, no checkout, no live charge.
Why give a whole domain to a settings layer?
Because in a network of schools it is not a settings screen, it is the boundary. Which schools reach which parts of the platform decides what a principal sees, what a family is asked for, and what a vendor of ours is permitted to touch. A district that cannot name that boundary cannot answer for it. Preset is the page that names it in one place, in plain terms, with the mechanism attached.
The next concrete step
There is one, and it is small. Send us the list of your schools and the shape of your network — which buildings, which are grouped, and whether a reseller or a studio relationship sits between us and any of them. We come back with the module inventory marked up against it: which modules are togglable at a node at all, which of the stops you want are structurally capable of holding, and which of your exceptions become dated rows against a named school.
That produces the written boundary statement described above. It does not produce an account, because there is no account on this domain, and it does not produce an invoice, because nothing here charges. It produces a document a board can read.
What this page is, and is not, claiming
Preset names one layer: which node in a network of schools reaches which module, and how that decision inherits. The parts described as built are a module registry, a dated per-node configuration row with a three-valued switch whose top-tier off cannot be undone below it, and a single entitlement gate the platform’s routes are written against. The parts described as absent are absent today: there is no console, no sign-in and no configuration written on this domain, and there is no saveable named bundle in the schema — that is an intention and has its own section saying so. Money is off here and the schema is the reason: the price fields on that row are annotated as catalogue figures and never a charged amount. Minors’ data is consent-gated and never public, and a configuration switch cannot grant an exception to that. This page makes no artificial-intelligence claim. There are no invented adoption numbers, district counts or testimonials on this page, and no competitor is named.