Lunchroom
Book a conversation

Lunchroom · Nutrition directors, cafeteria managers, school business offices · Early access · 2026

The school cafeteria platform — the cashier sees a price, the engine protects the eligibility record

Lunchroom is the operating platform for the school lunch line. A prepaid meal account with a hash-chained journal and a POS draw-down in integer cents. Free and reduced eligibility protected at the data layer per 7 CFR 245.6: the cashier’s view is masked to a price category; the eligibility basis is inaccessible to the cashier lane at the engine. A Smart-Snacks a-la-carte POS guard that fires before the transaction completes. Household income application intake with official-review-required determination. Early access — no pricing commitment, no signup, no live card transactions today.

Book a conversation How it works
7 CFR 245.6eligibility masking enforced at the data layer — cashier sees a price, not the tier
Integer centsdraw-down in exact integer arithmetic — no rounding error in the ledger
Hash-chained journaltamper-evident: a modified or deleted transaction breaks the chain
Consent-gatedstudent and family data owned by the school district, never sold

The lunch line — where three rules fire simultaneously at the point of sale

The cashier draws down the account. The eligibility record stays behind glass.

Three things happen at once when a student reaches the cashier. The engine debits the meal account in integer cents and records the transaction in the hash-chained journal. The negative-balance predicate checks whether the account is below the configured threshold before the transaction completes — a flag to the cashier, not a silent debt. If the item is a-la-carte, the Smart-Snacks guard checks compliance before the ring-through. None of this requires the cashier to know, see, or act on the student’s eligibility status. The cashier sees a price. The engine keeps the tier.

Federal regulation 7 CFR 245.6 requires that free and reduced-price eligibility be kept confidential. Most systems depend on a role permission someone set correctly the last time a staff member changed. In this platform the masking is at the data layer: the cashier’s data stream does not contain the eligibility basis. It is not there to find, not because of a permission setting, but because that is what the engine returns to that view.

The meal-account engine, the eligibility masking layer, the direct-cert import, and the Smart-Snacks guard are built and production-ready. The card deposit rail that moves money from a parent’s payment card to the account is honest-off: present in the platform, not enabled for live card transactions today.

Book a conversation Full platform

How it works

The cafeteria year in four stages

Lunchroom runs on the school year: program setup and direct-cert import at the start of year, household application intake and official determinations through application season, the daily lunch line with POS draw-down and Smart-Snacks guard, and a clean reconciliation and export at year end. Every stage is described as it is built today.

Step 1 · Start of year — program configuration and account setup

The nutrition director configures the food-service program for the year: meal types, price tiers, a-la-carte catalog with Smart-Snacks compliance flags, and the negative-balance threshold that governs when an account is flagged before a draw-down. Student accounts are opened against the enrollment record. Eligibility carryover is initialised for returning students per USDA carryover rules, pending new determinations. Direct-cert records from the state agency are imported via the bulk endpoint, with per-row upsert and an audit trail per import. Family consent for any communication is collected at this stage, never assumed, and can be withdrawn at any time. The school district owns every record from the first day of configuration.

Step 2 · Application season — household submissions and official determinations

Families submit household income applications through the intake form. Each submission creates a pending record with a provisional income determination — flagged PROVISIONAL ONLY — that awaits the nutrition director’s review. No pending application is automatically promoted to an approved eligibility record; the nutrition director or designated reviewer acts on each one. The direct-cert summary reconciliation read surfaces gaps between certifications on file and the active student population. Eligibility records are protected under 7 CFR 245.6 throughout: no individual status is visible outside the nutrition-director lane.

Step 3 · Daily service — the lunch line, POS draw-down, and Smart-Snacks guard

