A request returning HTTP 500 or a background job failing gives us an error message, but investigating it usually requires more: the producing commit, a source location, the failure chain, the operations that ran before the failure, and enough occurrences to see whether the inputs vary.

Repeated failures need separate handling. One defect inside a loop can produce thousands of reports. We need to retain the occurrence count without sending an alert or making an LLM request for each report.

We could have sent these errors to a hosted error-tracking service. We built a narrower system ourselves for three reasons: data sovereignty, direct integration with our application and operations pipelines, and control over which internal data leaves our infrastructure.

The implementation is split between Curling IO and our separate Operations application. Curling captures a bounded diagnostic envelope without waiting for another service. Operations imports and deduplicates it, sends the alert, asks a fast, lightweight, low-cost LLM for a structured analysis through OpenRouter when that integration is enabled, and stores the result with the issue. The redacted issue record is available through a command and a static report.

Data Sovereignty, Integration, and Security​

Data sovereignty​

Error reports can contain stack traces, internal file paths, deployment identifiers, integration failures, and selected application context. We keep the primary error record in the Operations SQLite database on our server in Canada. Its replication, backups, retention, and access controls use the same infrastructure boundaries as the rest of Operations data.

A hosted error-tracking service would maintain another copy of that diagnostic archive. Keeping it in Operations means we know where the archive lives, which accounts can read it, how long it is retained, and which recovery process restores it.

Direct integration​

First-party ownership lets us shape reports around Curling IO workflows instead of adapting them to a vendor event format. A request failure, background-job panic, handled Mailchimp failure, Stripe reconciliation problem, and browser exception can each include the bounded context appropriate to that boundary.

The stored issue is also easy to connect to other pipelines. The opening email is one durable job. An optional second job builds a redacted prompt, makes one OpenRouter request to a fast, lightweight, low-cost LLM, validates the structured result, and stores it beside the issue.

That LLM request is not an agent run. The model has no coding harness, repository access, tools, write access, or investigation loop. It cannot change code, resolve the issue, or mutate Operations data. It gets one bounded diagnostic record and returns one structured first-pass analysis.

A developer may later choose to give the same issue to a frontier coding agent through a read-only command. That optional second pass is a separate consumer, not part of the automatic alert pipeline. It typically uses a more capable model in a proper coding harness, can inspect the repository and use development tools, and is intended to do the deeper diagnosis when the answer is not already obvious. The issue is also rendered into the static report. None of these paths needs a vendor webhook or a second export format.

Both machine consumers are optional. Without them, Operations still captures and deduplicates errors, sends notifications, and generates the report. We are testing whether the first-pass LLM analysis and the coding-agent bundle reduce the time required to understand and fix an issue.

Security​

We do not send the full diagnostic archive, private source maps, request bodies, provider responses, or general service logs to an observability vendor. The capture code accepts specific safe fields, and Operations applies another redaction pass when reading them.

When enabled, AI analysis is an intentional exception to the local boundary. OpenRouter receives one bounded diagnostic prompt for an eligible issue, not access to the Operations database or error archive. The request disables storage and asks for zero-data-retention routing. The model returns a fixed structured analysis, and that result is stored in Operations. This is not the same as keeping every byte inside our infrastructure, but it lets us choose exactly what crosses the boundary for each analysis call.

Scope​

This covers application error tracking. It does not include performance monitoring, session replay, general log search, or distributed tracing.

The stored data is selected for debugging. It includes the full producing Git commit rather than only a display release, a bounded sequence of application operations, and separate generated and original JavaScript locations. It does not include data needed only for performance charts or replay.

A frontier coding agent is an optional downstream consumer of the data, separate from the first-pass LLM request. When a problem is not already obvious, a developer can choose to give the issue bundle to an agent that uses a more capable model and a proper coding harness. It can inspect the producing revision, form a hypothesis, change the relevant workflow, and write a regression test. The bundle includes the deployment and failure context that we would otherwise have to assemble manually.

The issue record is organized around that purpose:

When present, the first-pass analysis is stored beside these fields rather than replacing them. The captured error message, cause chain, stack trace, context, and occurrences remain available whether the analysis succeeds or not. A developer or coding agent can check its hypothesis against that underlying evidence.

Applications Write to a Local Handoff​

Curling does not call Operations, Postmark, or an LLM while handling the failing request or job.

The application writes a bounded diagnostic envelope to a local handoff. A separate Operations worker imports those envelopes once a minute. If Operations is unavailable, the original request still returns its original result and a background job still follows its own retry or failure policy.

This is also used for handled failures. A Mailchimp member sync may fail for one account while later accounts can still be processed. A Stripe recovery job may confirm that a payment succeeded remotely but fail while finalizing the local order. The business workflow owns whether it can continue, retry, reconcile, or stop. Error reporting records the evidence. It does not make the business decision.

Reporter failures are contained. A full handoff directory, malformed envelope, or unavailable Operations database does not recursively create another wave of reports.

Captured Context and Redaction​

Serializing the request, job payload, local variables, and provider response would copy credentials, personal information, payment details, and arbitrary customer input into a second database and a model request.

Each producing boundary defines its safe context.

Request reports retain the matched route, method, status, correlation ID, and safe source evidence. They do not retain raw paths, query strings, form values, or request bodies. Integration reports can include a provider request ID, status code, and retry stage, but not credentials, account email addresses, or provider response bodies.

Each request and job also carries a small ordered breadcrumb trail. A breadcrumb names an application operation, its outcome, elapsed time, and a few whitelisted scalar fields. The producer keeps the newest 16 events within 4 KiB. Unknown keys and nested values are dropped.

A failed checkout might retain this sequence:

+0 ms     http.request    started
+5,000 ms database.write failed    status=busy

This records which operation failed and how long it ran without storing the order form or customer record.

Operations redacts the evidence again when it builds the diagnostic bundle. This protects readers from mistakes in current or historical producers.

Deduplication and LLM Request Limits​

Each request is cheap. Thousands of them are not. A simple error inside a tight loop is the main cost risk.

Operations groups occurrences into an issue using the application, environment, full producing commit, and a normalized error fingerprint. The build is part of the identity because an investigation must start from the code that actually ran. A new deployment creates a new issue instead of quietly mixing evidence from two revisions.

Volatile values such as numeric identifiers are normalized before fingerprinting. One reconciliation loop that fails for item 1001 and then item 1002 should normally be one issue with two occurrences, not two issues.

The database enforces one analysis job for each issue and prompt version. A thousand repeated reports therefore produce:

1,000 occurrences
1 deduplicated issue
1 opening notification
1 LLM analysis job

Deduplication is not enough protection. A broken fingerprint or a broad outage could create many distinct issues at once, so the worker starts analysis for at most 10 new deduplicated issues in any rolling hour. Excess analyses are marked as skipped. They do not form an expensive backlog that wakes up later and drains the account after the outage is already understood.

Ten is intentionally unsophisticated. If more than ten genuinely different errors appear in an hour, we probably have a larger incident and do not need a model to explain every symptom. If bad normalization created the extra issues, we need to fix the normalization, not pay for the noise.

Notification and Analysis Jobs​

Notification and analysis are separate durable jobs.

The worker processes the opening email first. That email says AI analysis is pending and goes out even if the model credential is unavailable, the provider is down, or the hourly analysis budget is exhausted. The analysis runs afterward with extra-high reasoning, and its structured result is attached to the same issue in SQLite.

This uses a fast, lightweight, low-cost LLM, not an agent. It receives one bounded diagnostic record and returns a summary, likely cause, suggested fix, confidence, supporting evidence, and missing context. If the evidence does not support a reasonable diagnosis, the confidence and missing-context fields should say so. A suggested fix is only a suggestion. The model has no write access and cannot edit code, resolve the issue, deploy a fix, or make a business decision. We use extra-high reasoning for this request without moving it to a heavier model.

The optional second pass comes later, if a developer decides the issue needs more work. A frontier coding agent can use its more capable model and coding harness to verify the first-pass analysis against the source, trace, breadcrumbs, and producing commit. If the analysis is wrong, disabled, or unavailable, the issue and alert still contain the captured evidence.

Provider failures use bounded retries. A worker restart can recover a stale claim, and a permanently failed analysis is not reopened every time another occurrence arrives. One claimed attempt makes at most one LLM request.

The processing order is:

1. Preserve the failure.
2. Send the alert.
3. Analyze it asynchronously when eligible.
4. Make the evidence and analysis available for investigation.

The email path does not depend on analysis completion.

Browser Errors and Source Maps​

Uncaught JavaScript exceptions and unhandled promise rejections use the same issue model, with one additional problem: the browser reports a location in a generated asset.

Curling sends bounded browser reports to a same-origin endpoint. The server adds the trusted build identity before writing the handoff envelope. Production source maps are private release artifacts with sourcesContent removed, and Operations uses a map only when its manifest matches the occurrence's full Git commit.

When mapping succeeds, the issue keeps both locations:

generated: /assets/islands/checkout.js:42:7
original:  apps/curling/platform/src/islands/checkout.ts:118:14

When mapping fails, the generated evidence remains usable and the issue records an explicit status such as release_missing, map_missing, or unmapped. An unavailable mapping remains unavailable rather than being presented as an original TypeScript location.

Browser capture has its own per-page and server-hour limits. Those limits contain reload loops before Operations deduplication and the hourly LLM analysis budget even come into play.

A Command and a Static Report​

One issue can be retrieved through a bounded JSON command. It opens the Operations database read-only and returns the exact producing commit, source locations, first and latest occurrence, up to five meaningfully different occurrences, breadcrumbs, safe context, and stored analysis. It is used for command-line investigation. A developer's coding agent can call the command to receive that bounded bundle without receiving general access to the Operations database.

The static report presents the same record as an index and one detail page per issue.

The report is rendered in Rust using the same Basecoat and Tailwind setup as the Curling site. It contains no client JavaScript and has no write actions. The generator stages the complete output before replacing the previous report, and fingerprints the issue data and stylesheet. If nothing changed, it leaves the existing files alone.

The report has no write endpoint. Marking an issue resolved and authorizing a repair belong to explicit Operations commands with narrower permissions. Serving and authentication are separate deployment concerns.

The Diagnostic Drill​

The implementation has a no-network diagnostic drill that creates plausible failures and runs the whole workflow against a temporary Operations database. It includes:

• an HTTP request that times out on a database write;
• an unhandled background-job panic;
• a handled Mailchimp synchronization failure;
• a Stripe payment that succeeds remotely but fails during local finalization;
• a browser exception with generated source evidence;
• a 1,000-occurrence reconciliation loop; and
• enough distinct issues to cross the 10-per-hour LLM analysis limit.

The drill sends no email and makes no LLM request. Fake Postmark and analysis boundaries record what would have happened, including the structured analysis. It asserts the stored issues, job counts, notification order, redaction, source-map status, throttle behavior, and final diagnostic bundle.

The report screenshot above comes from that fixture: 17 issues and 1,016 occurrences, with 16 fake analyses attached and one skipped by the hourly limit. These counts verify the loop and throttle behavior rather than only the single-error path.

The usual human-in-the-loop AI agent pattern goes something like this: the model requests a tool call, the agent runtime pauses, a human approves the call, and the runtime resumes so the tool can execute.

That is a reasonable general-purpose design. It is also stricter than simply letting an agent call every tool it can see. For Curling IO, we wanted to expose the smallest possible surface to the model and put an application-owned guardrail around every path to a write. That led us to a stricter question:

If the application already has the exact call details, why hand control back to the agent at all?

By the time we ask a club manager to approve an operation, Curling IO has parsed the model's request, resolved every default, checked the current application state, produced a fixed preview, and stored the exact arguments. The model has nothing useful left to contribute to execution, so we do not let it execute the operation or resume it merely to carry out the approval.

The agent proposes. The application turns that proposal into a contract. The human approves the contract. Rust executes it.

The common approval pattern​

The OpenAI Agents SDK human-in-the-loop flow can pause a run when a tool requires approval. The application serializes the RunState, records approvals or rejections for pending tool calls, and resumes the original run. The approved tool executes as the run continues.

LangGraph interrupts support a similar shape. A graph can stop before a tool node, let a person approve, edit, or reject the call, then resume toward the tool or back toward the model.

Those frameworks solve a broad problem. An agent may have many tools, nested agents, long-running work, and several points where a human needs to intervene. Keeping the pending tool call inside durable agent state is useful in that world.

Curling IO has a narrower problem. We own the application, the database, the authorization rules, the interface, and every operation an assistant may propose. We do not need a generic agent runtime to remain authoritative after a proposal has crossed into application state.

This is the difference:

Not resuming the model after approval has a narrow meaning. While a proposal is being prepared, safe validation errors can go back into the active model loop so it can correct its request. If a manager declines a proposal, or execution finds a recoverable state change, Curling IO records app-authored revision context for the manager's next message. That starts a new model turn with the safe reason included. A terminal internal failure is recorded and reported as non-retryable instead. The model can adapt where that is useful, but it never owns execution of the approved contract.

The first pattern can be implemented safely. It's not that resuming an agent automatically changes an approved call. A good runtime should preserve the exact call and its identity. For a first-party application, the paused model run is unnecessary operational state once the application has accepted a complete proposal.

Human approval is not enough​

An approval button is only meaningful if the application can say exactly what was approved.

Suppose a model asks to refund an order. A weak approval could show:

Refund this customer?

That leaves almost every material decision hidden. Which payment? How much? Which line item? Where will the money go? Is the model using a value it calculated itself? Could it select a different destination when execution resumes?

Our refund review shows the participant, product, discount, payment, amount, destination, and resulting order total. The manager is not approving the model's general intention to fix an order. They are approving one concrete operation with one set of effects.

That requires more than a tool schema. It requires an application-owned contract that defines all of these together:

• the fields the model must supply;
• the defaults Rust is allowed to resolve;
• valid and invalid combinations;
• the typed representation stored for approval;
• the fixed human review presentation;
• revalidation against current state;
• the executor;
• the typed result and safe handback; and
• the audit events for the whole lifecycle.

If those pieces are split between a prompt, a generic JSON schema, a hand-built review page, and an unrelated executor, they will drift. A new field can affect execution without appearing in the review. A prompt can describe a default differently from the application. A model can produce a value the ordinary interface would never allow.

In Curling IO, those are all parts of one capability.

The smallest useful surface​

Our first preference is not to guard a broad agent surface. It is to avoid presenting that surface in the first place.

Each assistant is confined to one section of Curling IO and receives only the context needed for the current task. The order assistant does not receive an organization-wide database view. The email assistant does not inherit the order assistant's tools. Tenant identity, permissions, internal field names, provider payloads, and unrelated customer records stay on the application side of the boundary.

The same rule applies to operations. An assistant sees a small catalogue of things it may propose, not a generic write API. Its model-facing fields contain only the choices that genuinely require interpretation. Rust supplies resource scope, resolves defaults, calculates derived values, rejects unsupported combinations, and builds the human preview.

Then we add a guardrail at every remaining vector from model output to durable state:

• bounded, application-written context before the model call;
• task-specific read tools with server-owned tenant scope;
• strict parsing and validation of the model's operation request;
• typed arguments and previews built by Rust;
• human approval of every material effect;
• authorization, expiry, and state revalidation at execution time;
• idempotency at the proposal and domain-record boundaries; and
• typed, redacted outcomes after execution.

No one check carries the whole safety argument. Human approval does not replace authorization. A type does not prove that current state still permits the operation. Revalidation does not prevent a duplicate provider call after a lost response. The surface stays small, and every boundary still has its own job.

The model request is not the stored proposal​

Our order assistant has a model-facing operation called propose_payment_refund. Its input is intentionally small. The model identifies the relevant payment, line item, discount, and requested destination from the evidence Curling IO gave it.

Rust does not store that request directly. It validates the request against the server-owned order investigation, calculates the refund using application rules, resolves a concrete destination, and creates typed arguments:

#[derive(Clone, Debug, PartialEq, Eq, Serialize, Deserialize)]
struct OrderRefundArguments {
    order_id: i64,
    payment_id: i64,
    line_item_id: i64,
    discount_id: i64,
    amount_cents: i64,
    refund_destination: RefundDestination,
}

The model does not choose amount_cents. It cannot say "use the original payment method" and leave that decision until later. Rust resolves that phrase to a concrete RefundDestination before the manager sees anything.

The review is typed separately from the executable arguments:

#[derive(Clone, Debug, PartialEq, Eq, Serialize, Deserialize)]
struct OrderRefundPreview {
    participant_name: String,
    product_name: String,
    discount_name: String,
    payment_method: PaymentMethod,
    amount_cents: i64,
    current_order_total_cents: i64,
    resulting_order_total_cents: i64,
    currency: String,
    refund_destination: RefundDestination,
    product_configuration_unchanged: bool,
}

The arguments contain what execution needs. The preview contains what a human needs to understand the consequences. Both come from the same validated domain facts, and both are frozen together.

JSON appears at the database boundary, but it is not the programming model. An operation is parsed back into its Rust type before it can be revalidated or executed. An operation kind cannot be dispatched into another operation's argument type.

A proposal is durable application state​

Each proposal gets an opaque public identifier and a row containing its tenant, requesting administrator, section, resource, operation kind, exact arguments, preview, status, and expiry. It also records approval, execution, result, and failure information.

A simplified view of the Rust side looks like this:

struct OperationProposal<Arguments, Preview, Result> {
    public_id: ProposalId,
    interaction_id: InteractionId,
    scope: OperationScope,
    requested_by: UserId,
    operation_kind: OperationKind,
    arguments: Arguments,
    preview: Preview,
    status: ProposalStatus,
    expires_at: DateTime,
    approval: Option<Approval>,
    outcome: Option<OperationOutcome<Result>>,
}

