Field Trip · approval, permission slips & chaperones · Early access · module-dark until enabled
Run a school field trip on the record — a two-stage approval, family permission slips, and chaperones on the shared roster, with the trip fee honest-off.
A field trip is not a generic form. It needs two people to sign off before it can happen, a signed permission slip for every student who goes, chaperones assigned and accounted for, and sometimes a small fee. Field Trip carries all four on one record — on top of the platform’s canonical approval substrate and the same student roster the rest of the platform already keeps — so who approved the trip, who is going, and who is watching are on the record, not scattered across paper forms and a group chat. The fee is consent-first and honest-off: it is recorded, never collected.
Field Trip is built, but it ships module-dark -- a tenant that has not enabled it is byte-identical to today -- and this product surface is early access, opening up gradually. This page describes how the module behaves; the honest next step is to ask about early access, not to sign anything.
What Field Trip is
At the centre is a plain idea: a trip is a record that has to pass through people before it happens. A teacher drafts it, an administrator clears it, families sign for the students who go, and adults are assigned to watch them. Field Trip is the module that carries that record end to end, on the platform’s canonical approval substrate — the same two-stage sign-off machinery the rest of the platform uses — rather than a second, private workflow that could drift out of step.
Around that record it does four jobs. It moves the trip through a two-stage approval (draft to submitted to approved, and approved only when both a teacher and an administrator have signed). It collects a family permission slip for each student, on the shared roster. It assigns chaperones and keeps who is watching on the record. And it can carry an optional fee — consent-first, recorded, and never charged.
It rides the shared roster. The students on a trip, the families who sign, and the staff who chaperone are the same people the rest of the platform already knows — not a re-typed copy of the student list that goes stale the moment a child transfers. And it is module-dark: until a school turns it on, Field Trip does nothing, and a tenant that has not enabled it is byte-identical to today.
Honestly, where the build is: the module is written, but it ships behind that module-dark switch, and this product surface is early access, opening up gradually. Where something is a plan rather than an open door, this page says so. The honest next step is to ask about early access.
Two stages, two people — how a trip gets approved
A trip does not become real because one person clicked a button. It moves through three states, and the last transition needs two different roles. The approval wall is fail-closed: a role that is not allowed to advance a trip is denied at the wall, before any of the trip’s own logic runs.
Draft — the teacher proposes
A teacher drafts the trip: where it goes, when, which class or roster it is for, and what it needs. In draft it is a proposal and nothing more — no permission slip is out, no chaperone is committed, no fee is recorded. It is the teacher’s to shape until they submit it.
Submitted — it goes up for review
Submitting hands the trip to an administrator. It is now on the record as awaiting an approval decision; a teacher cannot approve their own trip, and submitting is not approval. The trip waits here until an administrator acts, rather than sliding through on a single sign-off.
Approved — an administrator clears it
A trip reaches approved only when an administrator signs off on a submitted trip — two stages, two roles, teacher then admin. Approval is the point the trip becomes real: permission slips can go to families and chaperones can be committed. The record shows who approved it and when.
The wall denies the wrong role
The approval step is fail-closed on authorization. A sales representative, a student, or a parent is hard-denied at the wall — the trip cannot be approved by anyone outside the teacher-then-admin path. The check runs before the trip’s own logic, so a denied role reads nothing and changes nothing.
Permission slips, on the record instead of on paper
Every student who goes needs a family to say yes. Field Trip keeps that consent as a permission slip on the shared roster — the same student list the rest of the platform already keeps — so who is going is a fact on the record, not a stack of paper forms a teacher counts on the morning of the trip and hopes is complete.
Because the slip rides the shared roster, it stays honest as the roster changes. A student who transfers out is not still on a paper list in a folder; a student added to the class is visible as still needing a slip. The trip’s picture of who has consent is the roster’s picture, not a copy of it that drifted.
A permission slip is consent-first: it records a family’s decision for a specific student and a specific trip, and it is treated as private minors data. It is not a “we hold no data” claim — a permission slip IS data. The honest claim is that it is private minors data, kept behind the school’s row-level walls, owned by the school, and never sold. A family’s consent belongs to the family and the school, not to us.
Chaperones — who is watching, on the record
A trip needs adults, and it matters that the right adults are cleared to be there. Field Trip assigns chaperones on the shared roster, so who is supervising a trip is recorded next to who is going — not a name someone remembers on the bus. The assignment is a record the school can read back, before the trip and after it.
Chaperone assignment is fail-closed on clearance. Before a chaperone is committed, the module reads a recorded background-check status and denies by default when there is no current, valid clearance on file. No positive, in-date clearance means not assigned — the safe answer is the default, not the exception.
To be exact about what that is and is not: the module reads a screening; it does not run one. The background-check RUN itself is honest-off — it stays off until a licensed provider is provisioned to perform it. We would rather read a recorded clearance and be honest that the run is not ours yet than imply this page performs a background check it does not. When the check run is real, it will be labelled real.
The trip fee is honest-off
Some trips carry a small cost, so Field Trip can record an optional fee — but it does not collect it. The platform does not process payments yet. The fee is consent-first and the pay-intent record is an append-only audit: it captures that a fee was set and that a family intends to pay, and that is where it stops. No card is taken, no charge is made, no money moves. The fee is recorded, never collected.
This is honest-off by construction, not by a setting we forgot to turn on. There is no checkout on this surface, no cart, and no charge rail behind it. An approved trip with a fee holds the fee as a recorded intent; it never advances to “paid” because there is no collect step to advance to. When live payment is real, it will be a deliberate, separate, opt-in decision — and this page will say so plainly rather than let a fee imply a transaction that did not happen.
The append-only audit matters for exactly this reason: it lets a school see what was intended without pretending anything was settled. A fee on the record is a fee on the record — not a receipt.
Module-dark until a school turns it on
Field Trip ships module-dark. Until a tenant enables it, the module does nothing at all — and a tenant that has not enabled it is byte-identical to today. Nothing about a school’s existing experience changes because this module exists; it appears only when a school deliberately turns it on.
When a school does enable it, every action still sits behind a fail-closed role gate. The teacher-then-admin approval path, the permission slips, and the chaperone assignments are all authorized before they run, so enabling the module opens the capability without opening the wall. Enabling is a decision the school makes; it is not a default that arrives switched on.
That is the honest shape of the build: a real module, held dark, gated when live, and opened one school at a time. This page describes the module’s behaviour under that posture — not a finished product open to everyone today.
Private by default, and honest about the data
A permission slip and a chaperone assignment are records about children and the adults who supervise them, so they sit on the platform’s student-data lane. They stay in our own private system, are owned by the school, and are never sold to or shared with outside companies, advertisers, or third parties. A minor student’s data is consent-gated and is never made public.
Because the trip rides the shared roster, it does not create a second, sloppier copy of the student list. The people on a trip are the people the platform already knows, referenced the same way, behind the same row-level walls — a family sees its own child, staff see students through the school’s student-data rules, and a support session scoped to a school reads only what that scope allows.
To be plain about it: this is not a “we hold no data” claim. A permission slip and a chaperone assignment ARE data. The honest claim is that they are private minors data, kept behind the school’s walls, school-owned, consent-gated, and never sold — and that a family’s consent can be withdrawn. This module handles no photos and no face templates; it is the trip record, not a gallery.
Common questions
Can I use Field Trip right now?
Not generally, yet. The module is built, but it ships module-dark — a school that has not enabled it is byte-identical to today — and this product surface is early access, opening up gradually. No school is running a live trip on fieldtrip.software yet. This page describes how the module behaves; the honest next step is to ask about early access.
Why does a trip need two approvals?
Because one sign-off is not the standard a real trip should clear. A trip moves from draft to submitted to approved, and it reaches approved only when both a teacher and an administrator have signed — teacher then admin, two roles. A teacher cannot approve their own trip, and submitting is not approval. The record shows who approved it and when.
Who can approve a trip — and who cannot?
Only the teacher-then-admin path advances a trip. The approval step is fail-closed on authorization: a sales representative, a student, or a parent is hard-denied at the wall. The check runs before the trip’s own logic, so a denied role reads nothing and changes nothing. There is no side path that approves a trip around the two stages.
How do permission slips work?
A permission slip records a family’s consent for a specific student on a specific trip, and it rides the shared roster — the same student list the rest of the platform keeps. So who has consent is a fact on the record rather than a stack of paper forms, and it stays honest as the roster changes. A slip is treated as private minors data, kept behind the school’s walls and never sold.
Do you run background checks on chaperones?
No — we read one, we do not run one. Chaperone assignment reads a recorded background-check status and denies by default when there is no current, valid clearance on file. The background-check RUN itself is honest-off: it stays off until a licensed provider is provisioned to perform it. The engine reads a screening; it does not perform one, and this page does not claim otherwise.
Does the trip fee actually charge a card?
No. The platform does not process payments yet. The optional fee is consent-first and honest-off: the pay-intent record is an append-only audit that captures that a fee was set and a family intends to pay, and stops there. No card is taken, no charge is made, no money moves — the fee is recorded, never collected. There is no checkout on this surface.
What happens to a school that does not turn Field Trip on?
Nothing. Field Trip is module-dark: a tenant that has not enabled it is byte-identical to today. The module appears only when a school deliberately turns it on, and even then every action sits behind a fail-closed role gate. Enabling is the school’s decision; it is never a default that arrives switched on.
How is trip data handled?
Permission slips and chaperone assignments are private minors data on the student-data lane: they stay in our own private system, are owned by the school, are consent-gated, and are never sold or shared with outside companies. A family’s consent can be withdrawn. This module handles no photos and no face templates — it is the trip record, not a gallery.
How do we get started?
By a conversation, not a signup. Field Trip is in early access and ships module-dark. A conversation shows the current state honestly — how the two-stage approval moves, how permission slips and chaperones ride the shared roster, and exactly what is built versus honest-off, including the fee and the background-check run. There is no pricing commitment here. Ask about early access.
Related surfaces
Field Trip is the trip record. These adjacent destinations cover the wider platform and the neighbouring records a trip touches.
homeroom.software
The flagship platform brand home and the wider product family Field Trip belongs to. The full picture of the platform and every module on it — including the approval substrate this trip record rides.
busfleet.software
The owned school-transportation record — the bus that carries the trip. Route and vehicle assignments on the same roster, kept in sync from the school’s system of record. An adjacent record, not the same product.
middleschool.software
The middle-grades front door — the stage where a student first joins a trip with the safety rails on. A sibling stage-front that shares the same activity and chaperone rails, kept as a separate product.
What this page is and is not claiming
Field Trip — a school field-trip module with a two-stage teacher-then-admin approval, permission slips and chaperones on the shared roster, and an optional consent-first fee — is built, but it ships module-dark and this product surface is early access, not yet generally available. This page describes the module’s design and behaviour; it does not present early access as a finished, open product. There are no invented stats, testimonials, or trip counts on this page, and no school is running a live trip on it yet. The trip fee is honest-off: the platform does not process payments yet, and the fee is recorded, never collected. Chaperone screening reads a recorded clearance; the platform does not run a background check. Privacy is stated honestly: permission slips and chaperone assignments are private minors data behind the school’s walls, not a claim that no data exists. No competitor brand names appear on this page. The software records and gates; a human still signs the trip off. The honest next step is to ask about early access.