Each student at the point of sale is identified against the meal-account record. The cashier’s view shows the student’s name, the account balance, and the applicable price category — Full Pay, Reduced, or Free — without the eligibility basis present in the cashier’s data stream. The draw-down records the transaction in integer cents in the hash-chained journal. The negative-balance predicate fires before the draw-down if the account is below threshold. A-la-carte items are checked against the Smart-Snacks guard before the transaction completes. The cashier cannot see, set, or alter a student’s eligibility status; only the nutrition-director lane can.

Step 4 · Reporting and reconciliation — accounts, certifications, and applications

The accounts summary gives the business office the POS financial aggregate: balance totals, transaction counts, negative-balance exposure, and daily draw-down volume, without individual eligibility status in the aggregate view. The direct-cert summary reconciliation surfaces current versus lapsed certifications. The meal-applications summary shows pending, approved, and denied counts for the period. USDA NSLP daily claiming is partner honest-off and is not available as a live submission today. The data and the hash-chained journal belong to the school or district; one-click export is available at any time.

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 partner integration is in active build. We do not claim otherwise.

Prepaid meal accounts — POS draw-down, negative-balance predicate, hash-chained journal

Each student carries a prepaid meal account. At the point of sale the cashier initiates a draw-down and the engine debits the account in integer cents — no floating-point arithmetic, no rounding error, no penny silently absorbed into a platform margin. The negative-balance predicate fires before the draw-down: if the account is below the configured threshold the cashier is flagged before the transaction completes, not after a string of silent debt has accumulated. Every event — deposit, charge, a-la-carte item, account open — lands in a hash-chained meal-account journal. Each entry hashes the prior entry’s hash; a deleted or modified record breaks the chain at the point of alteration, making tampering detectable by external audit or export verification. The meal-account engine is built and production-ready. The card-on-file deposit rail is honest-off: the part that accepts a payment card from a parent to credit an account online is present in the platform, not enabled for live card transactions today.

Meal account engine built · card deposit rail honest-off

Free and reduced eligibility — 7 CFR 245.6 protection enforced at the data layer

Federal regulation 7 CFR 245.6 requires that a student’s free or reduced-price meal eligibility status be kept confidential. The platform enforces this at the data layer: the cashier’s point-of-sale view is masked to a price category — Full Pay, Reduced, Free — without the eligibility basis present in the cashier’s data stream at all. The raw eligibility tier and the record of how it was determined are accessible only to the nutrition-director and administrative lanes. This masking is not a role permission that can be misconfigured; it is enforced in the engine. The eligibility record and masking layer are built and production-ready. The eligibility SET endpoint enforces an official-only wall: only the nutrition-director lane can write an eligibility record. Direct certification records — single entry and bulk import with per-row upsert and audit trail — are built. The direct-cert summary reconciliation read, which surfaces students whose cert is current versus lapsed or missing, is built. Eligibility is never shared with advertisers, never visible to other families, and never exported without an explicit official action.

Eligibility engine built · 7 CFR 245.6 enforced at data layer

Smart-Snacks POS guard — a-la-carte compliance at the point of sale

USDA Smart Snacks in School rules set nutrient standards for competitive foods sold to students during the school day. The Smart-Snacks POS guard checks each a-la-carte item against its compliance flag at the moment of sale — not at catalog entry, not as a post-hoc audit, but as a check the engine runs before the transaction completes. A non-compliant item in the catalog cannot be rung through as a student a-la-carte sale during school hours; the guard enforces this in code, not by a reminder a cashier could skip. The Smart-Snacks guard engine is built and production-ready. The catalog management interface is in active development — the surface where a nutrition director updates item compliance flags.

Smart-Snacks guard engine built · catalog UI in development

Household income application intake — parent submits, official determines

A parent or guardian submits a household income application through the family-facing intake form: household size, income figures, and the required attestation. The submission creates a ‘pending’ row in the meal-application record. The platform runs a provisional income determination using the federal Income Eligibility Guidelines (IEG) — but the IEG thresholds must be configured by a qualified nutrition administrator before the determination can run, and the result is flagged PROVISIONAL ONLY. A provisional result is never automatically promoted to a final eligibility record. The nutrition director or designated reviewer acts on each pending application; official review is required to confer eligibility. The application intake engine is built and production-ready (submission, provisional determination, pending record), as is the meal-applications summary read. The IEG threshold configuration for automatic approval is pending SME sign-off and is not live.