struct OperationScope {
    organization_id: OrganizationId,
    section: AssistantSection,
    resource_id: ResourceId,
}

Arguments, Preview, and Result are the types owned by one operation contract. SQLite stores their serialized form and the proposal's audit events, but application code cannot execute those values without decoding them through the matching contract.

The conversation is not the source of truth for this operation. Neither is the model provider's stored run state. A pending proposal survives a browser disconnect, a model change, or a deployment because Curling IO can reconstruct the approval from its own records.

This also gives the approval request a very small input. The browser submits the opaque proposal identifier. It does not submit the refund amount, destination, message body, or any other approved value a second time.

Approval creates one execution contract​

When the administrator selects Approve refund, Curling IO verifies all of the ordinary request boundaries again:

• the signed-in user still has access to the organization;
• the proposal belongs to that organization, section, and order;
• the proposal is still pending and has not expired;
• its stored operation kind and arguments can still be parsed; and
• the current user is still allowed to perform the underlying operation.

Only then does the proposal move from pending to executing. The update is atomic and produces a typed execution contract:

struct ExecutionContract<Arguments> {
    proposal_id: ProposalId,
    operation_kind: OperationKind,
    scope: OperationScope,
    arguments: Arguments,
    approved_by: UserId,
    approved_at: DateTime,
}

match proposals.approve_for_execution(proposal_id, administrator, now)? {
    Approval::Claimed(contract) => execute(contract),
    Approval::AlreadyCompleted(outcome) => present(outcome),
    Approval::NotApprovable(reason) => reject(reason),
}

The repository issues Approval::Claimed only when it atomically moves the matching, unexpired proposal from pending to executing. If another request already approved, declined, or completed it, the handler does not receive an execution contract and therefore does not get a second authorization to execute.

The model is not involved in any of this. Approval is an authenticated request from the administrator to Curling IO, not another message in the conversation.

Revalidation is part of execution​

Freezing a proposal prevents its arguments from changing. It does not freeze the rest of the world.

A payment may have been refunded in another tab. Someone may have changed a broadcast's audience. The administrator may have lost access. A proposal may have sat open long enough to expire.

The refund executor therefore reloads the order and proves the original evidence still holds. It checks that:

• the same line item and discount evidence still exist;
• the calculated amount has not changed;
• the selected payment still exists and has enough refundable value;
• no unresolved refund attempt makes another call unsafe; and
• the concrete destination is still compatible with the payment and account.

If a material fact changed, the old proposal fails closed. The application records a revision-required outcome, explains the changed condition in safe terms, and asks the manager to prepare a new proposal. It does not silently update the amount under an approval that showed something else.

This is optimistic concurrency in human terms. The preview is a claim about a particular state. Revalidation proves that claim is still true when approval arrives.

Idempotency has to reach the domain record​

Conditional approval prevents the same pending proposal from starting twice, but that alone is not enough for operations with external effects.

Consider an online card refund. Curling IO can send the provider request and lose the HTTP response. At that point, retrying may create a second refund. The correct outcome is not a generic failure. It is OperationOutcome::NeedsReconciliation { status_path }.

The refund workflow retains stable proposal and provider identities, records the unresolved attempt, and refuses to improvise another call. Recovery checks the original attempt and eventually records the authoritative result.

For local database operations, the domain mutation and successful proposal outcome are committed in the same transaction. For external operations, the proposal stays in an executing or reconciliation state until recovery closes the uncertainty.

Repeated approval of a completed proposal returns its original stored outcome. It does not manufacture a fresh success message, and it does not execute the operation again. Replay is a delivery fact, not a new business result.

That distinction matters because HTTP responses are not durable. The operation record is.

Handing back the result without resuming the agent​

The application already knows what happened, so it should not spend another model call asking for a paraphrase.

We use a small typed outcome vocabulary around each operation's own result:

enum OperationOutcome<S> {
    Succeeded(S),
    NeedsReconciliation {
        status_path: String,
    },
    RevisionRequired {
        reason: RevisionReason,
    },
    TerminalFailure {
        correlation_id: String,
    },
}

The operation-specific S might identify the refund and resulting order balance, or state that an email draft was copied into the editable form. The shared enum says what the user and system can safely do next.

One stored outcome drives several projections:

• a localized browser response;
• an app-authored follow-up in the assistant conversation;
• bounded context supplied if the manager sends another message; and
• eventually, the same semantic result through a machine-facing agent API.

The model does not classify the failure or decide whether retrying is safe. Rust does. On the next user turn, a recoverable outcome gives the model enough safe context to investigate again or prepare a revised proposal.

For an internal invariant failure or corrupt stored contract, the application records the operational error itself. The model and browser receive a terminal message with a correlation identifier, not a stack trace and not an invitation to keep trying. Asking the agent to submit a support ticket would add another failure-prone step while throwing away context the application already has.

Two assistants were enough to expose the boundary​

We currently have two operation contracts, and they are deliberately different.

The order assistant can propose order.refund_missing_discount. Approval may lead to a financial operation with an external provider, uncertain responses, and reconciliation work.

The email broadcast assistant can propose email_broadcast.apply_draft. Approval copies frozen filters, subject, and message into an editable form. It does not create or send the broadcast. This is a local operation, but it still recounts the audience before applying the draft. If the audience changed, the manager needs a new proposal.

That difference stopped us from building a refund framework and calling it an agent framework. The shared part is small: lifecycle, approval identity, outcome semantics, audit, and handback. Argument types, previews, revalidation, and execution remain with the operation that understands them.

We expect to add assistants to a couple dozen sections. Each new operation will need a typed request, frozen arguments, a human preview, a revalidator, an executor, a typed result, and focused tests for expiry, stale state, replay, and failure classification.

That is more work than adding another function tool to a prompt. It is supposed to be.

What this pattern is, and what it is not​

We did not invent human approval, durable commands, optimistic concurrency, capability security, or idempotency keys. The design borrows from all of them. Agent frameworks already support pausing tool calls for review.

The useful shift is treating the agent's requested mutation as input to an application command, not as the command itself. The application materializes a new durable object with stricter semantics than the model call that inspired it. Once that object exists, the model run is disposable.

This pattern is not necessary for every assistant response. Read-only answers do not need frozen proposals. Draft text that has no application effect can remain draft text. But if an operation changes customer data, sends something, moves money, or alters access, we want a stronger statement than "the model called a tool and a human clicked approve."

We want to know exactly what the application promised to do, exactly what the human approved, exactly which current facts were rechecked, and exactly what happened afterward.

That is the contract.

Curling IO v3 includes optional in-app assistance for most tasks a club manager does. It appears within the section where the work is happening and uses the context needed for that work.

An assistant can investigate a problem, explain what it finds, and prepare an operation for review. It performs that operation only after an administrator explicitly approves it.

A change from our earlier plan​

Earlier this year, we wrote about letting clubs connect their own AI agent to Curling IO. That approach put the choice and configuration of the model in the club's hands. We've since changed direction. The main experience will be assistants built into Curling IO, with the external model provider selected and managed by us.

Managing the provider ourselves means we can:

• control exactly what information and operations are available for each task;
• require Zero Data Retention from the model provider; and
• avoid asking every club to configure and pay for its own model account.

It should also cost less to operate because each assistant receives the context it needs instead of having to discover how the entire system works. When an assistant needs better context, we can improve its supporting documentation and task design for every club.

Investigating an order​

We set up this premise in a demo club, then worked through it using the in-app assistant. The responses shown below were not scripted.

Suppose a club offers a Youth discount of 50% to curlers aged 17 and under. The discount is assigned to most of the club's leagues, but an administrator misses one while setting up the season.

Madison registers for that league and the order is paid at full price. Later, her parent calls the club. The club manager opens the order and asks:

Madison's parent called. They paid full price, but thought Madison was supposed to get the Youth discount. Can you look into it?

The assistant can inspect the information relevant to that order. It checks Madison's age at the start of the season, the requirements of the Youth discount, the league she purchased, and the discounts assigned to it.

In this case, Madison meets the age requirement. The problem is that the Youth discount was not assigned to the league, so it was not considered when the order was priced.

That distinction matters. Checkout followed the club's configuration. The assistant has found a likely setup mistake, but it does not assume that the club intended the discount to apply. The club manager confirms that before anything is changed.

Preparing the correction​

After the manager confirms that the league should offer the Youth discount, the assistant calculates the adjustment using the same pricing rules as checkout. It prepares a reduction to the order and the corresponding refund against the original payment. For Madison's $275 registration, the proposed refund is $137.50.

The manager can review the calculation, the payment being refunded, where the refund will go, and the resulting order balance. Nothing changes until the manager approves the operation. If the refund should go to account credit instead, the manager can decline the proposal and ask for that change.

The approval corrects this order. It does not change the league's configuration. The assistant explains that the manager still needs to open the product and assign the Youth discount so future registrations receive it.

After approval, the order shows the $137.50 reduction and the refund against the original payment.

That is an intentional boundary. The order assistant can investigate and correct that order. It cannot cross into editing a product just because the investigation found a product configuration problem.

We may eventually allow an explicit handoff from the order assistant to the assistant responsible for products. For now, each assistant stays within a tight, task-specific sandbox.

Preparing an email broadcast​

We set up this premise in a demo club, then worked through it using the in-app assistant. The responses shown below were not scripted.

A club manager can also ask the assistant to prepare an email for a particular audience. The assistant prepares the audience filters and message, then presents the broadcast for review.

For example, a manager can ask:

Please prepare a short reminder for everyone registered in Tuesday Mixed Doubles this season. Let them know the first draw is Tuesday, October 7 at 7:00 PM and ask them to arrive 15 minutes early.

The assistant tests the requested filters separately from the broadcast form, finds four matching recipients, and prepares the subject and message. It then presents the complete draft for review. The manager's form has not changed yet.

If the manager chooses Apply to broadcast, Curling IO copies those exact filters and message into the editable form. The manager can change them further, inspect the resulting recipients, and use the normal send confirmation when ready. This step does not create or send the broadcast.

Limited to the current task​

Each assistant is optional and inactive until someone uses it. When a manager asks for help, Curling IO gathers only the information relevant to completing that task and provides it to the model in a limited, structured form.

The order example does not require unrestricted access to the club. It needs the order, the participant and purchase information relevant to its pricing, and the nearby discount configuration needed to answer the question. Unrelated orders and unrelated member information are left out.

Curling IO also decides which task-specific tools are available in each section. The order assistant may inspect pricing and propose an order correction. Editing a product is not available. The email broadcast assistant receives a different set of read-only tools for preparing and previewing an audience and message.

The model cannot call arbitrary application code or add tools to its own task. Most importantly, it is not given a tool that performs an approved operation.

Data processing​

Curling IO requires the external model provider handling each assistant request to operate under a Zero Data Retention policy. This means the provider can process the information supplied for the request and return a response, but cannot retain the prompt or response afterward or use it to train models. Provider prompt logging is not enabled.

Approval is part of the operation​

Preparing an operation and performing it are separate steps. The assistant can present a proposal, but it cannot approve or perform it.

Each operation has a contract that defines its required information, valid values, defaults, review presentation, and execution rules. If the assistant cannot fill every required field from the information available, and there is no valid default, it has to gather more information or ask the manager.

The proposal contains the exact action and every parameter that can affect the result. Curling IO stores that snapshot and uses the contract to render the review shown to the manager. The assistant does not decide which fields to show. For the refund, the review includes the participant, product, discount, payment being refunded, refund amount, refund destination, and resulting order total. For the broadcast, it includes the audience filters, current recipient count, subject, and full message.

Approval turns that frozen proposal into an execution contract. Approval is an authenticated request made by the administrator to Curling IO. It is not a prompt sent to the model. The model is not resumed after approval and never receives a function that can carry out the contract.

Curling IO loads the stored contract and executes it through application code. No model is running at this point, so its parameters cannot change between review and execution. The contract is single-use. A batch, another action, or any material change requires a new proposal and another approval.

Approval does not bypass the regular application. Curling IO checks the administrator's permissions, validates the current state, and applies the same business rules used by the ordinary interface. If the operation is no longer valid when it is approved, it is rejected instead of being performed from stale information.

If the manager chooses Decline, Curling IO records that decision and asks what they would like changed. Their next message continues the same conversation with the decline included as context. The declined proposal cannot later be approved.

Proposal creation, approval, decline, execution, and the resulting record are audited. Operations that can be retried also retain the proposal identity so an interrupted request cannot perform the same contract twice.

As we add assistants to more sections before Curling IO v3 launches, each will have its own task-specific information and contracts. The approval boundary will remain the same.

Clubs often need to send purchase information to systems outside Curling IO. That might mean updating a spreadsheet, notifying staff, or starting a workflow in another service.

Rentals are one example. Someone may need to prepare the lounge, reserve tables, arrange catering, or add the booking to a staff spreadsheet.

Curling IO v3 webhooks can send that product purchase to Zapier, n8n, or another HTTPS endpoint when it is submitted, paid, cancelled, or rescheduled.

Choose the products to watch​

One webhook sends one kind of notification to one destination. A club can send:

• every product;
• products matching selected product types, such as rentals;
• individual products, such as four specific corporate rental options.

The product filter has three scopes. If two receivers need different products, the administrator creates a separate webhook for each receiver and scope.

Rentals and their add-ons are products. The same webhook configuration also works for memberships, leagues, programs, and other products.

A webhook can send every product, selected product types, or individual products. This one sends paid rental purchases to Zapier.

Choose when to send​

A webhook sends for one trigger:

• A product is submitted after checkout finishes.
• A product is paid in full the first time its line item is fully paid.
• A product is cancelled when a refund allocation cancels the line item. Reducing its quantity or value does not send this notification.
• A product is rescheduled when an administrator changes the purchased product's start time in the calendar.

A workflow that needs more than one trigger can use separate webhooks at the same destination.

Choose what the receiver gets​

The club chooses which purchase fields each webhook sends. New webhooks start with 16 recommended fields covering the order, registration, product, pricing, and schedule. Purchaser and participant information is not selected by default.

Fields are grouped and searchable. An administrator can select a whole group, clear it, or return to the recommended selection. The payload preview updates immediately, so the club can see the JSON keys and representative values before saving or sending a test.

This example uses a small field selection so the complete payload is visible. Delivery details remain in every payload, while the other keys follow the saved selection.

Purchaser and participant fields are marked Sensitive. Custom participant and registration questions are marked May be sensitive because the answer depends on the question. Curling IO warns the administrator but lets the club decide whether the destination should receive that information. Passwords, authentication tokens, payment card data, and payment-provider secrets cannot be selected.

Curling IO accepts only public HTTPS destination URLs, which encrypts the request in transit. Curling IO has no control over how Zapier, n8n, or another receiving service handles the data after delivery and is not responsible for that third-party handling. The club is responsible for choosing the service and deciding which fields to send to it.

Test the receiver before enabling the webhook​

The administrator can leave a webhook disabled and select Send test. The test uses the saved field selection and the real delivery path. It contains a representative rental, so Zapier or n8n can discover the selected JSON fields before the webhook is enabled.

In Zapier, use a Webhooks by Zapier > Catch Hook trigger. In n8n, use a Webhook node. Copy the receiver's HTTPS URL into Curling IO, send the test, and map the fields before enabling the automation.

Delivery reliability​

Webhook calls run in the background. Curling IO retries network failures, timeouts, rate limits, and server errors up to five times. The receiver can use the stable webhook publication ID to discard a duplicate if a request succeeds but its response is lost.

Each request is signed with HMAC-SHA256 for receivers that can verify it. A Zapier Catch Hook normally relies on its hard-to-guess URL instead, so that URL needs to be treated like a password.

Administrators can inspect Recent Deliveries, see attempts and HTTP statuses, retry a failed retained delivery, rotate the signing secret, or disable the webhook. Detailed payload and delivery data are removed after 30 days. Each delivery stores its exact request body, and every retry sends that same body even if the field selection or purchase data changes later.

Recent deliveries show successful requests, failed attempts, HTTP statuses, and when a failed delivery can be retried.

See the webhook setup guide for the payload, Zapier and n8n steps, retry rules, and signature verification.

Curling IO v3 includes a new draw scheduling screen for event games. The schedule is a grid of draws and club resources, with unassigned games kept in a queue beside it. You can drag and drop games, lock specific placements, and use Allocate and Optimize around those locks.

Unlike a separate schedule template generator, this editor works with the event's actual teams, stages, games, resources, and draw times. Saving the schedule updates the event directly.

You can try most of the scheduling interface now at CurlingSchedules.com. It uses generic teams and browser-local saves instead of an event's actual games, but the grid, drag-and-drop editing, locks, catalog schedules, fairness inspection, and optimization are available today.

The Curling IO v3 schedule editor keeps the game queue, event controls, draw times, resources, and scheduled games in one view.

The Draw Scheduling Tool​

Version 2 generates draw schedule templates and uses dropdowns to place games. It does not have this editor, the full canonical catalog, game locks, or local optimization around manual changes.

The v3 editor supports:

• drag and drop games between the schedule and game queue
• edit draw times, add draws as games are placed, or delete a draw and return its games to the queue
• lock a game so Allocate and Optimize leave it where you put it
• allocate round-robin, ad hoc, and bracket games under their different ordering rules, including queued games when requested
• fill unused sheets with games from the next logical round when compact draws matter more than keeping every round in a fresh row
• inspect exactly which games produce the Max, Total, and Back-to-back fairness numbers
• add an ad hoc game to a specific round robin, so it remains part of that stage's standings and scoring
• import CSV assignments for existing games without recreating the event's competition structure
• save the current arrangement as a club draw schedule template, or deliberately apply a matching template
• start from a validated canonical schedule, then optimize event-specific changes without moving locked games

