Athon Network · the standard, and the register, for a-thon run providers
Choosing who runs your a-thon should not be a leap of faith. Athon Network is the standard you can require — and the register you match against.
An a-thon has three separate jobs, and this is only one of them. Athon Network is the standards-and-matching layer: a published vetting standard a school can require of a run vendor, a matching flow that pairs your event to accredited providers, and a shared data standard so a vendor’s counts feed your pledge engine or SIS without a re-keying marathon. It is deliberately not a pledge app and not a gear shop — those are separate sites in the same family.
You are here · standards + matching
athon.network
The vetting standard, the accreditation register, and the Athon Event Data Standard. Vendor-facing. No student data.
Execution
The per-school pledge engine: pledge-per-unit, the FLOOR principle, the donor cover-fee. Where the pledges actually run.
This page publishes the standard and the category checklists so you can use them today. No vendor is listed as accredited yet — the register is opening, and we will not invent a roster. Read the draft standard or ask for a shortlist at [email protected].
The gap
There is no shared reference for vetting who runs an a-thon
A jog-a-thon or bike-a-thon is a mass-participation event with real money and hundreds of children on a course, and yet a booster lead choosing who runs it is working with no shared reference at all. They vet a timing vendor by reading its marketing site. They take a route organizer’s word that the loop is a quarter mile. They ask an entertainment vendor if it has done schools before and accept the answer. They request a certificate of insurance and are not sure what the limit should say or whether the district is named on it. Every school re-derives the same checklist from scratch, badly, under time pressure, once a year.
The cost of that is not abstract. An uncertified course silently mis-prices every distance pledge on the roster. A timing system whose numbers live only in its own dashboard hands the coordinator the “data-entry marathon” — hand-keying tally sheets at midnight — that the category is infamous for. An insurance policy that names a generic service but excludes a mass-participation athletic event leaves the school uncovered for exactly the event it bought the policy for. None of these are exotic failures; they are the ordinary result of vetting ad hoc, vendor by vendor, with no shared standard.
Athon Network exists to be that shared reference: one published standard, one checklist per category, one place to match against it — so the vetting is done once, in the open, instead of privately and repeatedly by every school that runs an event.
The register · five categories
The provider categories, and the named criteria each is vetted on
A school does not hire “an a-thon company.” It hires up to five different kinds of vendor, each of which can be good or bad independently. The register is organized by those five categories, and each carries the concrete criteria the standard scores it on — not the word “vetted,” but the actual checklist. The register is opening; these criteria are published now so a school can hold any vendor against them today.
Timing & pledge tracking
The system that counts the units an a-thon is pledged against -- laps, minutes, miles, books -- and reports them back so a pledge can resolve.
Vetted on
- Exports units-recorded in the Athon Event Data Standard shape (participant handle, unit type, count, event window) -- the single criterion that lets its numbers feed a pledge engine or SIS without re-keying.
- Records a per-participant count tied to an opaque handle, never a public roster of children against dollar amounts.
- Produces a results-reporting file (per-class and per-grade totals) a coordinator can reconcile against the collected amount.
- States plainly whether its count is device-captured (lap counter, RFID, scan) or hand-entered, so a school knows what it is trusting.
This is the vendor whose output actually turns a promise into an amount. The a-thon pain the whole category names is the “data-entry marathon” after the event: a coordinator with a stack of tally sheets, hand-keying laps into a spreadsheet at midnight. The standard scores a timing vendor first on whether its export matches the Athon Event Data Standard, because that one property is what removes the re-keying step — the counts flow straight into a pledge resolution or a school’s SIS. A vendor whose numbers only live inside its own dashboard is scored honestly as that.
Route & course certification
The party that measures and certifies the physical course -- the lap loop, the walk route, the ride course -- for distance and for accessibility.
Vetted on
- Certified measured distance: the lap or course length is measured and documented, not estimated, so a per-mile or per-lap pledge is priced against a real number.
- ADA accessibility of the route: surface, grade, width, and rest points reviewed so a wheelchair user or a student with a mobility aid can participate on the same course.
- A documented turn-by-turn and marshal-point plan for the specific school site, not a generic template.
- Written confirmation of any permits or road/facility permissions the route requires.
A pledge-per-lap or pledge-per-mile a-thon is only honest if the lap and the mile are real. Route certification is the step schools skip most often and regret most: an uncertified “quarter-mile loop” that is actually 310 yards silently inflates or deflates every distance pledge on the roster. The standard requires a measured, documented distance and an accessibility review of the actual course, so the number a family pledged against is the number the student ran, and every student can be on the course.
Entertainment & MC
The DJ, MC, or entertainment crew that runs the energy of the event -- announcements, music, the class-vs-class moments, the thermometer reveal.
Vetted on
- A written run-of-show for a school a-thon (waves, lap counts, water breaks, the goal reveal), not a wedding or corporate script repurposed.
- Age-appropriate content policy for a K-12 audience, stated in writing, covering music and announcements.
- Coordination plan with the timing vendor so announced totals match the recorded count -- no MC calling a number the system cannot back.
- Its own liability coverage and a named on-site lead (see the insurance category).
Entertainment is where an a-thon becomes an event a school wants to run again, and it is also where an unvetted vendor does the most quiet damage — a playlist no one screened, a total announced over the microphone that the timing system never captured. The standard treats the MC as part of the data chain, not decoration: what is announced has to match what is recorded, and the content has to be written for a room full of children.
Safety & medical staffing
The certified medical presence and safety staffing for a physical event with hundreds of children moving at once.
Vetted on
- Current certification of on-site medical staff (the specific credential and its expiry date named, not “trained staff”).
- A staffing ratio appropriate to the headcount and the event type, stated as a number.
- A written emergency and weather plan for the site, including a heat/hydration protocol for a running event.
- A check-in method that counts participants in and out without building a public identity roster.
A jog-a-thon or bike-a-thon is a mass-participation athletic event, and the safety and medical layer is the one a school cannot improvise. The standard names the credential and its expiry, the staffing ratio as a number, and a written weather and hydration plan, because “we’ll have a nurse there” is not a plan a district activities director can put their name on.
Insurance & liability
The coverage that stands behind every other vendor and the event itself -- the piece a district legal or risk office actually asks about first.
Vetted on
- A current certificate of insurance (COI) with general-liability limits meeting a stated floor.
- The school or district named as an additional insured on the vendor’s policy, in writing.
- Coverage that names the specific event type (a physical, mass-participation a-thon), not a generic services policy that excludes it.
- Worker classification and any required event or athletic riders documented.
This is the category schools vet last and lawyers vet first. The standard makes the insurance checklist explicit — COI limits meeting a floor, the district named as an additional insured, coverage that actually names a mass-participation athletic event — so a booster lead is not reading a vendor’s policy PDF at 11pm trying to work out whether the school is covered. A vendor either meets the floor or is scored as not meeting it.
Matching
Five inputs in, an in-region accredited shortlist out
The matching flow is deliberately narrow and legible. A school supplies five things about its event; what comes back is a shortlist of accredited providers, in region, for the categories that event family actually needs — never a black-box “we’ll be in touch.” The event family alone decides which categories apply: a read-a-thon needs no route certifier; a bike-a-thon needs all five.
Event family
Which a-thon shape you are running — a walk-a-thon, a marathon, a read-a-thon, a jog-a-thon, or a fun run — the same five families the execution engine at athon.software is built around. The family determines which categories even apply: a read-a-thon needs no route certification; a bike-a-thon needs all five.
Date and event window
When the event runs. Timing, medical, and entertainment availability are date-bound, and a shortlist that ignores the date is a shortlist of vendors who are already booked.
Headcount
How many participants. Headcount drives the safety and medical staffing ratio, the timing system’s capacity, and whether a route can hold the field — it is a hard input, not a nice-to-have.
Budget tier
What the event can spend, as a band rather than a bidding war. The point of a fundraiser is the net to the school; a shortlist has to respect the budget or it costs the school the money it is trying to raise.
Geography
Where the school is. Route certifiers, medical staffing, and entertainment are regional; a national list is noise. The shortlist is in-region by construction.
Honest scope: there is no live matching engine and no signup on this site today. This is the shape the flow takes, described plainly, and the concrete next step is a conversation at [email protected] — not a form that pretends to run something that is not built.
The Athon Event Data Standard · draft v0.1
A published schema so a vendor’s counts feed your pledge engine — no data-entry marathon
This is the piece that makes Athon Network more than a directory. The single most common a-thon failure after the event is the re-keying of tally sheets into a spreadsheet — the “data-entry marathon.” The Athon Event Data Standard removes it by defining two record shapes every accredited timing vendor is scored against, so their counts flow straight into a pledge resolution at athon.software or into a school’s SIS. The field definitions below are real and grounded in how a pledge-per-unit a-thon actually works. It is a draft, version 0.1, open for comment; no vendor implements it yet, and no live import runs today — we say so rather than imply otherwise.
units-recorded — the raw per-participant count a timing system captures
- participantHandle
- An opaque, per-event handle for a participant — never a student’s name, and never a stable cross-event identifier. The standard requires the handle so a count can be attributed to a pledge page without any vendor holding a roster of children.
- unitType
- The unit the a-thon is pledged against, from a closed set that matches the execution engine: distance units (lap, mile) or time units (minute), plus the theme-specific units the category already uses (book, problem, word, rep, basket, pin). One recorded count means one thing.
- count
- A non-negative integer count of completed units for that participant in that event. Integer, not a rounded decimal, so a per-unit pledge resolves against exactly what happened.
- eventWindow
- The start and end of the counting window, so a count cannot silently include laps run before or after the event. The window is the audit boundary for every pledge that resolves from it.
results-reporting — the reconciled totals a coordinator and a pledge engine consume
- classTotals / gradeTotals
- Aggregate unit totals per class and per grade — the numbers a leaderboard and a thermometer are built from — carried as sums only, so the reporting file never becomes a public roster tying a named child to an amount.
- reconciliationSum
- An exact total-units figure the coordinator reconciles against the collected amount. It has to sum from the per-participant counts with no rounding residual, so a cent or a lap unaccounted for is visible rather than absorbed.
- provenance
- How each count was captured — device-scanned or hand-entered — carried on the record itself, so a school importing the file knows the confidence of every number in it.
Read the draft or send comments to [email protected]. It is versioned and additive: a later revision appends, it does not silently renumber.
Governance & child safety
Who governs the standard, and how a listing stays honest
A standard is only worth what its governance is worth. The accreditation body is being stood up around the people who actually run these events: booster and PTA advisory seats, alongside a written vendor code of conduct that a listed vendor agrees to. This is the proposed structure, described plainly as what is being built — not a live board with seated members, which we would only be inventing.
The design principle that keeps a paying vendor from buying a pass is that a listing names the specific criteria a vendor met, and those criteria are public on this page. A partial pass cannot be dressed up as a full one, because a school can read the checklist itself and ask which items a vendor actually cleared. Accreditation is against named criteria or it is nothing.
On child safety, the boundary is structural: Athon Network is vendor-facing and holds no student data. It carries vendor certifications, coverage, and checklists. Where student counts appear in the data standard they are attributed to an opaque per-event handle, never a name, and the reporting shape carries sums only — so nothing here can become a public roster of children tied to dollar amounts. The minor-safety machinery lives at the data layer of the execution engine, not in this register. This page runs no child-safety tip intake, sets no cookies, and uses no third-party advertising or tracking.
Questions
What Athon Network is, and is not, today
How is athon.network different from athon.software and athon.shop?
Three different jobs. Athon.network — this site — is the standards and matching layer: a published vetting standard a school can require of a run vendor, a matching flow that pairs a school to accredited providers, and a data-interop standard. Athon.software is the per-school execution engine that runs the pledges themselves — pledge-per-unit, the FLOOR principle, the donor cover-fee. Athon.shop is the physical event-gear catalog. You could run a jog-a-thon on athon.software without ever touching this site; you come here when you need to choose and vet the vendors who run the event day.
Which vendors are accredited right now?
None are listed yet, and we will not invent a roster to look established. Athon.network is a register that is opening: the standard and the category checklists are published on this page today, and the register fills as vendors complete review against them. When a vendor is listed, it is listed against the specific criteria it met, with nothing implied about the ones it did not.
What exactly is a vendor vetted on?
Named criteria per category, not a vibe. A timing vendor is scored first on whether its export matches the Athon Event Data Standard. A route certifier is scored on a measured, documented distance and an ADA accessibility review of the actual course. Safety and medical is scored on the specific credential and its expiry, a numeric staffing ratio, and a written weather and hydration plan. Insurance is scored on COI limits meeting a floor and the district named as an additional insured. Every criterion is on this page under its category, so a school knows what the standard checks before anyone applies.
What is the Athon Event Data Standard, and does anything use it today?
It is a published draft schema for two things: units-recorded (the raw per-participant count a timing system captures) and results-reporting (the reconciled class and grade totals a coordinator consumes). Its purpose is to end the “data-entry marathon” — the midnight re-keying of tally sheets — by letting a matched vendor’s counts flow straight into a pledge resolution or a school’s SIS. It is a draft, version 0.1, open for comment. It is honest to say the field definitions are real and grounded in how the execution engine already models a pledge; it would not be honest to say a vendor implements it or that a live import runs today. Neither is claimed.
How does the matching flow work? Do I submit a form here?
Not on this page. The matching flow takes five inputs — event family, date, headcount, budget tier, and geography — and its output is a shortlist of accredited providers in your region for the categories your event family needs, never a black-box “we’ll be in touch.” There is no live matching engine and no signup on this site today; the concrete next step is a plain conversation at [email protected]. We would rather describe the shape honestly than put up a form that pretends to run something that does not.
Does the register hold any student data?
No. Athon.network is vendor-facing. It holds vendor accreditation data — certifications, coverage, checklists — not student data. Where student counts appear in the data standard, they are attributed to an opaque per-event handle, never a name, and the results-reporting shape carries sums only, so it can never become a public roster of children tied to amounts. The minor-safety work lives at the data layer in the execution engine, not here.
Who governs the accreditation, and how do you keep a paying vendor from buying a pass?
The accreditation body is being stood up with booster and PTA advisory seats — the people who actually run these events — and a written vendor code of conduct that a listed vendor agrees to. This is the proposed governance model, described plainly as the structure being built, not a live board with seated members we would be inventing. The design principle is that a listing names the specific criteria a vendor met, so a partial pass cannot be dressed up as a full one, and the criteria are public on this page so a school can check a claim itself.
What can we actually use today?
The standard and the five category checklists are published and readable on this page right now, and you can hold any vendor you are already talking to against them today — that alone is the shared reference the category has never had. The draft data standard is readable and open for comment. The register itself is opening, and the matching flow is described but not a live service. We name each of those where it actually is rather than presenting the whole thing as switched on.
What is published, what is opening, and what is not built
The vetting standard and the five category checklists are published and readable on this page today — you can hold any vendor against them right now. The Athon Event Data Standard is a published draft (v0.1, open for comment): its field definitions are real, but no vendor implements it yet and no live import runs today. The accreditation register is opening — no provider is listed as accredited yet, and we will not invent a roster to look established. The matching flow is described, not a live service: no matching engine, no signup, no form on this site. The governance body is the proposed structure being stood up, not a seated board. There is no money, pricing, or checkout on this page. It sets no cookies, uses no third-party advertising or tracking, and holds no student data. Basic short-lived operational logs may record page requests.