Application intake built · IEG auto-approval pending SME gate

Accounts summary, direct-cert reconciliation, and application reporting

The accounts summary — the POS financial aggregate — gives the nutrition director and business office account balances, transaction volume, and negative-balance counts without exposing individual eligibility status in aggregate views. The direct-cert summary reconciliation read cross-references certifications on file against the active enrollment to surface students whose cert is current versus lapsed or missing, so the nutrition director can identify gaps before the next claiming period. The meal-applications summary surfaces pending, approved, and denied application counts for the current period. USDA NSLP daily claiming is partner honest-off: the submission of daily meal counts to the state agency for federal reimbursement is not enabled, and the ‘/claim/export’ endpoint is a stub. Menu and nutrient analysis, including USDA meal-pattern compliance reporting, are partner honest-off. These are described accurately: designed on the platform’s substrate, not enabled as live submissions today.

Account & application reporting built · NSLP claiming honest-off

Who uses it

Built for the nutrition director, the cafeteria manager, and the school business office — three views, one substrate

Nutrition directors

The nutrition director configures the programme, reviews pending household applications, sets eligibility records after official review, and imports direct-cert records from the state agency. The eligibility SET endpoint enforces an official-only wall: only the nutrition-director lane can write. The direct-cert summary reconciliation read surfaces gaps before the next claiming period. The nutrition director is the only role with access to the raw eligibility tier and the determination record.

Cafeteria managers

The cafeteria manager runs the lunch line. The cashier’s point-of-sale view shows the student name, the account balance, and the applicable price category — Full Pay, Reduced, Free — without the eligibility basis present in the data stream. The negative-balance predicate fires before a draw-down if the account is below threshold. The Smart-Snacks guard blocks a non-compliant a-la-carte item before the ring-through. The manager sees what is needed to run the line; the eligibility record stays protected.

School business offices

The business office works with the accounts summary: POS financial aggregate, balance totals, transaction counts, and negative-balance exposure — without individual eligibility status in the aggregate view. The hash-chained journal provides a tamper-evident record for audit: a deleted or modified transaction breaks the chain at the point of alteration. The meal-applications summary surfaces pending, approved, and denied counts for the period. One-click export delivers the full record to the district at any time.

The eligibility record — what protection at the data layer actually means

The official-only wall and the cashier mask are in the code, not the handbook

Two rules enforce the federal confidentiality requirement in the engine. First, the eligibility SET endpoint enforces an official-only wall: only the nutrition-director lane can write an eligibility record. A cashier, a classroom teacher, or a business-office user cannot set or alter a student’s eligibility tier, not because the form is hidden, but because the endpoint refuses the write from a non-director identity. Second, the cashier’s point-of-sale view is masked: it returns a price category and nothing else. The eligibility basis is not in the response the cashier’s screen renders.

Direct certification imports arrive from the state agency and are loaded via the bulk endpoint with per-row upsert and an audit trail per import. The direct-cert summary reconciliation read then surfaces the gap: which students have a current certification, which have a lapsed one, and which are in the enrollment without any cert on file. The nutrition director uses this to identify who still needs a household application processed before the next claiming period. None of this crosses to the cashier view.

Student data & family consent

The district owns the data. Eligibility is never shared. Minor student data is consent-gated.

The meal-account ledger, the hash-chained transaction journal, the eligibility records, the direct-cert log, and the household application records belong to the school or district — not to the platform. No student or family data is sold to or shared with outside companies or advertisers. Free and reduced eligibility status is protected under 7 CFR 245.6 and is never shared with other families, with classroom staff who do not need to know, or with advertisers. Eligibility is never exported without an explicit official action.

