Why Childcare Marketplaces Need Capacity Ledgers, Not Availability Badges

Turn the lesson into a decision check before adding scope. Name the product boundary, the owner, the evidence, the failure mode, and the next action.

• State what triggered the observation.
• Generalize the rule before introducing the project.
• Name what is proven, assumed, and still uncertain.
• Give the reader a concrete next action or diagnostic question.

Local-service marketplaces often represent availability as a badge, a free-text sentence, or a calendar last edited by the provider. That is enough for discovery, but not for a recurring service where one accepted arrangement changes what can be offered to every later family. The badge says a provider may have room. It does not say which schedule, age group, start date, care format, or commitment horizon the capacity belongs to.

The sharper lens is a capacity ledger. Each entry represents a bounded service unit and its history: declared, tentatively held, committed, released, expired, or disputed. Matching can still rank candidates, but it must consume capacity evidence rather than infer supply from profile visibility. This separates two product questions that are easy to blur: whether a provider could fit a request, and whether the required capacity is still operationally available now.

A useful unit is not simply one provider or one open place. Model {provider_id, service_area, care_format, age_band, recurrence_pattern, time_window, start_range, end_or_review_date, quantity, constraints}. A Monday-to-Thursday after-school slot is different inventory from full-day weekday care, even if both belong to the same provider. Capacity that starts next month cannot satisfy an urgent request today, and capacity for one age band should not silently inflate another.

Attach a versioned declaration with {capacity_id, version, source, declared_at, valid_until, evidence_scope, supersedes}. The operating invariant is that every match shown as currently actionable must resolve to a non-expired capacity version whose remaining quantity is positive after active holds and commitments. A profile can remain discoverable when this invariant fails, but the product must label availability as unknown rather than converting missing evidence into apparent supply.

NounouProche provides public portfolio context for a childcare ecosystem connecting families, childminders, nurseries, municipalities, and childcare coordinators across discovery, contracts, invoicing, and territorial intelligence. Public project context: portfolio projects. This is an architecture example, not a claim about live provider volume, municipal adoption, or production capacity accuracy.

The earlier request-fit lesson asks whether one family's constraints can reach a realistic candidate and response path. The capacity-ledger problem sits underneath that workflow. It asks whether the platform can prevent two requests from relying on the same recurring slot, explain why a previously visible option disappeared, and aggregate trustworthy unmet demand without counting stale profiles as local supply. That boundary matters to families, providers, marketplace operators, and territorial stakeholders for different reasons.

A practical state model is declared -> held -> committed, with branches to released, expired, withdrawn, and disputed. A hold should have an owner, quantity, reason, and deadline. It reserves attention during a bounded conversation; it is not proof that a childcare arrangement or legal contract exists. A commitment should reference the accepted arrangement and effective dates without storing more family detail than the capacity calculation needs.

Use compare-and-set or a transaction when creating a hold so two concurrent requests cannot both consume the final unit from the same capacity version. Expiry must release the quantity deterministically, while late provider confirmation should trigger reconciliation rather than silently reviving an obsolete hold. If agreements are finalized outside the platform, give providers a low-friction way to reconcile the ledger and record only the operational fact needed to reduce remaining capacity.

Freshness should depend on consequence and volatility. A recurring slot near its start date may need confirmation more often than exploratory capacity several months away. Define a policy with {capacity_class, confirmation_interval, reminder_window, expiry_action, reactivation_rule}. The UI should show the last confirmed scope and the consequence of staleness: still discoverable, excluded from actionable matches, or blocked from new holds.

Do not reward providers for clicking a generic 'still available' button if the underlying schedule has changed. Confirmation should present the exact capacity unit being renewed. Measure confirmation latency, stale-capacity rate, hold expiry, reconciliation corrections, and the share of actionable matches later rejected because capacity was no longer real. These metrics diagnose operational truth; profile views and message volume do not.

A capacity ledger can support territorial intelligence, but aggregation needs the same discipline as matching. Unmet demand should be grouped by compatible time window, care format, age band, geography, and start horizon. Ten unmatched requests are not one shortage if they ask for incompatible service units. Likewise, ten visible providers are not ten units of supply when their declarations are stale or overlap the same constrained schedules.

Publish confidence bands rather than false precision. A territorial view can separate confirmed capacity, recently declared capacity, stale or unknown supply, active holds, committed capacity, and structured unmet demand. It should also state coverage limits: platform participation is not the whole local market, and off-platform agreements may lag in reconciliation. The ledger improves the evidence boundary; it does not make the platform omniscient.

Common failures include double-holding the final slot, letting expired declarations remain rankable, treating a conversation as a commitment, asking providers to expose a detailed household schedule publicly, and aggregating sensitive family constraints into small identifiable groups. Another failure is operational coercion: a marketplace should not force providers to promise capacity merely to stay visible when availability is genuinely uncertain.

Keep public presentation coarser than the internal capacity unit, minimize household data in holds, and suppress territorial slices that are too small. When the ledger diverges from reality, preserve the history, mark affected matches uncertain, stop new holds on the disputed unit, reconcile with the authorized provider or operator, and create a new version rather than rewriting the old declaration. The cost is more state and operator design; the benefit is that uncertainty becomes visible and recoverable instead of hidden behind a green badge.

Test the model with seven synthetic cases: two families request the last recurring slot concurrently; a hold expires while the provider replies late; a provider changes only one weekday; an off-platform agreement consumes capacity; a stale profile remains discoverable; one arrangement ends and capacity returns later; and a municipality requests an aggregate view for a low-volume area. Inspect quantity, version, privacy, user explanation, and recovery for each transition.

The system passes only if it prevents conflicting consumption, distinguishes holds from commitments, expires evidence without deleting history, supports partial schedule changes, reconciles external outcomes, avoids exposing identifiable demand, and labels territorial coverage honestly. If an operator cannot explain which capacity version supported a match, what consumed it, when it became stale, and how it returned, the marketplace has availability display but no dependable capacity model.