Calendar
Challenge briefProvenance
DataDaily Problem

Provenance

A service left behind one recorded run of its activity and no documentation of how it works. Study it, then build a model that predicts where the activity is heading and picks out the records that don't belong.

Open SubmissionModerate confidenceNode 22 · JavaScriptRatedRecurringSolo
TypeHidden GauntletAmbiguity

Recurring: enter again after a result to beat your best score. Your best result counts, and your rating moves only on your first attempt.

This brief is intentionally open, and your interpretation is scored. When the challenge gives you a product owner, ask them from your attempt to settle what the brief leaves unspecified.

Opens
Oct 1812:00 UTC
Closes
Oct 1912:00 UTC
Effort
90 min
Entered
0
XP
175
Advanced1550
Author estimate · calibrating (0 attempts)
Need a rules clarification?

Ask before you start. The clock cannot be paused once your window opens.

01
Specification

Challenge brief

Type
Hidden GauntletAmbiguity
Stack
Node 22 · JavaScript
Format
Daily Problem · Open Submission · Solo
Time
90 min

Overview

You have one recorded run of a service's activity: a stream of records, each with a time, a key, a kind, and a value. How the service behaves is not documented, and it is not constant. It shifts between busy and quiet modes, mixes several kinds of activity, follows a rhythm that slowly drifts, and every so often emits a record that does not belong. Study the run and build a model that forecasts how much activity is coming and of what kind, scores each record for how anomalous it is, marks the points where the behaviour shifts, and fills in a value that has been blanked out. The grader trains your model on your run, then scores it on a different run of the same service that you never saw. Each job must beat a plain whole-run average by a set margin.

What is tested

  • Inferring latent structure from data: regimes, behaviour mixtures, seasonality, drift
  • Forecasting under regime shifts
  • Anomaly ranking and change-point detection
  • Generalizing to a held-out run of the same process

Acceptance criteria

  1. 1src/model.js exports createModel() with fit, forecast, anomalyScore, changepoints, and predictField exactly as the specification describes.
  2. 2Volume forecasts by kind that beat the simple global model on a fresh run, for both total and per-kind counts.
  3. 3Anomaly scores, regime switch points, and masked-value predictions that beat the simple global model by the margins the specification states.
  4. 4The public suite still green.

Rules

  • Work solo in the private repository Finals creates when you enter.
  • No external network access during evaluation.
  • Node 22, ES modules, no dependencies — only node: built-ins.
  • Your model is graded on a run of the process you have not seen, and must finish within the time limit.

Diagnosis, validation, and repair are scored. Submission speed is not.

02
Execution contract

Runtime and interface

You are given a Node 22 · JavaScript codebase and work inside it. The stack is fixed for this challenge.

BoundaryCLI
Start commandnode --test test/*.test.js
Portn/a
Health checkn/a
03
Open Submission session

How competing works

01
Accept the rules

Confirm the window, the tooling policy, evidence collection, and the submission contract.

02
Finals creates your attempt repository

A private repository, seeded with the challenge. You get one clone command and your clock starts.

03
Work in your own environment

Use any editor, agent, or model. Declare your tooling; it is recorded on your result.

04
Run the pre-flight check

Confirm at any time that your submission builds, starts, and answers its health check.

05
Push to main before the deadline

Your last push received on main before the deadline is your submission. Submit early if you are done.

06
Grading runs your commit

Your submission is built and run in an isolated environment: public tests, hidden tests, edge cases, security scans, and two independent code reviews.

07
Read the scorecard

What passed, what failed, where points were lost, and how stronger submissions differed.

04
Evaluation

Scoring model

Automated checks make up most of the score. Two independent code reviews cover what tests cannot, and every review finding cites a file and line.

Workflow is not scored on this challenge.

The “AI workflow and verification” band (15%) requires the Finals companion, which Open Submission does not use. Its weight is spread across the remaining bands. The percentages below are the ones applied.

Functional correctness64%
Hidden and edge-case testing18%
Architecture and code quality12%
Security and resilience6%
Automated checks

Build, startup, public and hidden tests, edge cases, performance, dependencies, security, and accessibility where relevant.

Independent code review

Two independent code reviews, each by a different model. Every finding cites a file and line.

Workflow evidence

Not scored at this tier. Requires the Finals companion session log.

05
Verification tier

Open Submission

What this result verifies

Your submitted commit is graded in an isolated environment, and its push history is confirmed against the challenge window.

Mints a credentialPrize eligibleMoves your rating
06
Privacy

What Finals records

Public by default

Score band, discipline, calibrated difficulty, verification tier, placement, and rating movement.

Private unless you publish

Score breakdowns, failing tests and their inputs, review findings, how stronger submissions differed, repository contents, and transcripts.

Never collected

Keystrokes and screen recordings, except during a live round you opt into. Secrets are redacted on your machine before anything is uploaded.

  1. 1Finals
  2. 2Challenges
  3. 3Schedule