These are curling-specific scheduling rules. The allocator distinguishes round-robin, ad hoc, and bracket games; understands logical rounds that may span several draws; accounts for selected resources and fixed placements; and scores how often teams return to the same sheet, including consecutive draws. It puts ad hoc games after the affected teams' round-robin games, and unlocked bracket games after round-robin and ad hoc play. A locked game is exempt from those placement rules.

When an event contains one complete round robin and no conflicting locks, Allocate checks our schedule catalog before doing any browser-side search. Multiple iterations repeat the matching catalog layout as a starting point. A matching club draw schedule template is presented separately and is applied only when the drawmaster chooses it. Once locks, ad hoc games, multiple stages, or manual placements change the problem, the browser optimizer works from the actual event schedule.

The blue lock marks a placement that automatic allocation must preserve. The queue contains an ad hoc second meeting between A and B, ready to be placed.

See the Draw Scheduling Workflow​

This tutorial shows how to configure, allocate, edit, inspect, optimize, save, and reuse an event draw schedule.

For Drawmasters: How We Built the Schedule Catalog​

The rest of this article gets technical. It covers how we scored schedules, tested algorithms, used exact solvers, and distinguished best-found schedules from proven optima. You've been warned!

The v3 scheduling system has two computational parts. An offline Rust application searches for, validates, and in some cases proves optimal base schedules. A JavaScript optimizer handles event-specific changes in the browser, including locked games, ad hoc games, and competition stages sharing the same resources.

The offline work produced a versioned catalog covering all 736 combinations from 2 through 24 teams and 1 through 16 sheets, under both supported draw-packing modes. Curling IO v3 loads this catalog directly when allocating an event schedule.

The catalog currently contains 449 layouts. Of those, 419 are proven optimal and 30 are the best result found so far. That includes 448 distinct requirements in the practical catalog envelope and one historical outlier retained for compatibility.

Scheduling Objective​

We score sheet fairness as an ordered tuple:

1. Maximum repeat visits: the largest number of extra visits one team makes to one sheet.
2. Total repeat visits: every visit by every team after its first visit to a sheet.
3. Back-to-back repeat visits: cases where a team plays on the same sheet in adjacent draws.

Lower is better. We compare the first number first, then the second, then the third. Runtime never compensates for a worse schedule.

An eight-team, four-sheet result of (1, 24, 0) means no team visits one sheet more than twice, there are 24 repeat visits in total, and nobody returns to the same sheet in consecutive draws.

Those 24 repeats are unavoidable. Eight teams make 56 team-sheet visits across seven draws, but there are only 32 unique team-and-sheet combinations. Even a perfectly balanced schedule has at least 56 - 32 = 24 repeat visits. Reaching that lower bound with a maximum of one extra visit and no consecutive repeats proves that there is nothing left to improve under our scoring rules.

The stats are inspectable in the schedule editor. Selecting one highlights the games and teams that produced it.

We chose an ordered tuple instead of a weighted score because weights hide tradeoffs. Is reducing one team's sixth visit to Sheet A worth creating three new consecutive repeats elsewhere? A scalar score can answer that only after someone invents a conversion rate. The tuple makes the priority explicit.

How Good Is AI for Draw Schedule Generation?​

We tested whether current general-purpose AI models could produce these schedules from a normal drawmaster request. This was a direct, one-shot model test, not an agent with access to our validator or a repair loop.

The prompt took some work. Early versions that sounded completely natural often returned missing or duplicate matchups, especially with an odd number of teams. We refined it to approximate the clarifications a drawmaster might give in a short conversation. The final version stated the expected number of games, asked for one Markdown table, and asked the model to check its work. It did not provide the matchup inventory, minimum draw count, fairness tuple, cached schedule, circle method, or any other scheduling algorithm.

Only the team count, sheet count, labels, and expected game count changed for the other fixtures.

We sent that frozen prompt to OpenAI and Anthropic through their first-party APIs. We added Gemini in a separate pass through OpenRouter, pinned to Google AI Studio with provider fallback disabled. Each model received the same five fixtures once: 8 teams on 4 sheets, 8 on 2, 9 on 4, 11 on 5, and 14 on 7. Every request started with a fresh one-message context, used the provider's default reasoning behaviour, and had a hard five-minute timeout. We kept every response, including timeouts.

The familiar 8-team, 4-sheet layout has been published for years and may appear in model training data. We kept it as a calibration case, not proof that a model derived the answer. We also kept informal consumer-chat experiments out of this table because those products may add hidden instructions, model routing, and reasoning settings.

The results were parsed and checked independently. Harmless formatting could be normalized, but the evaluator could not add or remove a game, change a pairing, or improve a sheet assignment. A schedule had to contain every matchup exactly once, keep each team to one game per draw, and pass the same fairness calculation used by Drawmaster. Invalid schedules did not receive a fairness score.

Reasoning tokens are included in the output totals, not added a second time. One pass over five fixtures is useful baseline evidence, but it is not a statistically strong ranking of the models.

OpenAI and Claude returned a valid, minimum-draw schedule for every fixture. OpenAI matched or beat Claude on all five. Sheet fairness was a different result:

Gemini finished every request in 5.1 seconds or less, but three of its five schedules were invalid. The 8×4 and 14×7 answers repeated matchups despite claiming in their own prose that every pairing had been verified. The 9×4 answer repeated two matchups and scheduled one team twice in its final draw. Its two valid schedules used the minimum number of draws, but neither matched the catalog's fairness score.

Our simple neutral-start Rust search matched OpenAI's best result on all five fixtures after a few seconds of combined local work per fixture. The much heavier offline process then produced the current catalog, which is better on four of the five fixtures and equal on the fifth.

AI is still useful here as another offline candidate generator. It can find a schedule our existing methods missed. We just treat its answer the same as any other untrusted candidate: parse it, validate every matchup and conflict, calculate the score ourselves, and prove optimality when we can. For custom event schedules, the browser optimizer works around locks and extra games under a 100 ms deadline instead of asking a general model to rebuild the schedule from prose.

Search Envelope​

Our practical envelope contains:

• 2 through 24 teams
• 1 through 16 selected sheets
• one complete round robin
• one iteration
• no locked, ad hoc, or bracket games
• two behaviours when one logical round spans multiple draws: start each round in a fresh draw, or fill blank sheets with games from the next round

That is 23 × 16 × 2 = 736 lookup keys.

The two packing settings cannot always produce different layouts. If all games in a round fit in one draw, for example, there are no blank sheets for the next round to fill. Aliasing those equivalent cases reduces the envelope to 448 distinct layout requirements. The catalog stores 449 layouts because it also retains one historically used shape outside the envelope, 26 teams on 7 sheets.

This boundary was not arbitrary. We analyzed Curling IO data. Among thousands of generated, single-iteration schedules where sheets were scarce, 98% had at most 20 teams and 8 sheets. The five most common shapes were 8×4, 12×6, 6×3, 10×5, and 9×4. Together they accounted for 63% of that cohort.

We extended sheet coverage to 16 because surplus-sheet layouts are cheap to store and useful to support. We later expanded the team boundary to 24. The 42-team outliers in the historical data still did not justify expanding the interactive target that far.

Research Harness​

The original CurlingSchedules implementation already had a circular round-robin generator, a greedy sheet allocator, local cleanup moves, and a small exact-match cache. We had also done a lot of experimentation, including a simulated annealing branch.

The first issue was measurement. Some historical runs used different weights, some used an older definition of maximum repeats, and some tests did not assert what their names claimed. Results using different objective functions could not be compared directly.

We built an application in Rust as a research harness with:

• one reference schedule model and independent validator
• deterministic fixtures and seeds
• swappable search strategies
• paired comparisons under equal budgets
• text, JSON, and CSV reports
• production-frequency weighting from Curling IO data
• resumable, atomic checkpoints for long-running searches
• a versioned catalog with the method, seed, effort, runtime, lower bound, and proof status attached to every layout

Generated schedules pass through heuristic search, exact methods, and an independent validator before entering the versioned catalog.

Cached layouts were comparison targets, never search inputs. Each algorithm had to produce its result from the same generated starting conditions.

Rust was a good fit for this work for many of the same reasons we chose it for the Curling IO v3 backend. Native execution let us evaluate large numbers of candidates, and the type system made it difficult to mix an invalid partial schedule into a supposedly valid result. The same harness could run bounded comparisons or resume long exact searches. This was a small research project we knew we would change constantly, but correctness still matters.

Evaluated Algorithms​

No single algorithm won across every fixture. The final offline process uses several methods with different costs and strengths.

Local Search​

The simplest optimizer tries one legal game swap and keeps it only if the tuple score improves. Our depth-two version tries a second swap even when the first move is awful, then keeps both only if their combined result beats the untouched schedule. Across 20 neutral eight-team starts, depth two beat single-swap search 16 times and reached the known optimum twice.

Depth three improved the odds again, but it did not dominate depth two. Across 1,000 paired starts it won 394, tied 310, and lost 296. Depth four then lost more often than it won against depth three. Bigger neighbourhoods created new paths, but they also spent more of a fixed budget wandering through unhelpful ones.

Targeting helped more consistently. We aimed most source-game choices at the team-sheet assignments blocking the next maximum-repeat reduction. Then we added tabu memory so the search could walk across previously unseen equal-fairness states instead of bouncing between the same arrangements.

Still, the classic 8×4 case exposed the limit of local moves. One exact check proved that a particular matchup grouping could do no better than (1,24,5). The global optimum was (1,24,0). No amount of sheet shuffling inside that grouping could close the gap because the pairings had to be regrouped across draws.

This is a limit of local search. Some improvements require changing which games share a draw, not only changing their sheet assignments.

Simulated Annealing​

We tried simulated annealing twice, first in the old Gleam implementation and again as a deliberately smaller Rust experiment. The larger historical version had temperature schedules, reheating, restarts, adaptive move weights, sheet cycles, draw rotations, targeted moves, and several phases. It retained the best candidate, so returning a hot degraded state did not explain its performance.

Considering the effort we put into understanding and implementing simulated annealing, the results were disappointing. The smaller Rust version made the comparison easier to trust. It remained competitive on 8×4 but lost across the broader fixture suite. Annealing added some portfolio diversity on one shape, but the evidence did not support using it as a general strategy.

We retained the negative result in the research record. Further temperature tuning was lower priority than approaches that improved more fixtures under the same evaluation budget.

Reconstruction and Portfolios​

Greedy reconstruction keeps the draws and competition rules but rebuilds sheet assignments from a new seeded ordering. Five independent reconstructed starts beat five ordinary starts under the same total evaluation budget. It did not solve every fixture, but it entered basins that swap-only search never saw.

Our offline portfolio eventually kept independent reconstruction and population workers, plus a separate lane that exploited the best validated candidate found so far. We tried forcing every worker back to the global best, but that reduced diversity and did not help. Sharing became useful only when it was additional work rather than a replacement for each worker's private search.

This is why we added checkpoints to the offline runner for each worker's private state as well as the global best. A long search can stop and resume with both the global best and the independent state of each worker intact.

Exact Methods and Constructions​

Heuristic search gave us strong candidates, but proving optimality required exact methods.

We added exact methods in layers instead of handing the entire problem to one solver:

1. Fixed-draw sheet assignment keeps matchups and draw membership fixed, then solves only which sheet hosts each game.
2. Logical-round models can repartition games across the draws belonging to one round while preserving round boundaries.
3. Packed factorization search chooses both the matchup grouping and sheet assignment for smaller full-draw schedules.
4. Bounded repair queries ask whether a known target can be reached within a radius of a strong incumbent.
5. Combinatorial constructions directly generate known design families such as partitioned balanced tournament designs.

The fixed-draw constraint solver brought several common layouts to their global lower bounds. A later exact pass promoted 64 of 74 previously unresolved high-sheet layouts to proven optimal, about 86%. Packed branch-and-bound also proved the 10×5 lower bound from generated input without reading the cached schedule, and handled small odd-team schedules using near-perfect matchings.

The exact results also identified limits in the search formulation. A 16×8 round robin is a partitioned balanced tournament design of side eight. A published starter-adder construction produced the global (1,112,0) lower bound directly. Local search had stalled because a strong heuristic schedule needed at least 41 game-sheet placements changed under its existing draw composition.

For 19 teams on 9 sheets, bounded repair could not reach (1,171,17) within 10 changed cells. We removed redundant variables and encoded the lower-bound condition directly: every team uses every sheet exactly twice. Z3 found (1,171,0) on the existing cyclic matchup structure. The solution differed from the starting sheet labels in 151 of 171 game cells, about 88%. The local repair radius had excluded the relevant solutions.

We then ran an exact round-order finishing pass. It treats each complete logical round as one block and finds the best path through those blocks without changing matchups, sheets, or the games grouped into each draw. That improved 28 catalog entries and proved 23 of them optimal. The pass deliberately rejects packed schedules whose draws cross round boundaries rather than guessing which games belong together.

A short constraint sweep produced another 51 proofs. Forty-nine finished in under one second on the development machine. The largest remaining back-to-back gap was 17 teams on 8 sheets, which improved from (1,136,16) to the global (1,136,0) lower bound after about 25 seconds. Both 13-team, 4-sheet packing modes remained unresolved after a one-minute attempt.

Finally, we generalized the full-round enumerator to allow surplus sheets. It exhausted six small search spaces, proved all six optima, and improved the 6-team, 5-sheet catalog entry from (1,3,0) to (1,2,0). These proofs matter because the cheap generic lower bound is not attainable for every shape.

Seventeen layouts were still marked best-found at that point. Graph-degree parity and a single-sheet transition bound proved 12 of them without changing their schedules. Cyclic edge-difference constructions then closed the 9-team and 13-team two-sheet layouts. Complete edge-colouring, draw-pairing, and draw ordering searches closed the 6-team and 7-team two-sheet layouts.

The last case was 9 teams on 8 sheets. Searching complete schedules carried too much symmetry, so we split it into smaller exact problems. A pseudo-Boolean model assigned the 36 games to sheets first. An exact factorization then formed nine legal draws, and a Hamiltonian path search ordered them without back-to-back repeats. The result improved from (1,5,0) to the global lower bound of (1,4,0).

We later expanded the catalog through 24 teams. Published partitioned balanced tournament designs gave exact 22-team, 11-sheet and 24-team, 12-sheet schedules. Splitting the two balanced halves of those designs also proved nine surplus-sheet layouts. Exact draw ordering and the existing odd-team split construction proved another 14 layouts. The remaining new shapes still receive validated cached schedules, but keep Optimize available while we work through them offline.

Coverage and Proof Status​

Catalog revision 23 resolves every team-and-sheet shape in the practical 2-through-24-team and 1-through-16-sheet envelope. Of the 449 stored layouts, 419 are proven optimal and 30 retain validated best-found results.

Of the 419 proven layouts, 392 reach the generic global lower bound. The other 27 need a tighter proof: 16 use a graph-degree parity bound, one uses a single-sheet transition bound, and ten use exhaustive search. The odd five-team, two-sheet layout is one example. Exact enumeration proved that four back-to-back repeats cannot be removed. Small surplus-sheet layouts provide others because games sharing a draw still need different sheets.

Every lookup in the defined envelope has a validated cached result. The 30 best-found layouts remain in the improvement queue. Proven layouts stay in the regression suite, but receive no more offline search budget unless the catalog envelope or the scoring rules change.

Offline Rust and Browser JavaScript​

Precomputing ordinary layouts changes the role of the browser optimizer. It is used for schedules that no longer match the canonical inputs.

A real event may have:

• multiple round-robin pools sharing sheets
• multiple iterations, where combining canonical layouts creates new repeat patterns
• locked games that Allocate and Optimize must not move
• ad hoc filler games for unbalanced round robins
• bracket games that have to follow their predecessors

Those combinations are too event-specific to cache globally. They still need immediate and reversible optimization in the editor.

The in-browser optimizer runs in a cancellable Web Worker with a hard 100 ms deadline today. It always retains the input and the best valid result found, so running longer can fail to improve a schedule but cannot return a worse one.

Its current dispatcher uses three broad policies:

• ordinary: an unlocked schedule that needs general local improvement
• constrained repair: locks or fixed placements make stability important
• bracket-safe: game ordering and fixed draw boundaries matter more than a wider reconstruction

It spends 70% of the deadline on depth-two search, then gives the remainder to the selected repair lane. The bracket-safe path stays with depth two for the whole deadline. Across 700 paired benchmark cases, this three-policy dispatcher beat the older five-route selector 22 times, tied 666, and lost 12.

The paired result supported using the simpler dispatcher. It nearly always returns the same or a better answer, runs off the main thread, and selects a policy from visible schedule features.

The browser and Rust implementations share the schedule vocabulary, validator expectations, fairness tuple, fixtures, and evidence. The offline Rust budget is effectively unconstrained, so it can use populations, exact solvers, parallel workers, and long-running checkpoints. The browser budget is tightly constrained because longer optimization would noticeably affect the editor's responsiveness.

Catalog Distribution and Runtime Selection​

Drawmaster writes a versioned JSON catalog. Each entry contains indexed teams, draws, and sheets plus its fairness tuple, lower bound, producing method, proof status, command, and independent validation evidence.

The catalog is owned by our shared Curling scheduling package and bundled into the Curling IO v3 event schedule builder. The free CurlingSchedules.com editor also consumes the same artifact, but its interface and local-storage persistence remain separate from Curling IO. An 8×4 lookup resolves to the same canonical schedule in both places.

The runtime order is:

1. Look for an exact canonical layout.
2. Apply it immediately when it maps safely to the teams and selected sheets.
3. Repeat or compose catalog layouts for iterations and multiple pools.
4. Repair around locks, extra games, bracket games, and manual placements.
5. Generate directly only when no catalog starting point can be used.