Minor student data is consent-gated: a family must opt in before their contact information is added to any communication list. Consent is not assumed; it is collected. Consent can be withdrawn at any time. Minor student data is never visible to other families. One-click export is available in writing — if the school or district leaves the platform, every record leaves with it: the journal, eligibility history, application records, direct-cert log, and consent status. This is part of the agreement, not a footnote.

What is built and what is coming — plainly

The engines are built. The card rail and NSLP claiming are not live yet.

Built and production-ready today: the meal-account engine (account open, POS draw-down in integer cents, negative-balance predicate, hash-chained journal, a-la-carte); the eligibility record and masking layer (7 CFR 245.6 protection at the data layer, official-only SET wall, cashier view masked); direct-cert import (single entry and bulk with per-row upsert and audit trail); the direct-cert summary reconciliation read; the Smart-Snacks POS guard engine (a-la-carte compliance check at transaction time); the household income application intake (submission, pending record, provisional determination flagged PROVISIONAL ONLY); and the accounts summary, direct-cert summary, and meal-applications summary reads.

Not yet enabled for live use: the card-on-file deposit rail (online account top-up from parents), the IEG threshold auto-approval (pending SME gate, provisional results are never auto-promoted), and USDA NSLP daily claiming and menu/nutrient analysis (partner honest-off, /claim/export is a stub). These are honest-off — present in the platform, not enabled for live use. There is no live card checkout here. No billing. No subscription. Nutrition directors and business offices deserve to know what is production-ready and what is still being wired.

Connected to the school platform

The cafeteria is one part of a school’s day. The platform connects to the rest of it.

Lunchroom runs on the same consent-gated substrate as the wider school platform. homeroom.software is the school publishing platform: the yearbook, newspaper, litmag, and newsletter engine that sits alongside the cafeteria, the classroom, and the after-school programme on one student record. Seen is the recognition programme: the layer that ensures every student lands on a real page, adviser-approved and consent-verified. Assembly is the moment layer: live school events captured, ticketed, and archived. One consent record, one student identity, one district-owned data posture across all of them.

homeroom.software seen.school assembly.school

Early access · Nutrition directors, cafeteria managers, school business offices

Book a conversation to see the current state honestly

Lunchroom is in active development. We do conversations that show the current state honestly: how the cashier view is masked to a price category with no eligibility basis in the data stream, how a draw-down lands in the hash-chained journal in integer cents, how the direct-cert bulk import works with per-row upsert and audit trail, how the provisional determination is flagged before an official review step, and how the Smart-Snacks guard fires before the a-la-carte ring-through. There is no pricing commitment and no signup. If it looks right for your district, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions from nutrition directors and school business offices

What does “7 CFR 245.6 protection at the data layer” mean for a cashier?

Federal regulation 7 CFR 245.6 requires that a student’s free or reduced-price meal eligibility status be kept confidential from those who do not need to know it. In many systems that protection depends on training and role settings someone might misconfigure. In this platform it is enforced at the data layer: the cashier’s point-of-sale view is masked to a price category — Full Pay, Reduced, Free — and the underlying eligibility basis is not present in the cashier’s data stream at all. A cashier looking at the screen sees a price. The engine ensures the tier is not there to find. That is not a permission you configure; it is what the engine returns to that view.

How does the prepaid meal account work?

Each student carries a prepaid account. At the point of sale the engine debits the account in integer cents — no floating-point arithmetic, no rounding error. Every transaction lands in a hash-chained meal-account journal where each entry hashes the prior entry’s hash. A deleted or modified record breaks the chain at that point, making the alteration detectable by external audit or export verification. The negative-balance predicate fires before a draw-down if the account is below the configured threshold — a flag to the cashier before the transaction completes, not a silent accumulation of debt. The meal-account engine is built and production-ready.

Is the card deposit rail live? Can parents top up accounts online?

