Learning Center Software · Tutoring centers, after-school programs, enrichment studios · Early access · 2026

Run your learning center without compromising student privacy — consent ledger, check-in, and scheduling built for real families

Most learning centers run on a spreadsheet roster, a forms tool, and a group text that parents are added to without ever consenting. Learning Center Software is built for the way centers actually operate: consent per child tracked at the action level, not as a single checkbox at enrollment; QR and PIN check-in with live ratio tracking; scheduling that handles makeups, siblings, and split households without a manual workaround for each one. Early access — no pricing commitment, no signup, no live payments today.

Book a conversation How it works

Consent per actionpickup, photo, messaging, billing visibility, data sharing — tracked per child in the ledger

Scheduling for real familiesmakeups, siblings, split households, extra term modes — designed in, not a workaround; in active development on the built engine

No data resalestudent records never sold, shared with advertisers, or forwarded without a signed DPA

Delete on requestdeletion logged, fulfilled within a stated window, confirmed in the consent ledger

How it works

The learning center year in four stages

Learning Center Software runs on the operating rhythm of an enrollment-based center: intake and consent before the first session, scheduling and check-in calibration in the first weeks, the daily operations loop through the program, and a clean season close with data-portable records. Every stage is described as it is built today.

Step 1 · Enrollment intake — roster, consent, and family onboarding

Before the first session, the center imports or enters its roster: student records with guardian contacts, program assignments, and the starting consent posture. Each guardian receives an onboarding prompt for the consent ledger — not a single release form but a structured walk-through of the permissions that govern the student’s record: pickup authorizations, photo releases, communication channel opt-ins, billing visibility scope, and data-sharing permissions for any school-partnership referral. A guardian who has not completed the consent walk-through is in a restricted state: the student is on the roster and may check in, but photos are blocked, messaging is suppressed, and no data flows to any school partner. Consent is the gate, not a checkbox the director marks complete.

Step 2 · First sessions — scheduling, makeups, and check-in calibration

The first weeks surface the edge cases that break most scheduling tools. A student misses a session: the makeup engine is designed to create a single makeup slot, debit one session from the pack, and notify the guardian via their opted-in channel with no new booking row — this makeup engine is in active development alongside session-pack billing. A sibling pair arrives together but attends different programs: the check-in screen resolves both under the same family drop-off with separate attendance records and separate ratio counts per room. A split-household family has two guardians with different pickup windows: each sees their own schedule view and neither sees the other’s billing. Ratio tracking runs in real time on the live attendance floor: the screen shows the current count per room and a flag if any room is at or over limit.

Step 3 · Active program — daily operations, messaging, billing notes

The daily operations loop: check-in, session, check-out, and the two communications that bracket it — a drop-off confirmation to the guardian and a pickup notification at close. Both run through the messaging channel the guardian opted into. Session packs draw down at check-in so a director can see pack balances without a separate spreadsheet. Low-balance alerts are configurable per family. Subsidy vouchers reduce the billable amount before the family balance is touched. Learning notes and session summaries attach to the student record and are visible to the guardian in the family view. The charge rail and the learning-notes surface are in active development; the daily check-in and messaging infrastructure are built and production-ready.

Step 4 · Season close — progress exports, data portability, and renewal setup

At the close of a program term, the center produces two outputs: a progress export and a data-portability pack. The progress export is a structured summary of the student’s session history, attendance record, and learning notes — formatted for the guardian and, where a DPA is in place, for the district. The data-portability pack is a complete export of the student’s record in a portable format: session history, attendance, consent log, and billing records the family may take with them. The organisation owns all of it. If the center ever leaves the platform, every record exports with it. Renewal configuration opens the next enrollment period on the same roster, prompting each guardian to re-confirm or update their consent posture rather than carrying it forward silently.

The full platform

Five engines — honest about what is built and what is coming

Every feature is labelled honestly: Built means the underlying engine is production-ready. In development means the surface, wire-up, or charge rail is in active build. We do not claim otherwise.

Scheduling and check-in — QR/PIN, ratio tracking, and the real family edge cases

QR-code and PIN check-in is built on the BAS/after-school substrate and is production-ready. A student arrives, a staff member scans the code or enters the PIN, and the attendance record is written. Ratio tracking runs against the live attendance floor: the screen shows the current staff-to-student count per room and flags if any room is at or over its configured limit — not a count updated at the end of the shift, but a live number against the actual roster. The core scheduling engine supports the two enrollment modes in the substrate today — weekly recurring and drop-in. Several scheduling edge cases that break generic tools are in active development on top of that engine: makeup sessions that debit one session from a pack and notify the guardian without a new manual booking; sibling schedules that share a family calendar but generate separate attendance records and separate ratio counts; split-household visibility that lets a booking guardian and a pickup guardian operate in the same family record without exposing one household’s billing to the other; and the additional term modes (intensive, block, seasonal) beyond recurring and drop-in. Check-in, ratio tracking, and the recurring/drop-in scheduling engine are built and production-ready; the makeup engine and the additional term modes are in active development alongside session-pack billing.