An exact, single-iteration layout marked proven optimal disables Optimize. There is nothing useful for the button to do. The catalog format can still hold a best-found layout if the envelope expands before its optimum is proved. In that case, Optimize remains available. Repeated, composed, or repaired schedules also remain optimizable because the original one-iteration proof no longer covers the combined result.

Club draw schedule templates are separate. A drawmaster can deliberately apply a recurring local arrangement instead of the global default, and v3 warns before that template moves games already placed in the schedule. Templates express a club's preference. The canonical catalog expresses the best general result we can validate for a numerical shape.

Findings​

The research produced the following working conclusions:

• Complete validated coverage took priority over spending more search time on one already well-understood layout
• No heuristic dominated every team-and-sheet shape. The amount of variance between shapes was larger than we expected
• More search depth did not guarantee better results under a fixed budget
• Equal-score plateau movement mattered, but it could not repair a bad matchup factorization
• Reconstruction and independent portfolios found different basins more reliably than one long local walk
• Simulated annealing did not perform well enough to become a general strategy
• Exact solvers became practical after we split the problem into the right layers
• Published combinatorial designs supplied direct solutions for applicable schedule families
• Proof status belongs beside every cached answer
• The best production optimizer is often a cache lookup followed by a small, domain-specific repair

The current catalog covers the v3 target envelope, and every stored layout is proven optimal. The remaining research is event-specific repair around locks, ad hoc games, bracket games, and shared resources, plus any future expansion of the catalog envelope.

Curling IO v3 maps each abstract catalog layout onto real event teams, resources, draws, and games. From there, the drawmaster can apply club templates, import assignments, add ad hoc games, and make manual changes while preserving any placements they choose to lock.

Glossary​

• Fairness tuple: The ordered (Max, Total, Back-to-back) score used to compare schedules. Lower is better, and the numbers are compared from left to right.
• Heuristic: A method designed to find a strong schedule quickly without proving that it is the best possible schedule.
• Local search: Improving a schedule by making nearby changes to its current arrangement.
• Swap depth: The number of moves evaluated together before deciding whether to keep them. A depth-two search can keep two moves whose combined result improves the original schedule.
• Plateau: A group of different schedules with the same score.
• Plateau walking: Moving through equal-scoring schedules in search of a position from which an improvement becomes possible.
• Tabu search: Keeping a short memory of recent moves or schedules so the search does not repeatedly cycle through them.
• Simulated annealing: A search that sometimes accepts a worse move to escape a local optimum, with that willingness usually decreasing over time.
• Basin: A region of the search space whose nearby moves tend to lead to the same local optimum.
• Portfolio: Several search strategies or workers run independently, with the best validated result retained.
• Exact method or solver: A method that can establish whether a target is reachable or prove that no better valid schedule exists.
• Branch-and-bound: An exact method that stops exploring a branch when its mathematical bound proves it cannot beat the best result already found.
• Lower bound: A score that no valid schedule can beat. Reaching an applicable lower bound proves optimality.
• Proven optimal: A validated schedule for which no better fairness tuple can exist.
• Best-found: The strongest validated schedule found so far, without proof that a better one does not exist.
• Checkpoint: Saved search state that lets a long-running process resume without starting over.

Curling clubs use rentals for practice ice, lounges, meeting rooms, and other bookable resources they define. A rental needs a product and price, but it also needs a schedule, one or more resources, public availability, and a booking record after checkout.

In Curling IO v3, an administrator defines the rental schedule and resources in the admin area. Available time slots appear on the public calendar, where curlers can add one to the cart and complete checkout. This post explains the rental options being added and how they fit into the calendar.

What Changes From v2​

Curling IO v2 already lets clubs rent venues. Curling IO v3 vastly improves on this workflow and changes how rentals are configured and managed:

• Rental administration: Create and edit rentals from Products > Rentals, with the schedule, resources, pricing, and booking options together in the admin area.
• Resource management: Resources replace what v2 calls venues. A resource can be a sheet, lounge, meeting room, or anything else the organization defines. A dedicated settings area controls the resources used by rental schedules, reservations, closures, and the calendar.
• Capacity and waitlists: A rental can accept one exclusive booking or several bookings for each time slot. Capacity and waitlists belong to the exact resource, date, and time being booked.
• Grouped resources: Several resources can form one time slot. One booking can reserve two sheets or the complete rink together.

See the Rental Workflow​

This tutorial creates and books an exclusive rental, configures a rental with capacity, and finishes with a grouped rental that reserves two sheets together.

How the Rental Schedule Works​

A rental starts with one or more resources, a date, at least one start time, and a duration. It can happen once or repeat daily, weekly, monthly, or yearly. An administrator can set an end date and exclude individual dates without creating a separate product for every time slot.

For example, a club can offer two-hour practice ice on sheets A and B at 4:00 PM every day for one week. Each sheet and date becomes its own bookable time slot, while the rental keeps one shared price and set of booking rules.

The rental defines the complete offer. A time slot is one resource, date, and start time that a curler can book. If the sheets need different prices or rules, the club creates separate rentals.

How Rentals Appear on the Calendar​

Available rentals appear alongside games and other activity on the public calendar. Curlers can filter the calendar to rentals, and a club can link directly to that filtered view when promoting practice ice or room bookings.

The desktop calendar provides day, week, month, and list views. On a phone it becomes a simpler day list, with date controls and each event shown as a card. When viewing the current date, the phone view leaves out events that have already finished.

Selecting an available rental opens its date, time, duration, price, and resource choice. When several equivalent sheets are offered separately, the curler can choose an available sheet before adding the time slot to the cart.

Adding a time slot to the cart does not reserve it. Availability is checked again at checkout, and the resource is allocated only when checkout completes. Abandoned carts do not affect public availability.

After checkout, the person who made the booking sees Booked. Other curlers see Reserved, without receiving the rental name or order details. Sheet B can remain available at the same time when only sheet A was booked.

Embed Rentals on Your Club Website​

A club does not have to send visitors to a separate calendar before they can find available ice. The rental widget puts a focused seven-day list of bookable times directly on the club's existing website. Visitors can compare dates, times, resources, and prices without leaving the page.

The widget can show every public rental or be limited to selected rental products and resources. A club could use one page for practice ice, another for lounge rentals, or show only the sheets relevant to a particular program. The list stays connected to the same rental schedule and resource conflicts as the full calendar, so the club does not maintain availability in two places.

Selecting Book takes the visitor into the club's normal Curling IO cart and checkout. That is where Curling IO confirms availability again and handles login, participants, questions, waivers, add-ons, discounts, payment, and the final booking. The embedded list is for finding a time, not a stripped-down checkout that skips the club's booking rules.

The layout adapts to the space available on the host page, including narrow website columns and phones. It also carries the club's Curling IO colours and protects its controls from conflicting website styles.

Exclusive Rentals and Rentals With Capacity​

Some rentals are exclusive. One booking takes the complete sheet or room for that time. This is the natural setup for practice ice.

Other rentals can accept several bookings for the same resource and time. A drop-in practice might use sheet C at 7:00 PM with capacity for four bookings. After one checkout, the time slot remains available with capacity for three more.

The club can also limit an account or participant to one purchase per time slot. If the time slot sells out, an optional waitlist collects interest for that exact resource, date, and time.

Approving a waitlist entry gives that account one private capacity exception. This lets the approved account book without increasing the capacity available to everyone else.

Group Several Sheets Into One Rental​

Sometimes the thing being rented is not one sheet. An instructor may want two adjacent sheets, or a rental league may want the full rink for a block of time.

An administrator can group the selected resources so one booking reserves all of them together. The day calendar shows adjacent grouped resources as one block spanning their columns. Selecting the block shows the complete resource set, and checkout creates one booking for the group.

A conflict on any resource makes the complete grouped time slot unavailable. If a scheduled game, closure, reservation, or existing booking uses sheet A, the calendar does not offer a partial version of the rental on sheet B.

Calendar Actions for Administrators​

The calendar is not only a public rental list. Administrators can add manual reservations and closures, edit a rental schedule, and reschedule an existing booking from the event itself.

Those records have different jobs:

• A rental is a public product with a price, schedule, cart, order, and payment.
• A reservation holds a resource manually.
• A closure marks a resource as unavailable.
• A booking is the purchased resource and time saved on an order.

The calendar resolves those records together. Removing a closure or reservation exposes the underlying rental time slot again without requiring the administrator to recreate its schedule.

Other Product Features Available to Rentals​

Rentals use the same basic commercial tools as other Curling IO products. A club can require a participant, add registration questions, offer add-ons, apply discounts, assign taxes and accounting, and use the normal payment and refund workflow.

For example, a room booking can ask for setup requirements, a practice booking can require a participant, and a full-rink rental can include a related add-on.

Rentals will be a Premium feature in Curling IO v3. A rental schedule will be the shared source used to calculate calendar availability, validate checkout, and create the booking saved with the completed order.

Membership associations sometimes need more than a recommended waiver. A group insurance policy may require every member club to present the same approved language to its Participants.

Emailing a Word document to each club distributes the wording, but it does not keep that wording under control. A club can edit its copy, miss the next update, or keep collecting responses against an old version. Later, the association may have no reliable way to tell which document a Participant actually saw.

Curling IO v3 will connect those pieces. A membership association can publish one locked waiver, make it available to its member clubs, update it in one place, and report on which clubs have Participants responding to it.

See the Managed Waiver Workflow​

This tutorial shows the complete workflow: creating managed and customizable waiver templates, publishing a new version, enabling association waivers at a member club, and reviewing version and response records.

From Group Insurance Policy to Participant Response​

Suppose Demo Curling Association’s group insurance policy requires every adult Participant to accept an approved General Liability Waiver. Here is how that would work in Curling IO v3.

1. The association publishes a managed waiver template​

A managed waiver template is an association-controlled waiver that member clubs can use but cannot edit. The association creates it once and controls the waiver name, body, acceptance text, and inclusive age range. Setting a minimum age of 18 means the waiver includes Participants who are 18 and older.

The waiver can contain variables for the member club’s name, province, and membership association. Curling IO fills those values in for each club, so the association does not need to maintain separate copies of otherwise identical documents.

2. Member clubs enable the association waiver​

New member clubs begin with available managed waivers enabled. When an association adds a managed waiver later, existing clubs see it in their Association waivers list as disabled. They can review it and enable it when they are ready to begin collecting responses.

Once enabled, the club cannot change the association-controlled document or age range. It can disable the waiver, but it cannot quietly edit the wording while continuing to present it as the association’s waiver.

3. Participants respond during registration​

When the waiver applies to a Participant, Curling IO presents the current association-controlled document during registration. The account holder accepts it for themselves or, when required, responds as the Participant’s legal guardian.

The saved response records the managed template, its version, and the exact resolved document shown at the time. It also records the Participant’s age, who responded, and the guardian relationship when one applies.

4. The association can see which clubs are using it​

Membership association reporting will show which member clubs have Participant responses tied to each managed waiver. This is more useful than checking whether a waiver is enabled. A club can have a waiver enabled without registering anyone, while a saved response proves that the managed document was presented and answered.

The report provides evidence that clubs are collecting responses against the association-managed waiver. It does not make an automatic legal ruling that a club has satisfied every condition of an insurance policy. Those policies may include requirements Curling IO cannot infer.

Update Every Club Without Replacing History​

When approved wording or age requirements change, the association publishes a new managed template version. The new version immediately becomes the document shown by every member club using that waiver.

People who have not responded will see the latest version. Participants who already responded during the season will not be asked again just because the association published an update.

The earlier version and its responses are not overwritten. Member clubs can review the version history and compare what changed, but they cannot roll a managed waiver back or apply their own version. Each historical response still shows the exact waiver document presented to that Participant.

Use a Customizable Template When Locking Is Not Required​

Central control is not always necessary. An association may have useful base language that clubs can adapt to local programs, facilities, or legal advice. In that case, it can publish a customizable waiver template instead. The practical differences are:

Selecting a customizable template prefills a new waiver form. The club can change the content before saving, and the resulting waiver belongs to the club. This is convenient, but convenience and compliance are not the same thing. If an insurer requires every club to use unchanged wording, the managed template is the option designed to preserve that control.

More Than a Waiver Upload and Checkbox​

A basic waiver field can display text and collect an agreement. It does not give a membership association control over that document across independent clubs, preserve every version, or connect each response back to its managed source.

That connection is the important part of the v3 design. The association can publish the requirement. Clubs can put it into use without copying it. Participants respond to the current document. The resulting records show which version was presented and where it was used.

This is the latest post in our series about product features coming to Curling IO v3. We’ll keep showing the real workflows as they take shape, including what changes for membership associations, member clubs, and the people registering.

Curling IO used to run on Debian configured with Ansible. That setup worked. It installed packages, configured Caddy and the firewall, created systemd services, and prepared our blue-green deployment slots.

The problem was not that Ansible couldn't describe the server. The problem was that a working, mutable server let us get away with an incomplete description. Old files remained under /etc. Build tools had been installed through a different path. Provider choices about disks and RAID lived outside the playbook. A provisioning run could succeed because an earlier run had already left the right thing behind.

NixOS is much less tolerant of these gaps. This strictness is occasionally annoying, but it is also the main benefit. It forces us to decide who owns a file, a service, a secret, a package, or a recovery input.

Moving from Ansible to NixOS taught us how much validation and cleanup the old approach had been missing. It exposed the difference between a server that continues to work and one we can recreate from declared inputs.

This is what we found useful while rebuilding an OVH bare-metal server from empty disks, restoring its state, and making the process safe enough to repeat.

The Boundary We Wanted​

We wanted to answer a simple question: if the server disappeared, could we rebuild Curling IO in a timely manner, without depending on undocumented state from the old host, and with basically no customer data loss?

A successful recovery had to:

• Recreate the mirrored disk and EFI boot layout.
• Activate the exact host configuration.
• Restore the host's ability to decrypt its secrets.
• Restore valid Caddy certificate state.
• Build and deploy the platform, public site, and Operations application from one frozen Git revision.
• Restore and validate SQLite from Litestream.
• Verify public and private upload storage.
• Create and verify an encrypted database snapshot in a second region.
• Pass local, public, storage, monitoring, and provider checks.

This is broader than operating-system provisioning. NixOS owns the host, but application releases and customer state have their own workflows.

That separation has held up well. We can change the host without deploying an application. We can deploy the platform without deploying the public site. We can restore a database without reinstalling the server.

Application Releases Stay Separate​

NixOS owns the host, not the application build. We build the platform, public site, and Operations application before deployment, package them as verified releases, and upload them over SSH. Production does not need source code, repository credentials, compiler toolchains, or build caches.

That leaves a smaller production software footprint: fewer packages and executable tools, no source checkout or build credentials, and less mutable build state. It reduces the attack surface and patching burden, though it does not replace service sandboxing or timely updates.

This keeps host changes and application releases independent. It also gives recovery a simple boundary: build from one frozen Git revision, verify each package before and after upload, then activate it using the same deployment workflow we use during normal operation.

Nix Has Two Different Host Deployment Paths​

Routine provisioning and replacement-host recovery deliberately work differently.

For a normal configuration change, our bin/provision production script sends the exact committed infrastructure source to the running server. The server uses Nix to build a new immutable system generation, validates it, switches to it, and keeps the previous generation available for rollback.

Clean-host recovery cannot rely on that path. A supposedly complete recovery image should not boot and then download or build most of the real system. Our BYOLinux image therefore contains:

• A minimal, secret-free bootstrap system that can boot and accept SSH.
• The complete production NixOS closure as inactive store content.

After first boot, the recovery command activates the already embedded production system and its required secrets. If the image does not contain the required closure, recovery stops. It does not hide the incomplete image by falling back to a remote build.

This makes the recovery image a real artifact rather than a thin installer. Application-only commits can still reuse it because the image derivation depends only on infrastructure source. Application code, documentation, and task files do not force another multi-gigabyte image build.

Bare Metal Keeps the Provider in the Design​

NixOS does not remove OVH from the recovery path.

Our first installer created valid software RAID metadata with a newer Linux kernel. The installed NixOS kernel and OVH's rescue kernel both refused to assemble it. Upgrading only NixOS would have made the installed system work, but it would still have left the provider's rescue environment unable to read the disks.

We changed the ownership boundary. OVH BYOLinux now creates the mirrored ext4 filesystems using the provider's supported layout. Our image supplies the NixOS filesystem and a boot hook that labels the filesystems and installs removable-path EFI GRUB on both drives.

The provider's BYOLinux hook runs inside a restricted chroot. During our first attempts, the chroot did not have the shell or PATH we expected. A working image build told us nothing about whether OVH could execute the hook. We had to:

• Use an absolute Nix store path for Bash.
• Inline the hook instead of calling a second store path that was absent from the image.
• Use shell builtins until the embedded system PATH was available.
• Test every referenced store path against the image itself.
• Replay the hook inside a provider-like chroot.

This was disappointing. QCOW2 gives us a standard image format, but not a standard contract for turning that image into a bootable bare-metal installation. We expected the provider boundary to be more predictable. Instead, OVH ran a provider-specific hook inside a sparse chroot whose shell, PATH, and available store paths had to be discovered through testing. The image format was portable; the installation contract was not.

Provider monitoring also mattered. During an early rehearsal, OVH detected the planned outage and opened a technician intervention. That intervention blocked an API request to change the server's boot mode. Recovery preflight now disables and verifies automatic intervention before allowing a reinstall, then restores the selected policy after the recovered host passes its checks.

Getting this provider boundary right consumed the lion's share of the engineering time we spent on recovery provisioning. The successful reinstall itself took under eight minutes, but reaching that point required repeated image builds, failed hooks, rescue boots, and destructive rehearsals.

