Find guidance for challenge work, collaboration, governance and platform administration. Options appear according to your account role and the challenge you have selected.
Release 13 governs uploaded files, account privacy requests, retention actions and recovery evidence.
Uploaded resources and attachments use links that expire after a short period. A copied old link cannot provide permanent access.
Files record pending, clean, quarantined or rejected states. Production must connect an approved external malware scanner.
Each file receives a retention date. Expired content can be reviewed before purge, while a legal hold prevents deletion.
Signed-in users can open Account security to download their data or request access, correction or deletion.
The platform administrator can revoke sessions and deactivate access without silently erasing operational evidence.
A backup counts as verified only after an isolated restoration test is recorded with accountable evidence.
Production access uses a short-lived email sign-in link and a protected browser session.
The session credential is unavailable to page scripts and is not stored in browser local storage.
Repeated link and verification attempts are limited and recorded as security events.
The platform administrator can revoke one session or all sessions belonging to an account.
The demo account selector and immediate development link remain available only when the local profile explicitly enables them.
Your workspace changes according to your role, challenge membership and selected challenge.
The demo account selector changes who you are viewing as. In production, secure sign-in will replace this convenience.
Use Current challenge to move between challenges without changing account. Your role may differ between challenges.
Open a first-tier group, then select a page. On mobile, the menu opens as a drawer from the top bar.
Challenge chat is the persistent right pane. It can be collapsed, narrow or expanded without losing its conversation.
Publishing makes the challenge discoverable; it does not start team work or require teams to exist.
| Status | What it means | Typical actions |
|---|---|---|
| Draft | Visible only to authorised operators while its design is incomplete. | Configure phases, governance, judging, agenda and public information. |
| Published | Appears in the public challenge directory and can receive registrations or expressions of interest. | Promote the challenge, receive applications and form teams. No team is required before publishing. |
| Active | Participants are working and submitting phase deliverables. | Run events, support teams, monitor progress and manage phase access. |
| Judging | Submitted evidence is held for assigned judges to assess. | Resolve conflicts, complete scorecards and record decisions. |
| Completed | The operating cycle is closed and outcomes can be archived or showcased. | Publish approved outcomes, report results and retain the audit record. |
This is a platform-wide authority, separate from being an organiser in an individual challenge.
In the current pilot, Petr Adamek is the designated platform administrator and carries a visible role tag.
Controls the global product name, subtitle, logo mark, optional square brand icon, fonts, colour defaults and reusable sponsor-ready themes. When a square icon is uploaded it replaces the text logo mark; removing it restores the mark automatically.
Can view deployment checks, live inventory, runtime boundaries and recent platform audit activity.
Challenge roles still control day-to-day challenge design and operations. Platform authority should not be used as ordinary facilitation access.
A live, read-only view of what Challenge Hub can verify about the current deployment.
The application can verify the expected configuration for that check. Independent assurance may still be required.
The capability works with a stated deployment limit, such as local storage or single-instance realtime collaboration.
A control required before responsible external production use is absent or cannot be verified.
Counts challenges, users, teams, messages, attachments, audit events and locally stored media without exposing credentials.
The same application package can now be promoted safely through local, staging and production environments.
Local permits SQLite and demo data. Staging requires PostgreSQL. Production also requires HTTPS, authentication, trusted hosts and an administrator identity.
The application refuses to start when a production profile contains unsafe defaults rather than silently falling back to a demo configuration.
Database changes are recorded in order. Readiness confirms that the running schema matches the application release.
Liveness confirms that the process is running. Readiness confirms database access, configuration and schema state before traffic is accepted.
The application runs as a non-root user, includes a health check and keeps generated data outside the packaged image.
Staging and production examples describe the required secrets, PostgreSQL connection, persistent media path and domain settings without committing credentials.
The report describes operating boundaries; it is not a security certification.
| Check | What it verifies | Production direction |
|---|---|---|
| Primary database | Whether the app is using local SQLite or PostgreSQL. | Use PostgreSQL with managed backups for an external multi-user deployment. |
| Authentication and identity | Whether secure sign-in is enforced and development sign-in paths are disabled. | Configure SMTP, disable development links, protect the session secret and review security events. |
| File and media storage | Where chat attachments and media are stored. | Use managed object storage, scanning, retention rules and signed access. |
| Realtime collaboration | Whether live chat relies on one running application instance. | Add a shared event broker before scaling across instances. |
| Automation worker | Enabled rules and pending or failed automated actions. | Use a durable queue, retries, monitoring and failure handling. |
| Production AI provider | Whether a provider is configured and challenge AI is enabled. | Retain deterministic fallback, approved-source boundaries and usage review. |
| Audit coverage | Application audit events retained in the primary database. | Add immutable retention, export, alerting and a retention schedule. |
| Backups and recovery | Whether automated backups and a tested restoration process can be verified. | Set recovery objectives and complete a restore rehearsal. |
| Privacy and deletion | Whether governed access, correction, retention and deletion workflows exist. | Complete a privacy impact assessment and data-subject workflows. |
They answer different questions and neither replaces the other.
Is this particular challenge designed and configured well enough to publish or run? It checks items such as dates, phases, governance, onboarding and judging.
Is the technical platform configured responsibly for the intended environment? It checks identity, data, recovery, privacy and infrastructure boundaries.
Begin with the decision and outcome, then design the workflow, evidence, governance and participant experience around them.
Earlier decisions should shape the options that follow.
These choices define the public frame and operating window.
Configuration is incomplete. Avoid onboarding participants against unfinished rules.
Visible and ready for registration, but challenge work may not have begun.
Teams are working through phases and producing deliverables.
Judging locks the evidence for review; completed closes the operating cycle.
All onboarding, teamwork, support and submissions happen remotely.
Combines in-person events with online workspaces and asynchronous work.
Centred on facilitated sessions, with ChallengeLab retaining the evidence record.
Record important boundaries, decision rights and human-approval requirements.
Choose the least restrictive model that still provides clarity and control.
Best for workshops and short cohorts that need common instruction.
Useful when teams progress at different speeds but need readiness checks.
Teams move among released phases. Best for experienced participants.
Teams explore early phases while facilitators control important gates.
Reduces bottlenecks; every submission remains attributable.
Creates a clear checkpoint. Ensure every team has a named lead.
The challenge sets a baseline. Teams agree their charter before accessing the workspace.
Creators retain their work, subject to the team charter and pre-existing obligations.
IP is assigned to a named company, university, consortium or other entity.
Ownership is shared. Define shares, decisions, licensing and departure arrangements.
The sponsor receives ownership. Use cautiously and obtain legal review.
Work is released under a named licence after checking every input permits it.
Use when standard models do not fit; state terms clearly and obtain advice.
| Option | Meaning | Design note |
|---|---|---|
| Challenge administration | Use work to operate, assess and archive the challenge. | Narrowest organiser licence. |
| Administration and showcase | Also permits approved communications or case studies. | Keep participant approval controls. |
| No sponsor preference | The sponsor uses ordinary commercial terms. | Cleanest open-innovation model. |
| First right to negotiate | The sponsor receives an exclusive first negotiation window. | Set a short expiry period. |
| First right of refusal | The sponsor may match a bona fide third-party offer. | Potentially restrictive; seek advice. |
Requires team approval before public display or communications.
Checks whether disclosure could damage patentability.
Flags Indigenous knowledge for appropriate authority, attribution and use.
Team private is safest; public should always be a deliberate choice.
Criteria should support the decision, not simply reward polished presentation.
Use weights to communicate genuine priorities.
Problem framing, stakeholder understanding and evidence quality.
Expected benefit, inclusion and measurable outcomes.
Technical, operational, regulatory and commercial credibility.
Ownership, risks, resources, partnerships and next steps.
Connect each deliverable to the criteria it supports.
The register is the team’s shared follow-up list. It carries important uncertainties, work and context across phases so they are not lost in chat or buried inside a deliverable.
A belief that matters but is not yet proven—for example, “customers will share property data.” Write it so evidence could validate or disprove it.
A concrete action still required, such as arranging an interview, checking a regulation or updating a test plan.
Useful context, an emerging decision, a question to revisit or information the whole team should retain.
Use team-wide for items that persist throughout the challenge. Link an item to a phase when it is mainly relevant to that stage.
Assign an owner when action is required. High priority should identify work that blocks evidence, progress or submission.
Tasks move from open to in progress or done. Assumptions should be marked validated or invalidated when evidence changes the team’s view.
A phase is a period of work. A deliverable is the evidence produced during it.
Explain the decision or learning goal for the phase.
Tell teams what to do, applicable boundaries and where help is available.
Must be answered before submission. Use only for essential evidence.
Useful supporting material that should not block progress.
Available according to the challenge’s progression model.
Locked prevents work; completed preserves submitted evidence.
AI personas are simulations for coaching and structured challenge—not substitutes for real customers, experts or judges.
Prompts reflection and planning without doing the team’s work.
Helps rehearse questions; insights still need real-world validation.
Provides bounded guidance from approved sources and acknowledges gaps.
Structures assessment but cannot select winners or make final decisions.
This is the first role-help release. Later versions can add contextual guidance to each workspace.
Owns challenge design, governance and final operating authority.
Runs the participant experience and keeps teams progressing fairly.
Contributes to team work, evidence and deliverables.
Coordinates the team and may hold submission authority.
Provides bounded advice without owning the team’s decision.
Assesses submitted evidence against published criteria.
Team Chat stays available beside deliverables so online teams can communicate without leaving the phase workspace.
Keeps the shared conversation visible while leaving space for deliverable work.
Reduces chat to an unread-count rail when the team needs maximum working space.
Provides more room for workshops, detailed discussion and AI-persona sessions.
Switch between the continuous shared history and messages linked to the phase being viewed.