Check-in, ratio + recurring/drop-in scheduling built · makeup engine + extra term modes in development

Family messaging — channel infrastructure built, live delivery key-gated

The channel infrastructure for family messaging is built: email templates, SMS templates, and web-push notification structures for session confirmations, pickup notifications, absence alerts, and makeup offers. Messages route only to guardians who have opted in through the consent ledger; messaging consent is recorded alongside pickup and photo permissions, not in a separate system. A center director can draft and preview a message before sending. Live carrier delivery — the wire that actually sends email through an SMTP provider or SMS through a carrier gateway — requires a configured provider key. Live delivery is honest-off: the infrastructure is present, the delivery wire is not yet enabled for live send. No message reaches a family who has not opted in to that channel. Student contact information is never used to build advertising profiles, and messaging logs are visible to the consenting guardian on request.

Channel infrastructure built · live delivery honest-off

Session billing — session packs, subsidies, and the charge rail in active development

Session packs and subsidy tracking are the billing model for most learning centers: a family purchases a block of sessions, sessions draw down at check-in, and a configurable low-balance alert fires when the pack approaches empty. The billing engine is in active development to handle pack purchase, per-check-in drawdown, subsidy voucher application (per-student voucher amounts from a district or state program, applied before the family balance is touched), and term-fee invoicing for programs that bill per term rather than per session. The underlying records model is being built. The charge rail that moves money is honest-off: the billing surface and session-pack engine are early-access, and no live payment is collected today. The model is described plainly: a per-active-student SaaS fee, a payment-processing margin when the charge rail is enabled, and no platform skim on subsidy vouchers. There is no live checkout, no billing subscription, and no pricing commitment from this page.

Session-pack engine early-access · charge rail honest-off

School-partnership mode — FERPA-aware referral intake and exports, contract-gated

A tutoring center or intervention provider that receives referrals from a school district operates in FERPA-adjacent territory: student records originating in the school system may be transferred to the center under a services agreement, and the center’s own records may flow back to the school for progress reporting. School-partnership mode handles structured referral intake — a form that captures the referral source, a referral-specific consent flag, and the program assignment — and produces FERPA-aware progress exports in a format the district can ingest. No student record is forwarded to a school partner without a signed data-processing agreement confirmed in the platform. The data-sharing wire is contract-gated by design: the center must confirm an active DPA with the named district before any export runs. Student data is never resold, never shared with advertisers, never aggregated for external research without explicit per-student opt-in. School-partnership mode is in active development.

School-partnership mode early-access · contract-gated

Who uses it

Built for the independent tutoring center, the after-school program, and the microschool — all on one substrate

Independent tutoring centers

A tutoring center with 40–300 active students runs on session packs, family billing, and a scheduling rhythm where makeups and sibling logistics are a weekly constant. The consent ledger governs which guardian sees billing, who can pick up each student, and whether the center may share progress notes with the student’s school. Session-pack billing, the scheduling engine, and the consent substrate are built for exactly this operational shape.

After-school enrichment programs

An after-school enrichment program — STEM club, art studio, language program, coding center, reading intervention — runs on a daily attendance floor with a ratio requirement, a pickup window, and a family communication loop that fires at drop-off and pick-up. The BAS/after-school substrate under this platform was built for exactly this pattern: QR/PIN check-in, live ratio count, and pickup-window communications routed only to consenting guardians. For dedicated after-school program operations, the sibling platform at afterschool.software is the more program-specific fit.

Microschools and intervention providers

A microschool or district-adjacent intervention provider operates at the edge of the school system: student referrals may carry FERPA-governed records, progress reporting may flow back to the district, and the consent model must reflect the complexity of a student who attends multiple programs across multiple providers. School-partnership mode handles referral intake, DPA confirmation, and FERPA-aware progress exports — with no data forwarded to any district partner until a signed agreement is confirmed in the platform. This surface is in active development.

Scheduling built for real families — not an ideal enrollment model

Makeups, siblings, split households, and term modes — the edge cases are the normal cases

Generic scheduling tools are designed for a clean enrollment model: one student, one program, one guardian, weekly recurring. Real learning centers run on edge cases. A student misses a session: does the makeup slot count against the pack, get added for free, or follow a configurable makeup policy? The makeup engine is designed to handle all three, with the center defining the rule — it is in active development on top of the built check-in and recurring/drop-in scheduling engine. A sibling pair comes in together every Tuesday: they share a drop-off event but attend different rooms with different instructors, and each generates a separate attendance record and a separate ratio count. The check-in screen resolves both under the same family drop-off without requiring the staff member to enter each separately.