Generated Configuration Needs One Owner​

Caddy exposed the problem with mutable configuration quickly.

The old server had generated fragments copied into mutable directories. When we changed the layout, stale files remained and were still loaded. The new configuration was correct in the repository but wrong on the server because the server contained both old and new interpretations.

The NixOS configuration now owns generated Caddy files as links to exact Nix store paths. Obsolete paths are removed explicitly, and the assembled configuration is validated before activation.

This lesson is not specific to NixOS. An Ansible deployment can enforce the same rule, but it has to do so deliberately. Copying the latest desired file is not enough when an old file can still affect runtime behaviour.

Recovery State Must Exist Before the Wipe​

The failed server is not a recovery source.

Before erasing it, preflight verifies:

• The selected infrastructure revision and recovery image.
• The required secret-recovery inputs.
• Current RAID health.
• A decryptable Caddy-state backup with valid certificates.
• The offsite Litestream replica and encrypted snapshot in a second offsite location.
• Public and private upload storage boundaries.
• Public endpoints and OVH state.

Caddy state became an explicit input after we realized that certificate issuance should not sit on the critical recovery path. NixOS checks for changed Caddy state every five minutes and stores encrypted copies offsite. Weekly retention slots provide a backstop.

During recovery, Caddy stays stopped while the platform, site, database, uploads, and encrypted snapshot are prepared. It starts only when the server can present a complete system using the restored certificate state. Normal background renewal resumes afterward.

SQLite follows a separate path. Litestream continuously replicates offsite. A daily job restores and validates that replica before creating a client-side encrypted full snapshot in a second offsite location. The restore process prevents an older disaster snapshot from replicating back to the primary replica while it is being tested.

Recovery Runs from a Frozen Revision​

A long recovery cannot safely follow a moving branch.

The complete recovery command creates a temporary checkout at the selected commit. Image publication, provider installation, host activation, all three application builds, state restoration, and final acceptance run from that frozen tree. New commits in the normal checkout cannot alter a recovery already in progress.

The workflow also has durable resume points:

1. Verify the image and recovery inputs.
2. Ask OVH to install the image.
3. Activate the embedded NixOS closure.
4. Build verified application packages locally.
5. Deploy the platform and public site.
6. Restore and validate SQLite, then verify upload storage.
7. Start Caddy.
8. Deploy Operations.
9. Run final acceptance checks.

If application deployment fails after the host boots, we resume at application deployment. We do not erase the disks again. Public DNS cutover is another separate, confirmed operation after direct checks against the replacement host.

Updates Use the Same Health Check​

NixOS checks for stable updates each night and keeps the previous generation available for rollback. A new generation is accepted only after it passes the same read-only health checks used by Operations monitoring.

Provisioning, automatic updates, recovery, and monitoring therefore share one definition of a healthy server. If those checks fail, the host returns to the previous generation.

Lessons Beyond NixOS​

You can get pretty far by applying the same strictness to Debian and Ansible:

• provision from an exact revision;
• define explicit ownership and cleanup;
• pin the tools used during recovery;
• guard destructive commands;
• test the complete replacement-host workflow automatically.

None of this requires NixOS. The difference is that Ansible lets you skip these steps and keep going. NixOS makes disagreements with the declared system much harder to ignore. And we like having these technical guardrails at Curling IO.

Decision​

We are keeping NixOS.

It does not build our applications, restore customer data, eliminate the provider, or replace deployment scripts. It gives those systems a host with a clearer definition and a safer activation boundary.

The most valuable part is not reproducibility as an abstract property. It is the pressure to make hidden assumptions explicit:

• Which system owns this file?
• Which key can recover this secret?
• Which artifact identifies this host?
• What survives loss of the server?
• What proves a new generation is healthy?
• Where can recovery resume after a failure?

These questions have improved the whole deployment system, including the parts that do not use Nix.

This is Part 9 of the Curling IO Foundation series. Previous: A Live Admin Panel Without Writing JavaScript.

Curling clubs sell much more than leagues and bonspiels. They run clinics, rent ice, assign lockers, host junior camps, sell banquet tables, and collect donations.

Today, each of those offerings has to fit one of Curling IO's predefined types. That works, but sometimes only because a club picks the closest available bucket. One active junior summer camp is stored as a Product, with its August dates written into the name. A full-sheet ice rental is stored as a Program because it needs a date, capacity, and a waitlist. A donation is stored as a Fee.

In Curling IO v3, the organization decides which product types it needs. A club can create Camps, Clinics, Ice Rentals, Locker Rentals, Fundraising, or any other category that fits its operation, then choose what each type can do.

Start with what your club calls it​

Suppose the club tells us:

We run learn-to-curl clinics and junior camps. We also rent practice ice, sell lockers, and hold a fundraising dinner. Those shouldn't all be mixed into Programs or Products.

In v3, they don't have to be. The club can create a product type for each part of the operation, put them in the order staff expects, and turn off types it doesn't use.

New organizations still get familiar starting types such as Leagues, Bonspiels, Programs, Products, and Fees. They aren't a permanent menu chosen by Curling IO. An administrator can rename them, reorder them, disable them, or create another type.

These categories already exist in the real world​

We looked at active offerings in Curling IO rather than inventing examples for this post. Here are a few of the things clubs and associations are selling now:

The current choices aren't mistakes. They show the limitation of a fixed set of types. Clubs are already using Curling IO for this work, but the product structure doesn't always speak their language.

A type controls more than its label​

A product type decides which tools are available for products of that type.

If a club creates a Clinics type, it might enable purchasing, participant registration, dates, capacity, waitlists, and product managers. Each clinic can then have a price, registration form, opening and closing dates, participant limit, and assigned staff.

An Ice Rentals type might need purchasing, dates, and inventory, but no participant registration. A Donations type might need purchasing and accounting without dates, teams, or a waitlist.

The result also carries through the rest of Curling IO. Enabled product types appear in the Products section in the order the organization chooses. Each type can have its own bilingual name and summary, accounting code, and public listing address.

Familiar defaults, without the fixed boxes​

Most clubs can keep using Leagues, Bonspiels, Programs, Products, and Fees. Nothing requires an administrator to design a taxonomy before opening registration.

But the club running camps can create Camps. The association running coaching courses can create Courses. The facility selling practice ice can create Ice Rentals. Their admin navigation, public listings, and product setup can match the operation people already understand.

Custom product types are coming in Curling IO v3.

The security problem is real​

WordPress powers roughly 43% of all websites on the internet. That kind of market share makes it a huge target for malicious actors. Sucuri's 2023 hacked website report found WordPress accounted for over 95% of hacked CMS platforms they remediated. Joomla and Drupal made up most of the rest.

Patchstack's 2024 State of WordPress Security report found 5,948 new WordPress vulnerabilities disclosed in a single year. The vast majority, over 97%, were in plugins and themes rather than WordPress core. The exact number changes every year, but the pattern is stable: plugins and themes are where most of the risk lives.

Supply chain attacks​

It's not just about unpatched bugs. In June 2024, WordPress.org disclosed that several plugins in the official repository had been compromised. Attackers gained access to developer accounts and pushed malicious updates to trusted plugins with tens of thousands of active installs. The malicious code created unauthorized admin accounts and exfiltrated data.

Even more concerning is a growing pattern where malicious actors purchase legitimate, established plugins from their original developers and then inject malicious code in subsequent updates. Users who have auto-updates enabled, as is generally recommended, receive the compromised version automatically without any indication that the plugin has changed hands.

The Balada Injector campaign, documented by Sucuri, has been exploiting known plugin vulnerabilities since 2017. By their estimates, it has compromised over one million WordPress sites, injecting malicious JavaScript that redirects visitors to scam sites.

In August 2024, a critical vulnerability in the LiteSpeed Cache plugin (used by over 5 million sites) allowed attackers to create admin accounts on any site running the vulnerable version. It was actively exploited in the wild.

Joomla and Drupal aren't immune​

Joomla has had its share of critical vulnerabilities. In February 2024, a high severity XSS vulnerability in Joomla's core filter component (CVE-2024-21726) could lead to remote code execution. Proof-of-concept exploit code was published shortly after disclosure. An earlier vulnerability (CVE-2023-23752) that leaked database credentials was still being mass-exploited well into 2024 because so many sites remained unpatched.

Drupal has a better security track record thanks to a more curated extension ecosystem and dedicated security team, but its complexity means fewer organizations keep it fully patched. The infamous Drupalgeddon vulnerabilities from 2014 and 2018 continued to be used against unpatched sites years later.

Automation is making it worse​

Automated bot traffic already accounts for roughly half of all internet traffic, with malicious bots making up about a third. AI tools add another layer: attackers can use them to research vulnerabilities, generate exploit code, and move faster once a flaw is public.

A University of Illinois study demonstrated that an AI agent could successfully exploit 87% of known vulnerabilities when given their CVE descriptions. Microsoft and OpenAI confirmed that state-affiliated threat actors are already using LLMs for reconnaissance and scripting attacks. The window between a vulnerability being disclosed and being actively exploited has compressed from days to hours, partly because AI tools help attackers weaponize published CVE information almost instantly.

For a CMS ecosystem like WordPress, with thousands of plugin vulnerabilities disclosed in recent years, this means every unpatched plugin becomes a race.

Why this matters for curling clubs​

Most curling clubs have a small group of volunteers managing their online presence. They don't have a dedicated IT team. They don't have a security budget. When a WordPress plugin introduces a vulnerability, they may not even know about it until their site is defaced, redirecting members to phishing pages, or quietly harvesting payment information.

The maintenance burden is significant even without a security incident:

• Constant updates. WordPress core, themes, and plugins all need regular updates. Falling behind is how sites get hacked.
• Plugin sprawl. Need a contact form? Plugin. Need event registration? Plugin. Need a photo gallery? Plugin. Each one is a potential attack vector.
• Hosting management. You're responsible for the full stack: operating system, web server, PHP version, database, CMS core, and every plugin.
• Backups and recovery. If something goes wrong, you need a recent backup and someone who knows how to restore it.

A general-purpose CMS is designed to build any kind of website. That flexibility comes with complexity that most clubs don't need for what is often a fairly simple informational site.

If you insist on using a CMS​

Some clubs may have reasons to stick with WordPress or another CMS. If that's the case, treat security as a non-negotiable priority.

If someone else manages your site for you, whether that's a volunteer, a local web developer, or an agency, you should be asking them about each of the following points. If their response is dismissive or vague, that's a red flag. Your club's reputation and your members' data are on the line.

Keep everything updated​

Enable automatic core updates and update plugins within 24-48 hours of security releases. Subscribe to security advisories from Wordfence or Patchstack (for WordPress), the Joomla Security Strike Team, or the Drupal Security Team. An unpatched site is a compromised site waiting to happen.

Minimize your attack surface​

Use the fewest plugins possible. Every plugin you install is code you're trusting with your site and your members' data. Before installing anything, check when it was last updated, how many installs it has, and whether it has known vulnerabilities. Remove (don't just deactivate) anything you're not using.

Use a web application firewall​

Deploy a cloud-based WAF like Cloudflare in front of your site. A WAF can block known exploit patterns even before you've applied an update, providing protection against zero-day attacks.

Harden authentication​

Enforce strong passwords and enable two-factor authentication for all admin accounts. Limit login attempts to prevent brute force attacks. Change the default admin username. These are basic steps that block a surprising number of attacks.

Use managed hosting​

If possible, use a managed hosting provider that specializes in your CMS (WP Engine or Kinsta for WordPress, Pantheon for Drupal). These providers handle server-level security, automatic backups, and often include malware scanning. It costs more than bargain shared hosting, but the security and peace of mind are worth it for a volunteer-run organization.

Monitor your site​

Set up alerts for unauthorized file changes and unexpected admin account creation. Run regular security scans. Have a plan for what to do if your site is compromised, including who to contact and where your backups are stored.

Consider a simpler alternative​

If your curling club website is primarily informational, showing hours, ice schedules, contact info, and news, you may not need a CMS at all. There are two good options:

A static site​

Tools like Hugo, Eleventy, or even plain HTML hosted on Netlify or GitHub Pages have virtually no attack surface. There's no database to breach and no server-side code to exploit. The performance is also fantastic since there's no server-side processing or database queries slowing things down.

AI agents like Claude, ChatGPT, and Gemini have made this easier for non-developers. If you're already paying for one of these tools, you can ask it to create a static site for your curling club. It can walk you through the process, show you mockups, help you pick a hosting provider, and help with deployment. It can also handle the integration of our Curling IO widgets and APIs.

Make sure you also ask the agent to document what it's built, how it's hosted, and how deployments are done, so the next volunteer can pick up where you left off. Ask it to commit the source code to somewhere like GitHub as well. This might sound like a lot, but the agents will step you through all of it. Claude Code is especially useful for this if you don't mind paying $20 / month (and it's great for other things too).

If you need something bespoke for your club's website that Curling IO doesn't offer, we highly recommend this approach.

Curling IO's built-in website hosting​

Every club on Curling IO can enable a hosted website at no extra cost. It's minimalist by design, so it's best suited for clubs that don't need a bunch of bells and whistles.

It includes a customizable landing page, pages, news articles, sponsor sections, and member-only content, all tightly integrated with your registrations, leagues, and bonspiels. There's no plugin ecosystem to exploit, no PHP stack to maintain, and no CMS updates to fall behind on. You can even redirect your existing domain to it.

Either approach eliminates the entire class of vulnerabilities described in this post. Your volunteers' time is better spent running the club than patching software.

Set up early bird pricing for the Tuesday Night League. 15% off if they register before September 1st.

Five seconds later, it's done. No browser tabs, no forms, no clicking through menus. With Curling IO v3, this is something you'll be able to do.

The Agent in Action​

The following conversation occurs after you've already logged in to Curling IO and authorized the curling CLI (more on that below):

You: Help me get the new season ready. Set up early bird pricing for the Tuesday Night League, 15% off if they register before September 1st.

$ curling call admin.items.list --org vancouver
$ curling commands admin.discounts.create

$ curling call admin.discounts.create --org vancouver '{"params": {...}}'

You: Same deal for Monday Mixed. Skip Friday, that one fills up on its own.

$ curling call admin.discounts.create --org vancouver '{"params": {...}}'

You: Yes, do that.

$ curling call admin.waitlists.list --org vancouver '{"item_id": 31}'
$ curling call admin.emails.send --org vancouver '{"params": {...}}'

You: What does our registration look like so far this season?

$ curling call admin.items.list --org vancouver '{"season": "2026-27"}'

You: Yeah, check in with me weekly on that.

Season setup, targeted outreach, and reporting in a five-minute conversation.

The same pattern works for setting up a full season's events, bulk-adjusting fees across leagues, generating financial reports, or processing waitlists. Anything an admin can do through the web interface, an agent can do through the CLI.

This isn't theoretical. We're building this right now.

How It Works​

Behind the scenes, the agent is calling a command-line tool called curling. Any AI agent with shell access can call it: OpenClaw, NemoClaw, Claude Code, Codex.

We considered MCP (Model Context Protocol), a standard for connecting AI models to external tools. We built a working prototype. But a CLI is simpler, more portable, and works with every agent framework, not just MCP-compatible ones. MCP can come later as a thin layer on top.

The CLI connects to the same backend as the Curling IO admin web interface. Every admin operation available in the browser is also available through the CLI. When we add a new feature to the admin, it becomes available to agents automatically with no client update.

Authentication​

Before an agent can manage your club, you grant it access. One time, takes about 30 seconds.

curling login

The CLI prints a URL. You open it, log into Curling IO, and approve access. That's it. The CLI stores a token and handles refreshes silently from that point on.

This uses the OAuth 2.1 device flow (RFC 8628), the same standard behind the GitHub CLI, Google Cloud CLI, and AWS SSO. It's well understood by security teams and works in any environment.

After login, the agent discovers which clubs you manage:

curling orgs

And scopes its commands accordingly:

curling call admin.events.list --org vancouver

Who It's For​

The real target is an AI agent acting on behalf of a club manager. The CLI's natural users are administrators who are early adopters of AI tools, the ones already using agents to help manage their inbox, draft communications, and automate repetitive work. For them, giving an agent access to curling is the next logical step.

We build it as if a human expert might use it directly. No wizard prompts, no hand-holding. Terse, precise output. Comprehensive --help that rewards reading. Agents are evolving toward human-like behaviour, so building a proper CLI serves both audiences.

The Bigger Picture​

Club management software has always been built for humans navigating web interfaces. That's the right design for most users most of the time. But administrators have repetitive, structured work: setting up a new season, bulk-updating pricing, generating reports, approving registration queues. Work that an agent can handle.

Most clubs aren't thinking about this yet, but we believe they will be within the next few years as AI tools and agents become more prominent. In the near term it'll probably be just a handful of technically oriented club managers who give it a try, and will probably never go back.

Registration forms in Curling IO have always collected the basics: team name, lineup, skill level, contact info. But every club runs things a little differently. Some need emergency contacts. Others want dietary restrictions for banquet planning. A bonspiel might ask for team contact information while a league doesn't.

In v2, admins can already choose which questions appear and create custom ones. What's new in v3 is control over the layout: where each question sits, how wide it is, and how the form is organized into sections.

How it works​

The form builder is a drag-and-drop tool inside the product admin. You start with a panel of available questions on the left and an empty canvas on the right. Drag a question onto the canvas and it becomes part of the registration form. Drag it back to remove it. Reorder by dragging within the canvas.

Questions have a defined column width (1, 2, or 3 columns) that controls how they sit in the grid. A one-column question like "Shoe Size" takes up a third of the row. A two-column question like "Street Address" spans two thirds. A three-column question like "Notes" takes the full width. The layout uses a masonry grid, so questions pack together without leaving gaps.

