Feature walkthrough
Seven core capabilities of the platform. Screenshots are on the way — this walkthrough will be illustrated with real captures from the running system.
Contest management
Organizers configure the full lifecycle of a contest — start/end/freeze time, visibility rules for the scoreboard and challenge difficulty, and bracket grouping for different tracks of contestants. A running contest can be paused, reset, or exported/imported as a self-contained data package for re-use or archival.
User & team management
Admins manage contestant accounts and teams, assign a team captain, and award bonus points to an individual or a whole team outside of normal flag scoring. Every user and team has a detail view — submission history, solved/unsolved challenges, and awards — for auditing performance during and after the contest.
Challenge authoring & management
Challenge writers create and edit challenges with static, regex, or per-team dynamic flags, point-deducting hints, tags/topics for discovery, and prerequisite/unlock chains between challenges. Every upload is versioned, so a challenge writer can preview a build before it goes live or roll back to a previous version if something breaks.
Scoreboard & dashboard
A real-time scoreboard ranks teams within a bracket, with a freeze option so organizers control exactly when official standings are revealed. An admin dashboard summarizes contest health at a glance — challenges, solves, and active participants — and standings can be exported to CSV for official records.
Monitoring & audit
Admins and jury watch each team's running challenge environment live, review a full action log per team/user (challenge started, flag correct/incorrect, hint unlocked), and check a separate admin audit log for every administrative change. Contestant tickets flow into the same view so disputes get handled without leaving the monitoring screen.
Multi-contest architecture
The platform's biggest structural change: every contest-dependent table now carries a
contest_id, Redis keys are namespaced per contest, JWTs carry a contest claim
checked by middleware, and Kubernetes namespaces are prefixed per contest with their own
resource quota. The result is that two contests — even with overlapping team names and
reused challenge templates — can run at the same time with zero cross-contamination of data,
scores, or running pods.
KYPO Sandbox challenge integration
A new "sandbox" challenge type links directly to a Training Instance on KYPO CRP. Starting it takes a contestant straight into their KYPO Training Run — no separate login, no manual navigation — because team creation in FCTF automatically provisions a matching KYPO account behind the scenes. Once the scenario is solved, FCTF pulls the Training Run result back through the KYPO API and folds it into the same unified scoreboard as the Jeopardy challenges.