Split households are the most common edge case in a tutoring or enrichment center, and they are the most likely to create a privacy incident if handled carelessly. Guardian A books the sessions and sees the billing. Guardian B is the pickup contact on alternating weeks. Neither should see the other’s account details or billing history. The scheduling engine enforces the household scoping at the data layer: booking visibility and pickup authorization are distinct permission fields in the consent ledger, and each is settable per guardian. The staff member at the door sees whether the arriving adult is authorized for pickup today — not just “is this person on the family record,” but “is this person authorized for today’s pickup window.”

Term modes let the center match how families actually enroll: weekly recurring (a standard semester-style schedule) and drop-in (single sessions without a commitment) are built and production-ready today; intensive (a block of daily sessions over a short period) and seasonal (a summer program or holiday intensive) are in active development on top of the built recurring and drop-in engine.

Trust materials and data posture

Real trust materials, not compliance badges — what we publish and what we don’t collect

Privacy badges are marketing. Trust materials are documents. The onboarding agreement for Learning Center Software includes a data-processing agreement the center can review before signing; a subprocessor list naming every third party that touches student data; a retention and deletion policy stating how long records are kept, what triggers deletion, and what happens when a guardian submits a deletion request; and a breach-notification commitment with a specific window. These materials are linked from the footer at launch. We describe them now as the standard we hold ourselves to — not as published documents. When they are live, a direct link replaces this statement.

On data posture: student data is never sold to outside companies, advertisers, or data brokers. No behavioral tracking is run on minors. No ad-network pixels fire on any page a student or guardian visits. A student’s session history and progress notes are not aggregated across centers for research or product development without explicit per-student guardian opt-in. The center owns its roster, its session records, and its family contact list — not the platform. If the center ever leaves, every record exports with it in a portable format.

What is built and what is coming — plainly

The consent ledger and check-in are built. Billing and school-partnership mode are not live yet.

Built and production-ready today: the consent substrate (per-child consent ledger, time-stamped revocable permissions, deletion logging, access-control enforcement); enrollment and roster intake (family import, guardian onboarding, restricted-state enforcement); QR/PIN check-in and live ratio tracking (on the BAS/after-school substrate); the recurring/drop-in scheduling engine; and the family messaging channel infrastructure (email and web-push templates, consent-gated routing, guardian-visible message log).

In active development: the makeup engine (session-pack drawdown), sibling and split-household scheduling edge cases, and the intensive, block, and seasonal term modes. Not yet enabled for live use: the charge rail (the part that moves money), live session-pack billing and subsidy voucher checkout, learning-progress report surfaces and session-note exports, school-partnership referral intake and FERPA-aware district exports, and live carrier delivery for SMS and email. These are honest-off — present in the platform architecture, not yet enabled for live use. There is no live checkout here. No billing subscription. We say so directly because the people running a learning center deserve to know what is production-ready today and what is still being built.

Connected to the platform

The learning center runs the program. Assembly captures the moments. Seen puts every student on a page.

Learning Center Software runs the operational spine: enrollment, consent, scheduling, check-in, billing. Assembly is the moment layer: live events — a recital, a robotics showcase, a reading celebration — captured, ticketed, and archived with the same consent architecture. Seen is the recognition layer: the program that puts every student who completed a term on a real, adviser-approved, consent-verified page — not a generic certificate but a named recognition. For licensed childcare centers, the sibling platform at childcare.software is purpose-built for the licensed early-childhood and CACFP compliance layer. For dedicated after-school program operations, afterschool.software is the more program-specific operating surface.

assembly.school seen.school afterschool.software childcare.software

Early access · Tutoring center owners, after-school directors, enrichment studio operators

Book a conversation to see the current state honestly

Learning Center Software is in active development. We do conversations that show the current state honestly: how the consent ledger works through an enrollment walk-through, how the check-in and ratio screen looks on the live attendance floor, how the scheduling engine is designed to handle a makeup and a split-household pickup in the same session, and what early access to the billing and school-partnership surfaces looks like. There is no pricing commitment and no signup. If it looks right for your center, we discuss what early access means for your program.

To book: email [email protected].

FAQ

Common questions

What does the “consent ledger for minors” mean in day-to-day operation?

It means every action the platform takes on behalf of a minor is traceable to a specific, time-stamped guardian permission. Pickup: who is authorized to collect the student, and was that authorization from guardian A, guardian B, or both? Photo release: did the guardian release photos for internal use, external communications, or neither? Billing visibility: which guardian sees the billing record? Data sharing: did the guardian consent to progress data being shared with the student’s school district, and under what data-processing agreement? Every ledger entry is immutable and auditable. A guardian can withdraw any permission at any time — the revocation is logged, the effect is immediate, and every downstream action that depended on the permission is blocked. The ledger is not a form on file; it is a live access-control layer.