Separators let you break the form into visual sections. Questions above a separator stay above it. Below it, a new section starts fresh.

Each question can be toggled between required and optional. Required questions show an asterisk on the public form and are enforced on submission.

What curlers see​

The public registration form renders the layout the admin designed. Questions float their labels above the input when you start typing, keeping the form compact. Hints appear as info icons that expand on hover.

The form is responsive. On a phone, everything stacks into a single column. On a tablet, two columns. On a desktop, the full three-column layout shows.

Available questions​

The form builder ships with a catalog of predefined questions covering contact info, emergency contacts, medical details, sport-specific questions, apparel sizes, dietary restrictions, and more. Clubs can also create their own custom questions to collect whatever else they need. The list is searchable, and any combination of predefined and custom questions can be used on any product.

Some questions are tied to event settings. If an admin configures a team name label in the event settings, the team name question appears on the form builder canvas automatically and is locked in place. Same for the lineup question when a lineup option is selected. Turn those settings off and the locked questions disappear from the builder.

Gaps and separators are layout tools, not data questions. Add a gap to leave an empty cell in the grid. Add a separator to visually divide the form into sections.

The form builder is part of Curling IO v3. We'll share more v3 features as we get closer to launch.

Curling IO's admin panel should feel instant when a club manager is working through a season setup. Toggle a setting, save a discount, move between product sections: the page should respond without a full reload.

Version 2 works, but every form submission reloads the page. Version 3's admin is a single Lustre server component running on the BEAM. One WebSocket connection, one long-lived Erlang process per session. Every interaction goes over that WebSocket and comes back as a DOM patch. The page never reloads, and there's no client-side JavaScript framework.

What's a Server Component?​

Phoenix LiveView popularized this idea: render HTML on the server, send patches to the client over a WebSocket, handle events the same way. The browser becomes a thin rendering layer. Lustre, Gleam's UI framework, has the same concept built in as "server components."

A Lustre server component is an Elm-architecture application (Model → Update → View) that runs as a BEAM process. When the model changes, Lustre diffs the old and new virtual DOM and sends a JSON patch over the WebSocket. The client applies it. Events from the browser (clicks, form submissions, input changes) travel back as JSON. The whole loop takes single-digit milliseconds on a local network.

The client side is a custom element called <lustre-server-component>. You point it at a WebSocket route and it handles everything: creating a shadow DOM, adopting your stylesheets, applying patches, and forwarding events. Lustre ships the client runtime as a single JavaScript file you include in the page.

The Architecture​

<html>
  <head>
    <link rel="stylesheet" href="/static/css/app.css">
  </head>
  <body>
    <lustre-server-component route="/ws/admin?url=/en/admin/products">
    </lustre-server-component>
    <script src="/static/lustre-server-component.mjs"></script>
    <script src="/static/js/admin-live.js" defer></script>
  </body>
</html>

fn(_connection) {
  let assert Ok(runtime) =
    lustre.start_server_component(admin.app(), flags)

  let self = process.new_subject()
  let selector =
    process.new_selector()
    |> process.select(for: self)

  server_component.register_subject(self)
  |> lustre.send(to: runtime)

  #(SocketState(runtime:, self:), Some(selector))
}

Navigation Without Page Loads​

Server-rendered pages usually reload on every navigation. That kills the experience for an admin panel where you're moving between product sections constantly. We needed client-side navigation semantics (pushState, back button support) without a client-side router.

The solution is about 90 lines of vanilla JavaScript in admin-live.js that bridges the browser's history API with the server component. It handles three flows:

Link clicks. A click listener on the server component intercepts <a> tags, prevents the page load, calls history.pushState, and tells the server about the new URL. Modifier keys (cmd+click), external links, and target="_blank" pass through to the browser normally. The listener uses composedPath() to pierce the shadow DOM boundary and find the actual <a> element.

Back/forward buttons. A popstate listener detects when the user navigates with browser buttons and sends the new URL to the server without pushing to the history stack (since the browser already updated it).

Server-initiated navigation. When a save operation redirects to a different page (like navigating from the edit form to the overview after saving), the server emits a custom event with the new URL. The client intercepts it and calls pushState.

All three flows use the same trick to communicate with the server component: hidden <input> elements inside the shadow DOM. JavaScript sets the input's value to the new URL and dispatches a change event. Lustre's event handler on the server side picks it up. Regular DOM events don't cross the shadow DOM boundary reliably, but events on form elements bubble through the component's internal wiring. We tried custom events first and spent a while debugging before landing on this.

Shadow DOM and Stylesheets​

Lustre renders inside a shadow DOM. This gives you proper encapsulation. Styles don't leak in or out. The admin's CSS won't affect the rest of the page, and vice versa. But it means your stylesheets need to get inside the shadow root somehow.

Lustre handles this automatically through adoptedStyleSheets, a browser API that lets shadow roots share stylesheets with the parent document. When the component mounts, it iterates over every stylesheet in the document, and pushes each one into the shadow root's adoptedStyleSheets array. If a stylesheet can't be directly adopted (cross-origin restrictions), it copies the CSS rules into a new stylesheet. If that fails too, it clones the <link> or <style> element into the shadow root. Three strategies, in order of preference.

This worked out of the box for Tailwind and our Basecoat component library. One place it tripped us up: CSS custom properties. We had alert color variants that referenced --success, --warning, and --info CSS variables, but those variables were never defined. The styles adopted fine, but color: var(--success) resolved to nothing because the variable didn't exist. The fix was just adding the variable definitions to :root. CSS custom properties inherit through shadow boundaries (unlike regular CSS rules), so once defined on :root they're available everywhere.

What Runs on the Server, What Runs on the Client​

The split is straightforward. The server handles everything that doesn't need sub-frame visual feedback:

• Navigation and routing
• Form input and validation
• Feature toggle switches
• Data loading (synchronous, from SQLite)
• Flash alerts
• Sidebar expand/collapse

The client handles the navigation glue (90 lines of JS) and stylesheet adoption (built into Lustre). That's it. The entire admin UI, including the sidebar, breadcrumbs, form fields, tables, and alert components, is written in Gleam.

Things we explicitly don't do in the server component: timers, drag-and-drop, animations, resize observers. Those require client-side feedback loops that would overwhelm the WebSocket. When we build the bracket builder and team drag-and-drop, those will be Lustre "islands": small client-side Gleam applications compiled to JavaScript, embedded within specific pages. The server component renders the page; the island handles the interactive widget.

What We Got Wrong Along the Way​