Not yet. The card-on-file deposit rail — the part that accepts a payment card from a parent to credit a student’s account online — is honest-off: it is present in the platform as a designed capability but is not enabled for live card transactions today. Manual deposit entry through the accounts management interface is available. When the card rail is enabled (a founder-gated decision), parents will be able to deposit online. The CTA here is “book a conversation,” not “add funds now.”

How does the direct certification process work?

Direct certification is the process by which a student is automatically certified for free meals based on participation in a qualifying programme — SNAP, Medicaid, FDPIR, or similar. The platform supports individual direct-cert records and bulk import via a batch endpoint, with per-row upsert and an audit trail per import. The direct-cert summary reconciliation read cross-references certifications on file against the active enrollment to surface students whose cert is current versus lapsed or missing. The nutrition director uses this read to identify gaps before the next claiming period. Direct-cert import and reconciliation are built.

What is the Smart-Snacks POS guard?

USDA Smart Snacks in School rules set nutrient standards for competitive foods sold to students during the school day. The Smart-Snacks POS guard checks each a-la-carte item against its compliance flag at the moment of sale. A non-compliant item cannot be rung through as a student a-la-carte sale during school hours — the guard runs before the transaction completes, not as a post-hoc audit. The guard engine is built and production-ready. The catalog management interface, where a nutrition director marks items compliant or non-compliant, is in active development.

How does the household income application intake work?

A parent or guardian submits an application through the family-facing intake form: household size, income, and the required attestation. The submission creates a pending record. The platform runs a provisional income determination against the federal Income Eligibility Guidelines (IEG) — but the IEG thresholds must be configured by a qualified nutrition administrator first, and the result is flagged PROVISIONAL ONLY. An official review step is required to confer eligibility. No pending application is automatically promoted to an approved record; the nutrition director or designated reviewer acts on each one. This is not a policy constraint — it is what the code does.

Is USDA NSLP daily claiming available?

Not yet. USDA NSLP daily claiming — the submission of daily meal counts to the state agency for federal reimbursement — is partner honest-off. The ‘/claim/export’ endpoint exists as a stub in the platform but does not generate live claim submissions today. Menu and nutrient analysis, including USDA meal-pattern compliance reporting, are also partner honest-off. These capabilities are described accurately: designed on the platform’s substrate, not yet enabled for live submission.

Who can see a student’s free or reduced eligibility status?

Only the nutrition-director and administrative lanes. The cashier’s point-of-sale view is masked to a price category and does not expose the eligibility basis. The eligibility SET endpoint enforces an official-only wall: only the nutrition-director lane can write an eligibility record. Eligibility status is never shared with advertisers, never visible to other families, and never exported without an explicit official action. This masking is enforced at the engine layer, not by a role permission.

What student and family data does the platform hold, and who owns it?

The platform holds meal-account balances, the hash-chained transaction journal, eligibility status records (masked in cashier views), direct-cert records, and household income application records. All of it is owned by the school or district — not by the platform. No student or family data is sold to or shared with outside companies or advertisers. Eligibility data is subject to 7 CFR 245.6 confidentiality rules and handled accordingly. Minor student data is consent-gated and never public. One-click export is available at any time — if the school or district leaves, every record leaves with it.

What is available right now, and how do we get early access?

The meal-account engine (account open, POS draw-down, negative-balance predicate, hash-chained journal, a-la-carte), the eligibility record and masking layer (7 CFR 245.6, official-only wall), the direct-cert import (single and bulk) and reconciliation read, the Smart-Snacks POS guard engine, the household income application intake, and the accounts and application summary reads are built and production-ready. The card deposit rail, the IEG auto-approval, and NSLP claiming are honest-off. A conversation is the honest next step — we show the current state accurately: how the cashier view is masked, how a draw-down lands in the hash-chained journal, how the direct-cert bulk import works, and how the provisional determination is flagged before an official review. Email [email protected] to book one.