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.
What makes a field trip different from a generic event on a calendar is exactly the four things above happening together, against the same record: an approval that has not cleared should never let a permission slip go out; a permission slip that has not come back should be visible as missing, not silently assumed; a chaperone without a current clearance should never be assignable, regardless of how good the trip idea is; and a fee, if there is one, should never quietly become a charge because a field somewhere got repurposed. Field Trip is built around keeping those four things from ever getting out of order.
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.
One record, not five documents
Before the approval flow, the permission slips, and the chaperones make sense, it helps to say what the trip record itself actually holds. A trip is one row that carries: a destination and purpose, a date and time window, the class or roster group it is drawn from, its current approval state (draft, submitted, or approved), the set of students with an outstanding, signed, or declined permission slip, the set of adults assigned as chaperones and each one’s clearance status at assignment time, and — if the trip carries one — the fee amount and its pay-intent audit trail. Nothing about a trip lives only in an email thread or a paper folder in a filing cabinet; the record is the trip.
That matters because the four pieces are not independent forms that happen to be about the same event — they read each other. The permission-slip step will not go out to families until the trip has cleared approval. The chaperone step will not commit an assignment without a current clearance, no matter what stage the trip is in. And the fee, wherever it appears on the record, never advances past a recorded intent, because there is no collect step on this record for it to advance to. A field trip is genuinely one thing with four faces, and the record is built that way rather than glued together from four separate tools.
Because the record sits on the shared roster and the canonical approval substrate, it inherits the same authorization rules the rest of the platform enforces — a family can read its own child’s slip and nothing else, a teacher can see the trips tied to their own classes, and an administrator sees the trips awaiting their sign-off. There is no separate field-trip login, no separate field-trip permission model to configure. It is the same platform, one more record type on it.
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, edit, or discard until they submit it. A draft can sit unsubmitted indefinitely; nothing forces a decision before the teacher is ready.
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. A submitted trip can still be corrected: if an administrator asks a question or flags a gap, the honest path is a new draft with the fix, resubmitted — not a silent edit to a trip already in review.
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, so an approval is never a memory of a hallway conversation.
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. There is no side door: a trip that skips submitted, or is approved by the same person who drafted it, is not a shortcut the substrate allows.
A few honest edge cases, stated plainly rather than left for a school to discover: an approved trip that needs to change (a new date, a different destination) is a decision for the school to make about how much changed — a minor logistics correction is not the same question as a materially different trip, and this page does not claim the module makes that judgment call for you. A trip that is declined at the administrator stage stays on the record as declined, with the reason if one was given, rather than disappearing; a teacher can start a fresh draft from what they learned. And because approval, permission slips, and chaperone commitments read the SAME record, an administrator reviewing a submitted trip can see, in one place, what the class roster looks like and what the fee (if any) would be — not a separate spreadsheet to cross-reference before deciding.
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.
Per student, not per household. Consent is recorded against one student and one trip, so a family with two children on the same trip signs for each child individually rather than one signature covering a household. A family with children in different classes sees only the trips that touch their own children — not a school-wide list of every trip running that month.
The three states a slip can be in. A permission slip is outstanding (requested, no answer yet), signed (the family said yes), or declined (the family said no). Only signed and declined are terminal for that student on that trip; outstanding is the honest label for “we do not know yet,” and the record shows it as outstanding rather than defaulting a non-response to either yes or no. A declined slip means that student does not go — the record does not treat “no answer” the same as “yes” in either direction.
Withdrawal. A family that signed can change its mind. Consent recorded today is not a decision locked for the school year; a family’s withdrawal is itself a record, not a silent overwrite of the earlier signature — the trip shows that consent was given and later withdrawn, and the student is treated as not going from that point.
What happens if the trip itself changes after slips are out. A permission slip is a family’s consent to a specific trip as described when they signed. This page does not claim the module decides, on its own, whether a changed date or destination invalidates an existing signature — that judgment belongs to the school. What the record does give a school is the ability to see, honestly, who signed for what was originally proposed, so the school can decide whether re-consent is warranted rather than discovering the question only if a parent raises it.
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. Reads a clearance
What “current” means. A clearance on the record carries its own expiry. An adult who was cleared two years ago and whose clearance has since lapsed is denied at assignment time exactly as if no clearance existed at all — a past clearance is not treated as a permanent credential. If a chaperone’s clearance lapses after they were assigned but before the trip runs, the honest answer is that the assignment gate is checked at assignment time; this page does not claim the module re-checks every already-committed assignment on a recurring schedule, and a school that wants that reassurance should confirm the specific behaviour before relying on it for a trip already in motion.
Ratio is a school policy, not a platform rule. Field Trip does not itself enforce a chaperone-to-student ratio — that is a decision schools make as policy, often set by state guidance or district rule, and it varies by grade level and destination. What the module gives a school is an accurate, current count of who is assigned and who is cleared, so the school can apply its own ratio rule against a real number instead of a guess made the night before.
Can the trip’s own teacher chaperone it? Nothing about the approval role and the chaperone role are the same gate. A teacher who proposed and is approved to run the trip can also be assigned as a chaperone on it, subject to the same clearance check every other chaperone goes through — being the trip’s teacher does not exempt anyone from the clearance gate.
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. Honest-off
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.
Why append-only, specifically. An append-only audit means a correction is a new row, not an edit that erases the old one. If a fee amount changes, or a family’s intent changes, or a trip carrying a fee is cancelled, the record keeps the full history rather than a single mutable field that could be quietly changed after the fact. A school (or a family, for their own child) can see what the fee was at each point, not only what it is now.
What a cancellation means for the fee. Because nothing was ever collected, there is no refund to issue in the financial sense — there is nothing to give back. What the record does is close out the pay-intent honestly: a cancelled trip’s fee intent is recorded as no longer active, so the audit trail reflects that the trip ended before any money question could even arise. This page does not claim a refund mechanism, because there is no charge for a refund to reverse.
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.
What each person actually sees
The same trip record looks different depending on who is looking at it — not because the data is different, but because each role needs a different slice of it. Here is the honest shape of each view.
Teacher
Proposes, watches it move
- Drafts the trip: destination, date, roster, and whether it carries a fee.
- Can edit or discard a draft freely before submitting.
- Sees the trip’s approval state (draft, submitted, approved, or declined) but cannot approve their own trip.
- Sees which students on the roster have a signed, outstanding, or declined permission slip once the trip is approved.
- Can be assigned as a chaperone on their own trip, subject to the same clearance check as anyone else.
Administrator
Clears the trip, sees the whole picture
- Reviews submitted trips: the destination, the roster, the fee (if any), and can approve or decline.
- Approval is the only action that unlocks permission slips going out and chaperones being committed.
- Sees the record of who approved a trip and when — including trips they themselves declined, with the reason if one was given.
- Sees chaperone assignments and each one’s clearance status at assignment time, school-wide, not per class.
Family
Signs for their own child, and only their own child
- Sees the trips that touch their own children — not a school-wide list of every trip.
- Signs or declines a permission slip per child, per trip; a household with two children on the same trip signs twice.
- Can withdraw a signature already given; the withdrawal is recorded, not a silent overwrite.
- Sees the fee, if the trip carries one, as a recorded intent — not a checkout, and no card is asked for on this surface.
Chaperone
Assigned only when cleared
- Cannot be committed to a trip without a current, valid recorded clearance — denied by default otherwise.
- Sees the trips they are assigned to and the roster of students on each one.
- Is not asked to undergo a background check through this surface; the check RUN is honest-off until a licensed provider is provisioned.
Module-dark until a school turns it on, and opening one school at a time
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. Module-dark
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.
What “early access, opening gradually” means in practice. Field Trip is not offered as a general sign-up today. It opens to a small number of schools first, honestly, rather than promising a broad launch date this page cannot keep. A school that asks about early access gets an honest conversation about the current state — what is built, what is module-dark, and what is still honest-off — before any decision to enable the module. There is no waitlist gimmick and no artificial scarcity framing; the pace is set by what is actually ready to support a real trip.
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.
Where Field Trip sits on the platform
Field Trip is not a standalone app that happens to talk to a school’s data once. It is one record type built on two pieces of infrastructure the rest of the platform already runs: the canonical approval substrate (the same teacher-then-admin, fail-closed sign-off machinery used elsewhere on the platform, not a private field-trip-only workflow) and the shared student roster (the same list of students, families, and staff every other module reads, not a re-typed copy that can drift).
That has a concrete consequence: a correctness rule earned once on the approval substrate — the fail-closed wall that hard-denies the wrong role, the requirement that submitting is not approving — is the same rule every other module built on that substrate gets, including Field Trip, rather than a rule this page has to re-argue from scratch. And a roster fix made anywhere on the platform (a transfer, a new enrollment, a household correction) is visible to Field Trip immediately, because there is only one roster to be visible in.
Two adjacent, separately-owned products sit next to a trip without being the same product as it: busfleet.software is the transportation record — the bus and route that physically carries the trip — and middleschool.software is the middle-grades front door where a student first joins a trip with the same safety rails on. Field Trip does not try to be either of those; it is the trip record, and it links out to them rather than absorbing their jobs.
And Field Trip is honestly scoped against the wider photography side of the platform too: it handles no photos and no face templates. A trip can happen, be approved, be chaperoned, and be paid for (once payments are live) without a single photo ever entering this record. This is the trip record, not a gallery.
What Field Trip does not do
Saying what a product does not do is as much a part of an honest page as saying what it does. These are deliberate boundaries, not gaps we forgot to mention.
- ×It does not run a background check.It reads a recorded clearance and denies by default without one. The check RUN is honest-off until a licensed provider is provisioned.
- ×It does not process payments.Any fee is recorded as an append-only pay-intent audit. No card is taken, no charge is made, no money moves through this surface.
- ×It does not enforce a chaperone-to-student ratio.Ratio is a school’s own policy decision. The module gives a school an accurate, current count to apply that policy against.
- ×It does not decide whether a changed trip needs re-consent.The record shows what was signed against the original proposal; whether a change warrants asking families again is a school judgment.
- ×It does not use AI anywhere in the approval, screening, or fee flow.No claim of AI assistance is made on this page, because none is made in the module.
- ×It handles no photos and no face templates.This is the trip record, not a gallery. Photography lives elsewhere on the platform, as a separate, consent-gated concern.
- ×It is not open to every school today.Field Trip ships module-dark and this surface is early access, opening to schools gradually.
The paper-and-spreadsheet status quo, next to the record
Field-trip management is a genuinely under-served niche. Most schools run trips on paper permission slips plus a spreadsheet, or a thin module bolted onto an unrelated tool. This is not a claim that every school does it badly — it is a plain comparison of what the record replaces, question by question.
| Question | Paper & spreadsheet | Field Trip |
|---|---|---|
| Where the trip proposal lives | An email, a hallway conversation, or a note on a whiteboard | One trip record with an approval state on it |
| Who signed off, and when | Remembered, or not recorded at all | On the record, with the role and timestamp, fail-closed |
| Who has a signed permission slip | A stack of paper counted by hand the morning of the trip | A live signed / outstanding / declined status per student, on the shared roster |
| Whether a chaperone is currently cleared | Assumed from a past clearance, or not checked at trip time | Read at assignment time; denied by default without a current one |
| What happens if a family withdraws consent | A phone call that may or may not reach the right person | Recorded as its own event, not a silent overwrite of the earlier signature |
| Whether a fee was ever actually collected | A cash envelope or a separate payment tool with no link back to the trip | Recorded as an append-only pay-intent audit — honestly, never collected today |
The edge here is structural, not featural: the trip record sits on the same roster, consent, and audit substrate as the rest of the platform, so a permission slip is a consent-ledger row rather than a scanned PDF nobody can search in April.
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.
Who can see a chaperone’s clearance status. A chaperone’s underlying clearance record is staff-and-administrator information, not something published to families or to other chaperones; what a family sees is that chaperones are assigned to a trip, not the private detail behind each one’s screening record.
Withdrawal is a real right, not a formality. A family that withdraws consent for a child on a trip has that withdrawal recorded as its own event. It does not disappear the earlier signature; it adds the honest fact that consent was later taken back.
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.
What happens if the administrator declines a trip?
The trip stays on the record as declined, with the reason if one was given, rather than disappearing. No permission slip goes out and no chaperone is committed for a declined trip. A teacher can start a fresh draft from what they learned; a decline is not a dead end, it is a recorded decision a new draft can respond to.
Can a trip be changed after it is approved?
The record does not decide for a school whether a change is minor or material — that judgment stays with the school. What it gives the school is an honest record of what families signed for against the trip as originally proposed, so the school can decide whether the change warrants asking families to re-consent, rather than that question only coming up if a parent raises it.
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. It has three states: outstanding (no answer yet), signed, or declined; a non-response is never treated as a yes. 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.
Can a family change its mind after signing?
Yes. A family that withdraws consent already given has that withdrawal recorded as its own event, not a silent overwrite of the earlier signature. The trip then treats that student as not going from the point of withdrawal. Consent recorded once is not locked for the rest of the school year.
What if a family with more than one child never answers for one of them?
Consent is per student, per trip, so each child’s slip is tracked on its own line even within the same household and the same trip. An outstanding slip for one child does not affect a sibling’s already-signed slip on the same trip, and it stays visibly outstanding rather than being assumed either way.
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. A clearance that has lapsed is treated the same as no clearance at all. 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.
Is there a chaperone-to-student ratio the module enforces?
No. Ratio is a school policy decision — often set by state guidance or district rule and varying by grade level and destination — not a number this platform imposes. What Field Trip gives a school is an accurate, current count of assigned and cleared chaperones so that policy can be applied against a real number.
Can the teacher who proposed the trip also chaperone it?
Yes, subject to the same clearance check as any other chaperone. Being the trip’s own teacher, or the person who submitted it, does not exempt anyone from the fail-closed screening gate at assignment time.
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 the fee if a trip is cancelled?
Because nothing was ever collected, there is nothing to refund in the financial sense. The record closes out the pay-intent honestly: a cancelled trip’s fee intent is marked no longer active, and the append-only audit keeps the full history of what was set and when, rather than erasing it.
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.
Is Field Trip its own product, or a feature bolted onto Homeroom?
It is a module on the platform’s canonical approval substrate and shared roster — the same infrastructure other modules use — presented under its own plain brand because a field trip is a genuinely distinct back-office thing. It shares Homeroom’s foundations rather than duplicating a private field-trip-only system, and it links to homeroom.software as the wider platform it belongs to.
How is this different from busfleet.software or middleschool.software?
They are adjacent, separately-owned records, not the same product. busfleet.software is the transportation record — the bus and route that physically carries the trip. middleschool.software is the middle-grades front door where a student first joins a trip with the same safety rails on. Field Trip is the trip record itself; it links out to both rather than absorbing their jobs.
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. Ratio requirements, mid-trip changes, and re-consent judgment calls are named plainly above as decisions that stay with the school, not capabilities this module claims to make for it. 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 AI capability is claimed anywhere on this page. 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.