Find guidance for challenge work, collaboration, governance and platform administration. Options appear according to your account role and the challenge you have selected.
ChallengeLab 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. Connect an approved external malware scanner where organisational policy requires it.
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.
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.
Development-only access tools are disabled in the hosted service and isolated from live accounts and data.
Your workspace changes according to your role, challenge membership and selected challenge.
Your signed-in identity appears in the top bar. Access is controlled by secure email sign-in and your assigned roles.
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. |
Platform administration is a small, high-trust group with authority across the whole service. It is separate from being an organiser in an individual challenge.
Open Platform → Administrators, enter the person’s name and email, then send the secure single-use invitation. It expires after seven days.
Administrators control the global product name, subtitle, logo mark, optional square brand icon, fonts, colour defaults and reusable sponsor-ready themes.
Administrators can manage accounts and sessions, data protection, deployment checks, live inventory and platform audit activity.
Challenge roles still control day-to-day design and operations. Grant the appropriate challenge role separately when an administrator also works on a challenge.
A live, read-only view of the service controls and documented operating limits.
The application can verify the expected configuration for that check. Independent assurance may still be required.
The capability is operational with a documented limit, such as host storage or single-instance realtime collaboration.
A control needs attention and the report provides the next accountable action.
Counts challenges, users, teams, messages, attachments, audit events and locally stored media without exposing credentials.
ChallengeLab uses separated development, staging and live deployment profiles.
The hosted service requires PostgreSQL, HTTPS, authentication, trusted hosts and an administrator identity.
The application refuses to start when a hosted profile contains unsafe defaults rather than silently falling back to development 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.
Deployment examples describe 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.
Are the technical controls appropriate for current operation? 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.
Chat stays available across the platform in a collapsible right pane. Its room selector keeps platform-wide staff coordination separate from challenge and team conversations.
Platform administrators, active organisers and active facilitators can coordinate across all challenges. Messages can target all platform staff, administrators, organisers or facilitators.
Select a team, audience and optional phase or agenda context. Team conversations remain isolated from the platform-wide room and from other teams.
Keeps the shared conversation visible while leaving space for the page you are using.
Collapse chat for maximum working space and unread notifications, or expand it for detailed discussion and attachments.
Filter platform messages by staff role or challenge messages by sender and context, while retaining one persistent history in each room.
Reply within the selected room and share governed files using expiring download links.