Final submission

The final submission is the deliverable you produced for the challenge. It's what your reviewers evaluate, and it's the thing your credential is anchored to.

Treat this page as the checklist you run before you click submit.

What you submit

Every challenge brief states the expected deliverable format. Common formats:

• Slide deck (PDF) — typical for strategy, market analysis, GTM, and creative briefs.
• Written report (PDF or Markdown) — typical for research, policy, scientific writing.
• Code repository (Git URL with README) — typical for software, ML, data engineering.
• Design artefact (Figma link, image set, or CAD file) — typical for product, UX, hardware.
• Mixed — a deck + a working prototype, or a report + supporting data.

If the brief says "10-page deck max," respect the limit. Reviewers stop reading at the stated cap; padding past it doesn't help.

What reviewers look at

Reviewers work from the rubric stated in the challenge brief. There is no hidden rubric — what's published is what gets scored.

The patterns that show up most often:

1. Problem framing

Did you understand the real question? Many submissions answer the surface question and miss the actual one. The strongest submissions open by restating the problem in their own words — that restatement alone tells a reviewer a lot.

2. Structure

Reviewers read submissions linearly. A submission with a clear arc — problem → approach → key findings → recommendation → caveats — outperforms one that buries the conclusion on slide fourteen.

3. Evidence-to-claim ratio

Every claim should be backed by something — data, analysis, source, reasoning. Submissions that read as opinion without scaffolding rarely land, regardless of how confident the prose sounds.

4. Honesty about limitations

Strong submissions name what they don't know. Working professionals call this epistemic humility. Reviewers notice it. Submissions that pretend total certainty come across as junior.

5. Craft

Spelling, grammar, layout, design polish. Not the main thing — but consistent sloppiness drags down strong work. Run a final pass.

What gets you a "needs revision"

A submission can come back for revision rather than acceptance. The usual reasons:

• The submission ignored a stated constraint (e.g. "under 10 pages," "include a cost estimate," "use the provided dataset").
• The deliverable is in the wrong format for the brief.
• Critical reasoning steps are missing — the reviewer can't follow how you got from problem to conclusion.
• Significant factual errors that would mislead someone acting on the submission.

A revision request is not a rejection. It's a specific list of things to fix. Most revised submissions are accepted on the next round.

What gets you a "not accepted"

A non-acceptance is rare and tends to require multiple compounding issues — for example, a submission that ignores the rubric and doesn't engage with the brief and has critical factual errors. We tell you the specific reasons.

You can attempt the challenge again, treating the first attempt as the world's most thorough learning experience.

Timeline

The standard timeline from submission to credential is:

1. Submission lands. You get a receipt.
2. Reviewer assigned — usually within 2–5 business days.
3. Review completed — within 5–10 business days of assignment for most challenges (longer for capstone-style work).
4. Decision — accepted / revision requested / not accepted, with written rationale.
5. Credential issued — typically within 24 hours of acceptance.

Capstone-style and team challenges sit at the longer end of those ranges.

The credential is the next step

When your submission is accepted, Ewance issues your verifiable credential — anchored on a public blockchain so it can be confirmed without trusting Ewance. The mechanics are covered in detail on the next page: Certificates.