Back button infinite loop. Our first navigation implementation used a single NavigateTo message for everything. Server tells client to push URL, client pushes URL. User hits back, browser fires popstate, client sends the old URL to server, server processes it and emits another pushState. Loop. The fix was separating NavigateTo (which pushes to history) from UrlChanged (which doesn't).

Sidebar flicker. When navigating between product pages, we were clearing the product context during the loading state. The sidebar would collapse to its default and then re-expand when the page loaded. We fixed this by persisting the product context on the admin model across navigations within the same product.

Flash messages disappearing. Save operations on discounts and affiliate fees navigate to the list page and show a flash. But we also added "clear flash on navigation." The save set the flash, then called NavigateTo, which cleared it. The fix was to set the flash after the navigation resolved.

What We Got for Free​

BEAM's hot code loading applies to server components. When the dev watcher recompiles a module, the running process picks up the new code on the next message. The WebSocket stays connected, the session state is preserved, and the next click or navigation renders the updated view. We didn't build this. We didn't configure it. We noticed it working one day during development and realized the BEAM had been doing it the whole time.

Why Not SSR or a SPA?​

Over SSR​

The Version 2 admin is server-rendered with full page reloads. It works. But every interaction has visible latency. Toggle a switch, wait for the page to reload to see the result. Navigate between product sections, lose your scroll position.

With the server component, toggling a switch updates the UI immediately (the BEAM process is right there, no network hop to a database and back). Form saves can navigate to a different page with a flash message, and the transition is instant. The sidebar persists across pages because it's part of the same running application.

Over a SPA​

From the user's perspective, the server component feels identical to a single-page application. Navigation doesn't reload the page, state persists, and updates are instant. The difference is where the work happens.

A SPA downloads a JavaScript bundle before the user sees anything. A modest React admin with a component library, router, and state management easily runs 200-500KB of JavaScript. Our admin sends ~15KB of initial HTML over the WebSocket and zero application JavaScript (the Lustre client runtime is a generic 10KB script, not application code).

A SPA also needs a REST or GraphQL API to talk to the server. That means designing endpoints, serializing data to JSON, deserializing it on the client, handling loading states, caching, and keeping client and server types in sync. With the server component, the update function has direct access to the full domain and business logic. There's no API ceremony in between. When a user saves a form, the update function writes to the database and returns the new model. The view diffs automatically. The whole admin is one Gleam codebase with state in one place.

Developer experience​

Every admin page is a Gleam module with Model, Msg, init, update, and view. The types enforce that pages handle all their messages. Adding a new page means adding a route variant (the compiler tells you everywhere that needs to handle it), a page module, and wiring it into the admin's update function. You don't need a template language or context objects passed through middleware. It's functions all the way down.

The Numbers​

For context on what we're working with:

• The admin shell HTML is 6 lines of content (meta tags, one stylesheet, the custom element, two scripts)
• admin-live.js is 89 lines of vanilla JavaScript
• The initial mount sends the full virtual DOM (~15-30KB depending on the page)
• Subsequent patches are typically under 1KB (just the diff)
• Each admin session is a single BEAM process consuming a few hundred KB of memory
• SQLite queries run in-process, so data loading for page transitions is synchronous and measured in microseconds

There's also a payload advantage over traditional SSR. Every HTTP request carries headers: cookies, content-type, CSRF tokens, accept headers, cache directives. That's typically 1-2KB of overhead on every round trip, in both directions. A WebSocket frame is just the payload, a few bytes of framing around the actual data. An admin session might make hundreds of interactions (toggling switches, navigating between sections, saving forms). Over HTTP, each one pays the header tax. Over the WebSocket, the connection is already established and authenticated. A toggle switch that changes one boolean sends maybe 80 bytes of JSON and gets back a 200-byte patch. The equivalent HTTP POST would be 2-3KB counting headers, redirect, and full page re-render.

What's Next​

The server component covers the 95% of admin pages that are forms, tables, and configuration. The remaining 5% (our bracket builder, drag-and-drop team management, live scoreboards) will be client-side Lustre islands that communicate back to the server through the same WebSocket or separate API calls.

This is Part 8 of the Curling IO Foundation series. Previous: Parallel Tests for Free.

AI coding agents like Claude Code, OpenAI Codex, and Google Gemini can write code, run it, read the errors, and try again. That loop is the whole game. The faster and more informative that loop is, the more useful the agent becomes. After building Curling IO Version 3 in Gleam alongside AI coding agents, I'm convinced Gleam is the best language for this workflow. Agents don't write better Gleam - there's less training data. But Gleam's compiler lets agents self-correct without waiting for a human.

The Feedback Loop That Matters​

Every AI coding agent works the same way: write code, check if it works, fix what's broken, repeat. The quality of that "check if it works" step determines everything.

In a dynamically typed language, "check if it works" means running the test suite. Tests take time, they might not cover the thing that's actually broken, and they're code too - every test you add increases the complexity of your project. And many bugs don't surface until runtime, sometimes much later, in production. The agent writes code that looks correct, you review it, it looks correct to you too, and then a user hits a nil error at 2am.

In Gleam, "check if it works" means compiling. That takes a few seconds. When compilation fails, the error messages are specific: here's the file, here's the line, here's what you wrote, here's what was expected. The agent reads that, fixes it, and compiles again. A few rounds of this and the code is structurally sound.

What the Compiler Catches​

No Nulls​

Gleam has no null. Optional values are represented as Option(T), which is either Some(value) or None. You can't accidentally dereference a nil. The compiler forces you to handle both cases. Null-related errors are the most common exception in production, appearing in 70% of production environments in a study of over 1 billion events.

When an agent writes code in JavaScript, it has to remember to check for null everywhere. It doesn't always remember. Gleam removes the possibility entirely.

Null references are famously the billion dollar mistake, and they're not just a theoretical concern. In June 2025, a single null value in a database field cascaded through Google Cloud's Service Control system and took down multiple GCP and Workspace products worldwide for hours. The null hit a code path with no error handling, replicated globally in seconds, and the resulting outage took nearly three hours to fully resolve. Gleam's Option type would have forced the developer or the agent to handle the missing case before the code compiled. It doesn't prevent every failure in a chain like that, but it removes the specific class of bug that triggered it.

There's a security angle too. Unhandled nulls can leave an application in unexpected states - authentication checks skipped because a nil slipped through, or data exposed through an error page that should never have been reached. Every error class the compiler eliminates is attack surface the agent can't accidentally introduce.

Structural Changes​

Here's a real example from our codebase. Say the agent adds a new field to a type:

pub type Listing {
  Listing(
    id: Int,
    name: String,
    capacity: Int,
    waitlist_enabled: Bool,  // new field
  )
}

In JavaScript, adding a property to an object changes nothing until runtime. If some template or API endpoint doesn't include the new field, you won't know until that code path executes. Your test suite might catch it. Or it might not, if coverage is incomplete.

In Gleam, every function that constructs or destructures a Listing now fails to compile. The compiler lists every location that needs updating. The agent works through the list, updates each one, and compiles clean.

This extends to every structural change: renaming a field, changing a type from String to Int, adding a variant to a union type. Agents handle this well. Humans forget things in lists.

Exhaustive Pattern Matching​

Gleam's compiler requires that pattern matches cover every possible case. If you match on a Result type, you handle both Ok and Error. If you match on a custom union type with four variants, you handle all four. Miss one and the compiler tells you.

Say you have a payment status type:

pub type PaymentStatus {
  Pending
  Completed
  Refunded
  Failed
}

If someone adds a Disputed variant, every case expression matching on PaymentStatus across the entire codebase will fail to compile until it handles Disputed. In a dynamically typed language, the agent writes a switch or if chain that handles the common cases and forgets the edge case. That's a runtime error waiting to happen. In Gleam, the compiler catches it before the code ever runs.

Simple Syntax, Fewer Ways to Go Wrong​

Gleam is a small language. There's one way to define a function, one way to handle errors and optional values (Result and Option). No exceptions, no implicit conversions, no macros.

This matters for agents because smaller decision space means fewer wrong decisions. When there are six ways to do something, the agent has to pick one, and it might not pick the idiomatic one. In Gleam, there's usually one way. The agent doesn't need to know the community's style preferences or the codebase's conventions for error handling. The language already decided.

Formatting is the same story. gleam format is canonical. No configuration, no style debates. The agent's output looks identical to hand-written code after formatting. You can't tell the difference, and you don't need to.

Whitespace Doesn't Matter​

I actually prefer whitespace-significant languages. Elm and Haskell are two of my favorites. Clean indentation instead of curly braces everywhere looks better to me. But agents aren't good at it yet. In my experience, agents constantly trip over Slim templates: indentation errors are common with LLM-generated code. The model might mix tabs and spaces, or get the nesting level wrong by one indent. These errors are silent and semantic (they change what the code does).

Gleam uses curly braces. Whitespace is irrelevant to the compiler. gleam format normalizes it. One fewer class of errors for agents to make.

Tight Feedback Loops​

Fast Compilation​

Gleam's compiler runs in a few seconds for our full project. A typical test suite in a dynamically typed language takes 30 seconds to a few minutes. When the agent is iterating, the difference between a few-second compile and a multi-minute test run adds up fast.

Fast Tests​

Tests are fast too. Because each test gets its own in-memory SQLite database with no shared state, we run them all in parallel. Around 800 tests finish in under a second. That speed accumulates over a session where the agent is compiling and testing dozens of times.

Less Training Data Is a Real Cost​

Gleam has less training data than JavaScript, TypeScript, or Python. Agents write worse Gleam on their first attempt. They reach for patterns that don't exist and invent functions that aren't in the standard library.

This is a real cost. The agent takes longer to write initial code in Gleam than it would in JavaScript.

But here's what I've found: the total time from "start writing" to "code is correct and deployed" is shorter in Gleam. The agent writes slower but the compiler catches errors instantly. In JavaScript, the agent writes faster but errors surface later, in tests or in production.

The Workflow in Practice​

Here's how a typical feature goes:

1. We write a spec describing what we want. This is iterative - we go back and forth with the agent refining the spec before any code is written. A good spec is the difference between useful output and garbage.
2. The agent writes the implementation: types, database queries, request handlers, views
3. It runs gleam build. Compilation fails with 5-10 errors.
4. The agent reads each error, fixes the code, rebuilds. A few rounds.
5. Compilation succeeds. The agent runs the tests. They pass, or they fail on business logic (not on null errors or type mismatches).
6. We review the diff. We're looking at logic, intent, and redundancy.

Agents tend to duplicate code rather than reuse existing functions, probably because of context window limits. Catching those opportunities to extract shared logic is the most common feedback we give.

We still write a fair amount of code by hand. Agents aren't always right, and they sometimes produce ugly or redundant code that needs to be caught and rewritten. We step in when the agent is spinning out on something, going in circles trying to fix the same error. In Gleam that happens a lot less than what we've seen in dynamic languages.

Other Languages​

Other statically typed languages with good compilers share some of these properties. Rust, OCaml, Haskell, and Elm all have strong type systems that catch errors at compile time.

But Gleam has a specific combination that makes it well-suited for agents:

• Simple syntax that's easy to generate
• Fast compilation for tight feedback loops
• Canonical formatting so agent output looks like hand-written code
• No nulls, eliminating one of the most common error classes
• Exhaustive pattern matching so no cases are forgotten
• Whitespace-insensitive so formatting errors can't change behavior

It also runs on the BEAM, which gives you fault tolerance and concurrency, but that's a separate conversation.

The trade-off is ecosystem maturity and training data. Gleam is young. Libraries are fewer. Agent-generated code needs more correction on the first pass. That gap is closing as training data grows.

The Bet​

I believe AI agents are already writing most of the code in a growing number of projects. Language choice is being evaluated differently. "How fast can a human write this?" matters less. "How much of the developer's review time does this require?" matters most.

The developer is the bottleneck. We're slow compared to computers. A language where the compiler has already verified structural correctness before the diff reaches your screen means the reviewer can focus on logic and intent instead of chasing down missing nil checks.

We picked Gleam for other reasons, but how well it works with AI coding agents has been huge.

Addendum: The State of AI-Assisted Coding​

Stepping back from the technical argument. AI-assisted coding is here to stay. Even if the technology doesn't meaningfully improve from where it is today, it's already useful enough that developers are adopting it en masse.

The Bar Is Higher, Not Lower​

Agents are good enough for a lot of business application work right now, but "good enough" comes with a big asterisk. Every diff needs scrutiny. The developer needs to be a domain expert, a security expert, and a programming expert. The speed at which code is produced has raised the expertise required from the developer, not lowered it.

Expect More Security Vulnerabilities​

Agents generate code that works, but "works" and "secure" are very different bars. They'll probably catch the obvious stuff like SQL injection. The less obvious stuff is where it gets dangerous - like not realizing that a decision you made three prompts ago means all your customers' PII is now accessible on a public URL as a side effect. That requires understanding the full picture, and agents don't have that yet. I think this will become a visible reality over the next few years as more agent-written code hits production without adequate review.

The Industry Is Evolving​

The industry is actively trying to figure out what the right abstractions look like for AI-assisted development. Two notable attempts:

Mog is a language designed to be written and read by AIs rather than humans. I'm skeptical. If the developer reviewing the diff is the bottleneck, optimizing for machine readability at the expense of human readability makes things worse.

Codespeak takes a different approach: specs and code as interchangeable representations, where you can move between them in both directions. I think both specs and code are important, and right now neither is enough on its own. A spec is great for big-picture thinking, but it lacks the detail that matters when things go wrong. Code has all the detail, but it's hard to step back and reason about the whole system by reading it. They operate at different levels of granularity, and collapsing them into one thing loses what makes each useful.

Statically typed languages have an advantage here: types are self-documenting. A well-defined type in Gleam already communicates a lot of what a spec would say about the shape of data and the boundaries of a function, without needing a separate document to describe it.

What Comes Next​

The developer's role is shifting toward a supervisory one. That might mean a lot more software gets written, or a lot fewer developers get employed, or both. And the supervisory role itself might not last if agents get good enough to close the loop on their own. That's a real possibility and it's worth being honest about.

After a year of building production software with AI coding agents, it works if you put in the effort to verify everything that comes out the other end. Gleam wasn't designed for AI agents, but good language design turns out to matter more than any tool built specifically for them.

While writing the previous post about our per-test SQLite databases, I was describing how each test gets its own in-memory database, no shared connections, no shared state. And I thought: wait, if nothing is shared, can we just run them all at the same time?

Turns out we could, and our server test suite went from ~4 seconds to ~0.85 seconds for around 800 tests. Zero code changes to the tests themselves. One 25-line Erlang module.

Why Sequential Was the Default​

Gleam's test runner, gleeunit, delegates to Erlang's EUnit framework. By default, EUnit runs test modules one at a time. This is the safe choice because most test suites have shared mutable state somewhere: a database connection, a named process, a file on disk. Running those tests concurrently produces the kind of failures that pass locally and fail in CI, or pass on Tuesday and fail on Wednesday.

Our tests don't have shared mutable state. Every test clones its own database. No two tests touch the same connection. The previous post explains the full setup, but the short version is: test_db.setup() clones a cached template database via SQLite's backup API and returns a fresh, independent connection. When the test ends, the connection is garbage collected and the database disappears.

What's Actually Isolated​

Before flipping the switch, we checked every category of shared state:

The persistent_term entries are write-once caches. Multiple tests might try to initialize the template database at the same time, but the first one wins and subsequent calls just read the cached value. That's safe.

ETS tables used in tests (for the rate limiter) are created without the named_table option, so each call to ets:new returns a unique table reference. No conflicts.

The Implementation​

EUnit supports a {inparallel, Tests} wrapper that distributes test functions across BEAM schedulers. It's been there for years, but gleeunit doesn't expose it. We submitted a PR to add a main_parallel() function, but it was pointed out that this fits better as a project-local solution than a change to gleeunit's core. That makes sense. We closed the PR and wrote a project-local Erlang module that replicates the test discovery logic and calls EUnit directly.

-module(parallel_test_runner).
-export([main/0]).

main() ->
    Options = [verbose, no_tty,
               {report, {gleeunit_progress, [{colored, true}]}},
               {scale_timeouts, 10}],
    Files = filelib:wildcard("**/*.{erl,gleam}", "test"),
    Modules = [to_module(list_to_binary(F)) || F <- Files],
    case eunit:test({inparallel, Modules}, Options) of
        ok -> erlang:halt(0);
        _  -> erlang:halt(1)
    end.

to_module(Path) ->
    case filename:extension(Path) of
        <<".gleam">> ->
            binary_to_atom(
              binary:replace(
                binary:replace(Path, <<".gleam">>, <<"">>),
                <<"/">>, <<"@">>, [global]),
              utf8);
        <<".erl">> ->
            binary_to_atom(
              binary:replace(lists:last(binary:split(Path, <<"/">>, [global])),
                <<".erl">>, <<"">>),
              utf8)
    end.

This does the same thing gleeunit does (glob for test files, convert filenames to module atoms) but wraps the module list in {inparallel, ...} instead of passing it flat. It reuses gleeunit_progress from the hex dependency for the dot-per-test output with color, so the test output looks the same as before.

The test entry point is one line:

@external(erlang, "parallel_test_runner", "main")
pub fn main() -> Nil

No fork. No submodule. Stock gleeunit stays in gleam.toml as a dependency (we still use it for the progress reporter). Only the server package uses the parallel runner. The shared and client packages use gleeunit's standard sequential main() because they have far fewer tests and don't need it.

The Results​

The shared and client packages didn't change because they already ran in under a second.

EUnit serializes its listener callbacks through a single process, so the dot-per-test progress output still arrives in order. Per-test stdout is delivered after each test completes, so you don't get interleaved output from concurrent tests. The test output looks identical to before, just faster.

Keeping It Working​

This works because the test architecture is clean. If someone adds a test that registers a named process with a fixed atom, or writes to a shared file path, two copies of that test will collide and produce flaky failures. The rules are simple:

• Don't share database connections between tests. Use test_db.setup().
• Don't register processes with fixed names. If you need a named process, include the test module name.
• Don't use named ETS tables. Pass the table reference instead.
• Don't write to the file system in tests.

If a test can't follow these rules, EUnit lets you mix {inparallel, ...} and {inorder, ...} in the same test run. We could maintain a list of sequential modules in the runner and group them separately:

Sequential = [some_integration_test],
Parallel = Modules -- Sequential,
eunit:test([{inparallel, Parallel}, {inorder, Sequential}], Options)

The sequential modules would run one at a time while everything else stays parallel. We haven't needed this yet, but it's a few lines if we do.

The Accidental Win​

None of this was planned. We chose per-test SQLite databases because they eliminated cleanup code, ordering dependencies, and flaky tests from leaked state. We're still a bit surprised that a permanent 4.7x speedup, one we'll benefit from for the lifetime of this project, took an afternoon and 25 lines of Erlang.

37 lines total (counting the 12-line FFI module from the previous post) for per-test database isolation and parallel execution across all available CPU cores. No test framework plugins. No configuration. The whole thing compiles with gleam build and runs with gleam test.

This is Part 7 of the Curling IO Foundation series. Next up: A Live Admin Panel Without Writing JavaScript.

The Full List​

• Curling Alberta
• Curl BC
• CurlManitoba
• CURLSASK
• Curling Ontario
• Northern Ontario Curling Association
• Curling Québec
• New Brunswick Curling Association
• Nova Scotia Curling
• Newfoundland & Labrador Curling Association
• Curl PEI
• Curling NT
• Nunavut Curling Association
• Yukon Curling Association

What Associations Use It For​

Provincial associations use Curling IO to run their competitions: provincial championships, playdowns, regional qualifiers. They manage team registrations, schedule draws, score games live, and publish results. Fans and participants see brackets, standings, and scoreboards update in real time.

Associations also collect affiliate fees through the platform. When a curler registers at their local club, the club's registration fees and the association's affiliate fees can be collected together in one transaction. The association fee and the club's own fees appear on a single checkout. No separate invoicing, no manual reconciliation.

The affiliate fee tie-in is optional. Clubs can use Curling IO independently without inheriting association fees or reporting member data. But clubs that do opt in get the fee collection and reporting handled automatically.

The platform is fully bilingual (English and French), which matters for associations like Curling Québec and for clubs across the country with francophone members.

Why It Matters for Clubs​

When your provincial association is on Curling IO, a few things work in your favour.

Your curlers already have profiles. A curler who registered for a provincial bonspiel or played in a championship already exists in the system. When they register at your club, they find their existing profile. No re-entering names, addresses, or emergency contacts.

Competitions connect. A curler's results from club leagues, provincial playdowns, and national championships all live in the same system. Their profile carries from club leagues to provincial to national competitions.

Why It Matters for Curlers​

From a curler's perspective, Curling IO is one account. They register for their Tuesday night league at their local club, sign up for a weekend bonspiel at another club, and qualify for a provincial championship. Same login, same profile, same payment flow.

There are currently around 150,000 curler profiles in the system across hundreds of active clubs and all 14 provincial and territorial membership associations. That number grows every season as more clubs come online.

Getting Started​

If your club is under a Canadian provincial association, your association is already on Curling IO. Getting started means your affiliate fees and curler database are connected from day one. There's no setup fee, no monthly fee, and no contract.

Clubs outside of Canada can use Curling IO too, just without the association tie-in.

Check out our getting started guide or visit your provincial association's Curling IO page to see it in action.

Curling IO's tests don't need a shared test database, cleanup hooks, or transaction tricks. Each test gets its own database, so a test can pass alone or in the full suite for the same reason: nothing else can touch its data.

That falls out of one Version 3 choice: SQLite runs in-process. Each test gets a completely independent in-memory SQLite database, cloned from a template in microseconds using SQLite's backup API.

The Shared Database Problem​

In a traditional Postgres or MySQL test setup, every test talks to the same database server. You need a strategy to keep tests from contaminating each other:

Transaction rollback. Wrap each test in a transaction, roll it back at the end. Works until your code uses transactions internally, or spawns processes that need to see the test data (the classic Ecto sandbox problem).

Truncation. Delete all rows from every table between tests. Slow, and you need to get the table ordering right to avoid foreign key violations.

Database cleaner. A gem/library that combines both strategies with configuration for which tables to clean, which strategy to use, and when. It works, but it's ceremony that exists purely because of the shared database.

All of these are workarounds for the same architectural constraint: one database server, many tests.

In-Memory SQLite: One Database Per Test​

SQLite opens a database by passing a file path. Pass :memory: instead and you get an in-memory database that exists only for the lifetime of that connection. It's fast (no disk I/O) and completely isolated. Nothing else can see it, and closing the connection frees everything.

pub fn setup() -> sqlight.Connection {
  let assert Ok(conn) = sqlight.open(":memory:")
  let assert Ok(_) = sqlight.exec("PRAGMA foreign_keys=ON;", conn)
  let assert Ok(_) = sqlight.exec(schema_sql, conn)
  conn
}

pub fn should_reject_duplicate_registration_test() {
  let conn = test_db.setup()
  // Insert test-specific data
  insert_org(conn, test_org())
  insert_listing(conn, test_listing())
  // ... test logic, assertions
  // conn goes out of scope, database vanishes
}

There's no possible cross-contamination because there's nothing shared. Test A and test B literally operate on different databases. You can run them in parallel on BEAM processes without any coordination.

The Schema Execution Cost​

This approach has an obvious cost: every test executes the full schema. For us that's 77 CREATE TABLE, CREATE INDEX, and CREATE VIEW statements. We profiled it:

• Opening an in-memory SQLite database: 15 microseconds
• Executing 77 schema statements: 1,100 microseconds (1.1 ms)

At 1.1 ms per test across ~500 tests that need a database, that's about 550 ms of schema execution. Not terrible, but not free either. And it scales linearly with both the number of tests and the size of your schema.

SQLite's Backup API: Page-Level Cloning​

SQLite has a backup API designed for copying databases between connections. It operates at the page level: it doesn't re-parse or re-execute SQL, it copies raw database pages from one connection to another.

Once at startup:  open(":memory:") → execute full schema → template
Per test:         open(":memory:") → backup_copy(template) → ready

-module(test_db_ffi).
-export([clone_db/1]).

clone_db(Template) ->
    {ok, Dest} = esqlite3:open(":memory:"),
    {ok, Backup} = esqlite3:backup_init(Dest, "main", Template, "main"),
    '$done' = esqlite3:backup_step(Backup, -1),
    ok = esqlite3:backup_finish(Backup),
    {ok, Dest}.

@external(erlang, "test_db_ffi", "clone_db")
fn clone_db(
  template: sqlight.Connection,
) -> Result(sqlight.Connection, Nil)

fn template_db() -> sqlight.Connection {
  case get_cached("test_template_db") {
    Ok(conn) -> conn
    Error(Nil) -> {
      let assert Ok(conn) = sqlight.open(":memory:")
      let assert Ok(_) = sqlight.exec("PRAGMA foreign_keys=ON;", conn)
      let assert Ok(_) = sqlight.exec(schema_sql, conn)
      cache("test_template_db", conn)
      conn
    }
  }
}

pub fn setup() -> sqlight.Connection {
  let assert Ok(conn) = clone_db(template_db())
  let assert Ok(_) = sqlight.exec("PRAGMA foreign_keys=ON;", conn)
  conn
}

The Numbers​

At the time we switched to the clone method, we had 594 tests and 77 schema objects. We're still early in the rewrite and already approaching 1,000 tests. By launch we expect closer to twice the schema objects and somewhere around 5,000 tests.

Here's what we measured at 594 tests:

The schema execution cost dropped from ~550 ms to near zero. The remaining 2.6 seconds is actual test logic (inserting data, running business logic, assertions) plus BEAM VM startup overhead.

The savings become more meaningful at scale. In a traditional Postgres setup, you'd use truncation between tests, issuing TRUNCATE TABLE on every table, in foreign-key-safe order, over a socket to the database server. With around 100 tables and 5,000 tests (a conservative estimate for our full rewrite, realistically 2-3x the tests), that's 500,000 truncation statements hitting a database server. Even at sub-millisecond per truncate, it adds up.

With the backup approach, the clone cost is ~25 microseconds per test regardless of schema size. At 5,000 tests that's 0.125 seconds total. No truncation ordering, no socket round-trips.

For context, this is a real application test suite covering cart operations, payment processing, registration validation, affiliate fees, waivers, round robin generation, scheduling, scoring, and more. Not trivial tests.

Why This Works So Well​

The backup API is a nice optimization, but the real win is that in-process SQLite eliminates the shared database problem entirely.

With Postgres, your test process talks to a database server over a socket. Every test that writes data is writing to the same place. You need isolation strategies because the architecture demands them.

With in-process SQLite, the database lives in your process's memory. Creating a new one is a memory allocation, not a network connection. There's no server to coordinate with and no connection pool to manage. The isolation falls out of the architecture for free.

This also means:

• No test ordering dependencies. Each test is fully self-contained.
• Safe parallelism. BEAM processes each get their own database, zero coordination needed.
• No cleanup code. No teardown, no after_each, no database_cleaner.
• No flaky tests from shared state leaking between runs.

Trade-offs​

This isn't free of trade-offs. You're not testing against the same database engine you run in production... unless you also run SQLite in production, which we do. If you're using SQLite for tests but Postgres in production, you'd miss Postgres-specific behavior (custom types, advisory locks, jsonb operators, etc.).

The other trade-off is that in our setup, each test builds up its own data from scratch. In practice this is a feature (every test explicitly declares its dependencies) but it does mean more setup code per test compared to a shared fixtures approach. That said, this is a choice, not a limitation of the technique. You could just as easily insert seed data into the template database before caching it, and every clone would start with that data pre-loaded. If your test suite benefits from a well-defined set of standard users, organizations, or other reference data, seeding the template is a straightforward way to reduce per-test setup while keeping full isolation.

This Isn't BEAM-Specific​

Our examples are in Gleam and Erlang, but the backup API is a C-level SQLite feature. Most languages expose it:

# Python 3.7+ has it built in
source = sqlite3.connect(":memory:")
source.executescript(schema_sql)

dest = sqlite3.connect(":memory:")
source.backup(dest)

// Node.js better-sqlite3
const template = new Database(":memory:");
template.exec(schemaSQL);

const dest = template.backup(":memory:");

// Rust rusqlite
let template = Connection::open_in_memory()?;
template.execute_batch(schema_sql)?;

let mut dest = Connection::open_in_memory()?;
let backup = backup::Backup::new(&template, &mut dest)?;
backup.run_to_completion(5, Duration::ZERO, None)?;

The pattern is the same in every language: build a template once, clone it per test via the backup API. The FFI detour we took through esqlite is only necessary because our particular Gleam driver doesn't expose it yet.

The Full Stack​

Here's what our test infrastructure looks like in its entirety:

• test_db.setup() clones a cached template database via SQLite backup API
• test_db.tz_db() returns a cached timezone database (loaded once, not per test)
• persistent_term is BEAM's global cache for the template DB and timezone data
• 12 lines of Erlang FFI wraps the SQLite backup API

That's the entire test infrastructure. No test framework plugins, no database cleaner gems, no truncation strategies. SQLite and 12 lines of Erlang.

This is Part 6 of the Curling IO Foundation series. Next up: Parallel Tests for Free.

Purpose-Built for Curling​

Generic sports platforms and website builders can handle basic registration, but curling has concepts that most software doesn't account for: ends, hammer, draw schedules, round robins with pools, page playoffs, spare management, rental ice, bonspiels, waitlists, and online waivers.

If the software you're evaluating doesn't understand these things natively, you'll spend your time working around it instead of working with it. Ask whether you can schedule a draw across four sheets, score a game end-by-end, or run a triple knockout bracket without manual intervention.

Management First, Not a CMS​

Some club management software is really just an extension of a content management system (CMS), focused on building websites like it's still 1999. Building a nice website is already a solved problem. Squarespace, Wix, WordPress, and hundreds of others already have that covered. Look for software that has the curling-specific depth you need, not a website builder with registration bolted on. Most clubs are better off with a simple website any volunteer can update than a giant CMS no one remembers how to administer.

Modern and Fast​

Performance matters more than people think. If the platform feels slow when a curler is trying to register and pay, they notice. Pages need to feel snappy, not just functional. If the platform is also used for provincial or national competitions, it's already proven it can handle real traffic, not a few dozen people checking scores at the same time.

More than half of web traffic comes from phones now. Volunteers entering scores, curlers checking draw times, spectators following results: most of that happens on a phone. The platform needs to work well on smaller screens, desktops included but not prioritized.

Pricing Transparency​

Pricing models vary widely. Some platforms charge setup fees, monthly fees, per-member fees, or some combination. Others take a percentage of transactions. Before you sign up, make sure you understand:

• Is there a cost just to get started?
• Are there ongoing fees regardless of usage?
• What does payment processing actually cost, all-in?
• Are there per-member or per-registration charges on top?

Clubs are often volunteer-run with tight budgets. A platform that costs hundreds of dollars a month before a single curler registers doesn't make sense for a 4-sheet club with 120 members.

Online Registration and Payments​

If your members can't register and pay online, you're creating work for yourself. Curlers should be able to browse events, register, and pay in one flow. No filling out PDFs, emailing forms, or bringing cheques to the club.

The payment processing should be built in, not bolted on through a third-party plugin. And it should handle what curling clubs deal with: membership fees, family registrations, multiple events in one cart, early bird pricing, discounts, and partial refunds.

League and Competition Management​

You should be able to:

• Generate round robin draw schedules across sheets and time slots
• Score games live with optional end scores
• Automatically calculate standings with head-to-head tiebreakers
• Run playoff brackets that advance teams based on results
• Share live scoreboards that spectators and curlers can follow from home

If the platform can't handle a standard 8-team round robin on 4 sheets without manual scheduling, it's not built for curling.

Data Portability and Accounting Integration​

Your data should be yours. Look for the ability to export registration data, financial records, and member information. If you ever want to switch platforms, you shouldn't be locked in.

For clubs that track finances seriously, look for accrual, double-entry accounting and integration with software like QuickBooks, Xero, or Sage. Ask whether the platform can export transactions in a format your bookkeeper can actually use.

Track Record, Development, and Support​

Who else is using the platform? A tool used by a handful of clubs is a different proposition than one trusted by national organizations and hundreds of clubs. Is the software still being actively improved? How often do updates ship? Some platforms haven't changed in years, and it shows.

Support turnaround matters too. When something breaks during league night or a bonspiel weekend, you need a response in hours, not weeks. Ask other clubs what their experience has been. Community adoption also means your curlers are more likely to already have an account, which makes registration smoother for everyone.

Who Owns It​

It's worth looking past the product and asking who actually owns the company behind it. A platform built and run by people in the curling community is a different thing than one owned by an investment firm in another country. When a private equity group acquires a software company, the priorities tend to shift: prices go up, support gets outsourced, and development slows down or focuses on whatever makes the numbers look good for the next quarter. The curling world is small and mostly volunteer-driven. You want the people making decisions about your software to understand that.

AI Ready​

Are you already using chatbots like Claude.ai to help with day-to-day tasks? A lot of club managers are. As these tools get more capable, they'll be able to do more than just answer questions. Look for a platform that's ready for this. Setting up a draw, checking registration numbers, pulling a financial report: these are things your AI assistant should eventually be able to do for you, if the software supports it. Your members could benefit too, using their own chatbots to register for events or set up reminders for upcoming matches.

Ask the Right Questions​

Full disclosure: we built Curling IO to check all of these boxes. But regardless of what you choose, these are the questions worth asking.

Version 3 should be cheaper to operate, easier to restore, and still fast during peak registration and live scoring. That pushed us toward a choice we didn't expect: SQLite.

We assumed PostgreSQL at first. After a decade running Postgres in production, we knew the tooling, the failure modes, and the operational playbook. Then we compared self-hosting Postgres with Litestream-backed SQLite and changed our minds.

What Version 2 Runs On​

Curling IO Version 2 runs on Rails backed by PostgreSQL on Crunchy Bridge, a managed Postgres service that has worked well for us. Crunchy Data handles backups, failover, and tuning. We don't think about shared_buffers or autovacuum settings. We don't run pgBackRest or schedule base backups. (Crunchy Data was acquired by Snowflake in 2025, which adds another reason to reduce our dependency on third-party managed services.)

The trade-off is cost, lock-in, and jurisdiction. Crunchy Bridge is AWS-only, so the app servers have to live on AWS too. That's the full stack dependent on a single US cloud provider. We're a 100% Canadian company and we'd rather keep our infrastructure closer to home, especially given the current political uncertainty south of the border.

For Version 3, we're moving to OVH, a French-owned provider with data centers in Quebec and Ontario. All data stays in Canada. Crunchy Bridge doesn't run on OVH, so we can't bring it along. Self-hosting Postgres on OVH would mean taking on everything Crunchy handles today: connection pooling, server tuning (shared_buffers, effective_cache_size, work_mem, max_connections), autovacuum monitoring, and the full backup story (pgBackRest, WAL archiving, scheduled base backups, tested restore procedures, monitoring backup freshness). That's a lot to take on for a small organization.

The Architecture: Database Per Sport​

Version 3 uses a database-per-sport architecture. Each sport gets its own SQLite file with an identical schema:

db/
├── curling.db          # All curling club data
├── pickleball.db       # All pickleball club data
└── shared.db           # Cross-sport reference data, jobs, email suppressions

Each sport database is multi-tenant. Every table with tenant data includes an org_id column, and every query filters by it. Adding a new sport means creating a new database file with the same schema. No cross-sport queries, no shared-database contention.

shared.db holds things that span sports: Canadian tax jurisdictions (17 rows covering GST, HST, PST, and QST rates by province), the background job queue, and email suppression lists from Postmark webhooks.

At startup, the server opens one connection per database and holds it for the lifetime of the app:

pub fn open(path: String) -> Result(sqlight.Connection, sqlight.Error) {
  use conn <- result.try(sqlight.open(path))
  use _ <- result.try(sqlight.exec("PRAGMA journal_mode=WAL;", conn))
  use _ <- result.try(sqlight.exec("PRAGMA busy_timeout=5000;", conn))
  use _ <- result.try(sqlight.exec("PRAGMA foreign_keys=ON;", conn))
  Ok(conn)
}

Three PRAGMAs on every connection: WAL mode for concurrent reads, a 5-second busy timeout so writes queue instead of failing immediately, and foreign key enforcement (which SQLite disables by default).

One connection per database. No connection pool. No pool configuration. Each incoming HTTP request gets the sport-specific connection (resolved from the hostname) plus the shared connection.

Why In-Process SQLite​

SQLite runs inside the application process. There's no socket, no TCP round-trip, no serialization between the app and the database. A query is a function call.

Our workload is primarily simple indexed lookups: single-row fetches by primary key, filtered lists by org_id, a handful of line items joined to an order. SQLite handles tens of thousands of write transactions per second, far beyond what 1,000+ curling clubs will generate. Even during peak registration or when a provincial championship is posting live scores, the load profile is overwhelmingly reads with occasional write bursts.

The cost follows from the architecture. No separate database server means no database hosting bill. The entire v3 stack runs on a single server for less than what managed Postgres alone costs on AWS.

WAL Mode and Concurrency​

WAL (Write-Ahead Logging) is what makes SQLite viable for a concurrent web application. Without it, any write locks the entire database for both readers and writers. With WAL, readers proceed concurrently with writes. On the BEAM, where hundreds of lightweight processes might query simultaneously during a traffic spike, this is essential.

Writes are still serialized. One writer at a time, coordinated by a mutex in the SQLite library. If the write lock can't be acquired within the 5-second busy timeout, SQLite returns SQLITE_BUSY. With our read-heavy workload, write contention hasn't been a practical concern. This is why we use a separate database for background jobs. Job processing writes to shared.db, not the sport databases, so it never contends with registration queries. With SQLite's single-writer model, separating write-heavy workloads into different files is a real architectural consideration, not just organization.

Litestream: The Tipping Point​

This is what tipped the scales.

SQLite is a file. Litestream watches that file and continuously replicates its WAL frames to S3-compatible object storage. For us, that's OVH Object Storage in two different geographic locations in Canada. Changes sync every 10 seconds to both.

The configuration is one YAML file:

dbs:
  - path: /var/lib/curling-io/databases/curling.db
    replicas:
      - type: s3
        bucket: xxxxx
        endpoint: xxxxx
        sync-interval: 10s
      - type: s3
        bucket: xxxxx
        endpoint: xxxxx
        sync-interval: 10s

litestream restore -o /path/to/curling.db s3://xxxxx/curling.db

That produces a ready-to-use database file. Copy it to the right path, start the app.

Now compare that to self-hosting PostgreSQL backup and recovery:

1. Install pgBackRest
2. Configure a stanza, set archive_mode and archive_command in postgresql.conf
3. Schedule base backups via cron
4. Monitor backup success, WAL retention, and disk usage
5. Periodically test restores (because an untested backup isn't a backup)
6. When disaster strikes: stop PostgreSQL, run pgbackrest restore --type=time --target="...", wait for WAL replay, verify the recovery point, promote to primary

PostgreSQL gives you something Litestream doesn't: exact transaction-level point-in-time recovery. You can roll back to any specific transaction. Litestream gives you "latest snapshot plus WAL frames," which means a worst-case recovery gap of about 10 seconds. For our use case that's more than sufficient.

The operational gap is where it gets decisive. Litestream is one binary, one config file, near-zero ongoing maintenance. PostgreSQL backup is a practice, something you rehearse, monitor, and maintain over the life of the project. Even with perfect tooling, you can't reduce "restore a running server's state" to "download a file and start the app." That gap is architectural. It won't close with better Postgres tooling because the complexity is inherent to backing up a running server process.

The simplicity ceiling for SQLite backup is fundamentally higher than what's possible for any client-server database.

The SQLite Tax​

Here's what we pay for that simplicity. Every item below is something PostgreSQL handles natively.

No Real Types​

SQLite doesn't have booleans, dates, or enums. Booleans are stored as INTEGER 0/1. Dates are Unix epoch integers. Enums are TEXT strings.

Every boolean parameter needs a db.bool_to_int(value) call. Every boolean decoder needs a != 0 check. All date formatting, timezone conversion, and comparison lives in application code. There's no DATE_TRUNC, no INTERVAL, no AT TIME ZONE.

We use STRICT tables on everything, which enforces that values match declared column types (INTEGER, TEXT, REAL, BLOB). It's a free safety net for anything that bypasses the application layer, but it doesn't help with booleans, dates, or enums. Those stay as application-level concerns, but since Gleam and Parrot are the only source of writes and types are enforced there, it's manageable.

Limited ALTER TABLE​

SQLite stores its schema as the original CREATE TABLE text, not as structured system catalogs like PostgreSQL. This means ALTER TABLE is minimal:

• ADD COLUMN, RENAME COLUMN, DROP COLUMN all work
• Changing a column's type, default, or NOT NULL does not
• Adding or modifying CHECK or FOREIGN KEY constraints does not
• Adding UNIQUE to an existing column does not

Changing a column post-launch requires a four-step dance: add the new column, copy the data, drop the old column, rename. PostgreSQL handles this with a single ALTER COLUMN.

No CHECK Constraints​

We don't use CHECK constraints anywhere. This is a policy decision, and not one we're thrilled about.

CHECK constraints are embedded in the CREATE TABLE DDL string. Modifying one means a full table rebuild. Adding a new enum value shouldn't require that. So all validation lives in Gleam: union types for enums (with exhaustive pattern matching at compile time), validation functions for business logic, and let assert in decoders to crash fast if bad data gets in.

Write Serialization​

As covered above, writes are serialized. In practice this barely matters because there's no network round-trip and no protocol overhead. A write is a function call that completes in microseconds. The lock is held for such a short window that writers rarely wait for each other at all. But it does rule out horizontal scaling to multiple app servers writing to the same database.

Single Node Only​

SQLite is a file on local disk. Multiple app servers can't share it (NFS breaks SQLite's file locking and leads to corruption). We're locked into a single-server architecture. On a BEAM runtime that handles high concurrency on one node, this is fine for well over 100,000 clubs. It's a hard ceiling if we ever need more, and if we do, that's a really good problem to have.

There are projects that add distributed replication to SQLite (LiteFS, rqlite, dqlite), but they add significant complexity: FUSE filesystems, consensus protocols, additional infrastructure. At that point you're fighting to make SQLite behave like Postgres, and you should probably just use Postgres.

NIF Risk​

Our SQLite driver (esqlite) is an Erlang NIF - compiled C code that runs outside the BEAM scheduler's control. A long-running query blocks a scheduler thread. A segfault takes down the entire VM.

In practice, SQLite's C library is near-bulletproof, and our queries return in microseconds. We mitigate the risk by keeping all queries simple (indexed lookups, no full table scans) and pushing anything heavy to background jobs. But the risk surface exists.

SQL Dialect Gaps​

Small things that add friction:

• DELETE FROM t WHERE ... LIMIT 1 doesn't work. You need a subquery: DELETE FROM t WHERE id = (SELECT id FROM t WHERE ... LIMIT 1).
• No LISTEN/NOTIFY for real-time push from the database. Change notification goes through application-level pub/sub.
• NULL comparisons need IS ? instead of = ? when the parameter can be NULL.

Why We Accept It​

Every tax above is an application-level workaround. Type conversions, date formatting, schema evolution dances, validation in Gleam instead of CHECK constraints. None of them change the architecture. They're annoyances, not obstacles.

The things that would actually force a migration (write contention, multi-node scaling, database size) aren't happening at 1,000 clubs with a read-heavy workload on the BEAM.

When We'd Switch to PostgreSQL​

Honestly, we don't see it happening anytime soon. Most of the limits people worry about with SQLite (database size, write throughput, busy errors) can be pushed further by upgrading the server. Vertical scaling is cheap and simple, and the BEAM makes excellent use of whatever hardware you give it.

The only real trigger would be needing multiple application servers, and that would mean we've seriously outgrown our predictions or miscalculated. If that happens, the migration path is mechanical, not architectural. Swap sqlight for gleam_pgo. Adjust SQL dialect across all query files: ? becomes $1, $2, ..., INTEGER PRIMARY KEY becomes GENERATED ALWAYS AS IDENTITY, booleans become real booleans, remove the DELETE subquery workarounds. Separate .db files map to PostgreSQL schemas within a single database. Business logic and request handlers stay the same.

What's Next​

If SQLite hits a wall, we switch to Postgres. The exit strategy is defined and the migration is a dialect swap, not a rewrite.

But so far, Litestream plus in-process SQLite has been one of the best decisions in the v3 rewrite. And there's one more benefit worth its own post: because SQLite runs in-process, every test gets its own in-memory database. No shared state, no cleanup, no flaky tests. That's next.

This is Part 5 of the Curling IO Foundation series. Next up: Test Isolation for Free with SQLite.

One Workflow From Registration to Results​

Curling IO handles the full competition workflow:

• Online registration and team assembly
• Draw scheduling across pools, sheets, and time slots
• Round robins, page playoffs, brackets, and mixed doubles formats
• Live end-by-end and shot-by-shot scoring
• Automatic standings and bracket advancement
• Embeddable results and scoreboards

Organizers manage the event in one place instead of moving registrations, schedules, scores, and results between separate systems.

Built for Traffic Spikes​

Competition traffic is bursty. A draw can finish on several sheets within minutes, while fans refresh scores, standings, and brackets at the same time. Curling IO caches and distributes that live data so event administrators can keep scoring without the public scoreboard slowing them down.

The Same Platform Your Club Can Use​

The draw scheduling, scoring, and bracket tools used for major competitions are the same tools available for a Tuesday night league or weekend bonspiel. A four-sheet club gets the same competition engine used at the national level.

Built for Curling, Not Adapted for It​

Curling has concepts that generic sports software doesn't account for: ends, hammer, last stone advantage, round robins with multiple pools, page playoffs, mixed doubles scoring. Even draw scheduling has curling-specific nuances, like minimizing how often a team plays on the same sheet. We even published a free draw schedule tool at curlingschedules.com that anyone can use.

Curling IO was built around these concepts. Every provincial and territorial curling association in Canada uses it for registration, competition management, or both.

See It in Action​

If your club wants the same tools that power Canadian curling at the national level, get started here. There are no setup fees or monthly fees. Check out our pricing page for a full feature breakdown and cost calculator.