Is the check-in and ratio tracking engine live today?

Yes. QR-code and PIN check-in is built on the BAS/after-school substrate and is production-ready. A student arrives, a staff member scans the QR code or enters the PIN, and the attendance record is written against the daily roster. Ratio tracking runs against the live attendance floor: the screen shows the current staff-to-student count per room and flags if any room is at or over its configured limit. The core check-in and ratio engine is built and production-ready today.

How does scheduling handle makeups, siblings, and split households?

The makeup engine is designed to create a one-off session slot when a student misses a scheduled class — debiting one session from their pack, notifying the opted-in guardian, and avoiding a new manual booking row. For siblings: two students in the same family who attend different programs on the same day check in under the same family drop-off but generate separate attendance records and separate ratio counts per room. For split households: the guardian who books a session and the guardian who does pickup can hold different account scopes — the booking guardian does not see the other household’s billing, and the pickup guardian is authorized only for their window. The recurring/drop-in scheduling and the check-in engine are built and production-ready; the makeup engine (which draws down a session pack) is in active development alongside session-pack billing.

Is billing live? Can we collect session fees now?

Not yet. The session-pack and subsidy tracking engine is in active development. The underlying records model — pack purchase, drawdown per check-in, subsidy voucher application, low-balance alerts — is being built. The charge rail that moves money is honest-off: present in the platform architecture, not enabled for live transactions today. There is no live checkout and no billing subscription. When the charge rail is enabled (a founder-gated decision), centers will be notified. The CTA here is “book a conversation,” not “sign up and pay.”

How does school-partnership mode work? Can we receive referrals from a district?

School-partnership mode is a structured intake and export surface for centers that work with students referred by a school district. Referral intake captures the referral source, a referral-specific consent flag, and the program assignment. FERPA-aware exports produce a structured progress summary in a format the district can ingest. No student record is forwarded to a school partner without a signed data-processing agreement confirmed in the platform — the data-sharing wire is contract-gated by design. Student data is never resold, never shared with advertisers, and never aggregated for external research without explicit per-student opt-in. School-partnership mode is in active development.

What about learning-progress reports and session notes?

Learning-progress reports and session notes are in active development. The platform’s records model supports attaching structured notes to a student’s session record. A guardian can see their child’s session notes in the family view. At the close of a term, the progress export produces a structured summary of the student’s session history and notes. The surface and export format are being built alongside the billing engine.

What is the difference between this and a learning-management system?

A learning-management system is built to deliver curriculum: course content, assignments, quizzes, grades, discussion boards, and a student portal for accessing learning materials. Learning Center Software is built to run an operation: enrollment, scheduling, check-in, ratio tracking, consent, family messaging, billing, and data portability. It is intentionally not a curriculum delivery tool. It does not host course content, grade assignments, or run an LMS learner view. It is the operating spine for the business side of a learning center — the enrollment, scheduling, compliance, and family-trust layer — so a director can focus on instruction rather than administration.

What trust materials do you publish? Vague privacy badges are not enough.

Agreed. The trust materials that will be published — and are part of the onboarding agreement — are: a data-processing agreement the center can review before signing; a subprocessor list naming every third party that touches student data; a retention and deletion policy stating how long records are kept and what happens when a deletion request arrives; and a breach-notification commitment. We describe these now as the standard we hold ourselves to, not as if they are already published. When they are live, a link replaces this statement in the footer.

How are minor student photos handled?

No photo of a student is shared or published without an active photo-release permission in the student’s consent ledger. Internal use requires the internal-release flag. External use — a newsletter, a program showcase — requires a separate external-release flag a guardian must set explicitly. Photos of students with no release flag are blocked from all sharing workflows at the data layer, not by a staff reminder. A guardian who withdraws a photo release has the effect applied immediately: the student’s photos are removed from every sharing queue and are no longer visible in any view accessible to other families or the public.

What data is never collected, sold, or shared?

Student data is never sold to outside companies, advertisers, or data brokers. No behavioral tracking is run on minors — no ad-network pixels, no engagement scoring for sale, no location data. A student’s session history and progress notes are not aggregated across centers for research or product development without explicit per-student guardian opt-in. The center owns its roster, session records, and family contact list. The platform provides a one-click data export: if the center ever leaves, every record exports in a portable format usable independently of the platform.

When is the platform available?

The consent ledger, enrollment and roster intake, QR/PIN check-in, ratio tracking, and the recurring/drop-in scheduling engine are built and production-ready. Family messaging channel infrastructure is built; live carrier delivery is honest-off pending provider key configuration. The makeup engine, the additional term modes (intensive, block, seasonal), session-pack billing, subsidy tracking, learning-progress reports, and school-partnership mode are in active development. The charge rail is honest-off — no live checkout, no billing subscription today. The best next step is a conversation where we show the current state honestly.