Project Submission & Assessment Policy

The purpose of this policy is to make assessment transparent, consistent and fair. It applies to:

• every student taking part in a Gradopus Labs program;
• every task, submission and review in those programs;
• the reviewers and mentors who assess work on behalf of Gradopus Labs.

Each task brief may add task-specific requirements. A task brief can make requirements more specific, but it cannot remove a protection this policy gives you.

• Assignment (or task): a piece of work set in a program, with a brief, submission requirements and acceptance criteria.
• Task brief: the written instructions for an assignment, shown with the task.
• Deliverable: what the task brief asks you to produce, such as working code, a deployed application or documentation.
• Submission: what you send for review in response to a task, such as a text answer or a project link. Each time you submit, a new attempt is recorded.
• Reviewer: a person who assesses submissions on behalf of Gradopus Labs. A reviewer may also be your mentor.
• Revision: a new attempt that you submit after a reviewer requests changes or rejects a submission.
• Required task: a task that must be completed to complete the program. Optional tasks never affect completion.
• Completion: meeting all of the completion requirements published for a program (section 22).

• Tasks are organised into modules within each program and are shown in your student dashboard once you are enrolled.
• Each task shows its brief, what to submit, its acceptance criteria, whether it is required or optional, and its deadline, if it has one.
• If a task is changed after you have started it, we will tell you, and the change will not be applied to a submission you have already made without your agreement.
• Ask your mentor or reviewer if anything in a brief is unclear. Asking for clarification is never held against you. To be confirmed: the channel for task questions

Every task brief will state, before you start:

• what you are expected to build or do, and what you should learn from it;
• the submission method (section 7) and which evidence is required;
• the acceptance criteria your work will be assessed against;
• whether the task is required or optional;
• any rules on AI tools (section 13) and third-party code (section 14);
• whether the task's work may be published publicly (section 24);
• its deadline, if any (section 6).

You will be assessed only against the criteria published for the task and the completion requirements of your program. A reviewer will not reject your work for failing a requirement that was not stated.

These apply to every submission:

• It must be your own work, with honest attribution (sections 12 to 14).
• It must not contain passwords, API keys, tokens, other secrets or other people's personal data (section 15).
• Any link must open securely (https://) and be accessible to the reviewer until the review is complete.

These apply only when a task brief asks for them:

• a GitHub repository (section 8);
• a live deployment or demonstration (section 9);
• a README or setup instructions (section 10);
• screenshots, recordings, progress reports or written explanations (section 11).

• A task may have a deadline, shown with the task. Some programs may also set milestones, which will be stated in the internship details. To be confirmed: whether programs use milestones
• Deadlines are set so that the work can reasonably be completed within the time commitment published for the program.
• Late submissions are still reviewed, and the reviewer can see when the work was submitted. To be confirmed: whether lateness affects the assessment of any task, and any grace period
• Extensions: if you need more time for a genuine reason, such as illness, a family emergency, examinations or a disability-related need, ask before the deadline where you can. Reasonable requests will be considered fairly and answered in writing.
• Missing a deadline is never, on its own, treated as misconduct.

The website currently accepts two kinds of submission:

• Text answers, up to 10,000 characters, for example a written explanation or a progress report;
• Project links starting with https://, for example a GitHub repository or a live deployment URL.

File uploads are not available on the website. If a task needs screenshots, a recording or a document, the task brief will say how to provide it, for example by including it in your repository or sharing a link to it.

The website never opens or downloads the links you submit. Reviewers open them in their own browsers.

When a task asks for a repository:

• Submit the repository URL only when the task asks for it.
• A private repository is acceptable. Give the reviewer access as the task brief explains, for example by inviting the reviewer's account as a collaborator with read access. You do not have to make work public to have it reviewed. To be confirmed: the reviewer account to invite
• Grant only the access needed for the review, and remove it after the review if you wish.
• Never share your GitHub password, personal access tokens or other credentials. Gradopus Labs will never ask for them.
• Your commit history helps show your own contribution. Do not rewrite or delete history after submitting until the review is complete, unless you need to remove a secret and you tell your reviewer.
• The repository must not contain secrets or confidential data (section 15).
• Do not upload code that belongs to an employer, client, college or anyone else unless you are authorised to.
• Follow the licences of any code you include (section 14).

When a task asks for a live deployment or a demonstration:

• Submit the deployment URL only when the task asks for it, and keep it working until the review is complete.
• A live deployment is evidence that the application works. It is not, by itself, proof of authorship or originality.
• You may be asked to explain your code or demonstrate features in a short, reasonable review, for example a call or a recorded walkthrough. This helps the reviewer assess your understanding and your own contribution. To be confirmed: how demonstrations are held, e.g. live call or recording
• Use only free or approved hosting. Do not use paid services in the name of Gradopus Labs without written permission.
• Do not put real personal data into a deployed task project unless the task requires it.

When a task asks for documentation, a README should usually explain:

• what the project does;
• how to install, configure and run it, including any environment variables, but never their real secret values;
• how to run any tests;
• the main technical decisions and any known limitations;
• the third-party code, templates and AI assistance you used, where the task asks for it.

• Provide screenshots, recordings, progress reports or explanations only when the task asks for them.
• Make sure they do not show passwords, tokens, private messages, other people's personal information or anything confidential.
• Evidence must be genuine. Edited or staged evidence that misrepresents what your work does is falsified evidence (section 20).

• Your submission must show your own work and understanding.
• Credit any code, tutorials, articles, templates, datasets or other material you used, in the way the task asks and as the material's licence requires.
• In group tasks, each member must be able to show their own contribution.
• Using properly credited material is not plagiarism. Presenting someone else's work as your own is.

Using AI tools is not automatically misconduct. The rules are:

1. Follow the task brief. Each task states whether AI tools may be used and how. Where a brief allows AI assistance, you may use it within those limits. Where a brief does not allow it, you must not. To be confirmed: the default rule when a task brief says nothing about AI tools
2. Disclose your use in the way the task asks, for example a short note in your README saying which tool you used and for what.
3. Understand what you submit. You must be able to explain, test and change any code you submit, including generated code.
4. Represent your contribution honestly. Submitting AI-generated work as your own where the task does not allow it, or without disclosing it, is misrepresentation.

You will never be asked to share your AI-tool account, its password or your private chat history. If a reviewer needs to understand how you used a tool, they may ask you to explain it.

The website does not use automated AI-detection or plagiarism-detection software. If Gradopus Labs uses any such tool, it will be checked for reliability before use, and its result will never on its own be treated as proof of misconduct. To be confirmed: whether reviewers will use any detection tools

• You may use libraries, frameworks, templates and other third-party components unless the task brief says otherwise.
• Use them only as their licence allows, and keep the licence and copyright notices the licence requires.
• Credit them as the task asks, for example in your README.
• Do not use code you do not have the right to use, such as leaked, pirated or confidential code.
• Using a template or starter project is allowed only where the task permits it. Your submission must make clear which parts you wrote.

• Never include passwords, API keys, private tokens, private certificates or other secrets in a submission, repository, deployment, screenshot or recording. Use environment variables or a local file that is not committed.
• If you commit a secret by mistake, tell your reviewer immediately and change the secret. Removing it from the latest commit is not enough, because it remains in the history.
• Do not include other people's personal data unless the task requires it, and then only what is needed.
• Confidential material from Gradopus Labs or a client must not be published (see the Intellectual Property & Code of Conduct).

• Each task is assessed against its own published acceptance criteria. There is no universal passing score.
• A reviewer records one of three outcomes:
  • Accepted: the submission meets the task's criteria;
  • Changes requested: it needs specific improvements, which the feedback explains;
  • Rejected: it does not meet the criteria, for example because it is incomplete, inaccessible or not your own work.
• A reviewer may also record a score out of 100 for a task. Scores give you feedback; unless the task brief says so, a score does not decide whether a task is accepted. To be confirmed: whether scores are used, and whether any task uses a minimum score
• The same criteria apply to every student on the same task.

A task's criteria may cover some or all of the following, as stated in the brief:

• Correctness and functionality: the work does what the task asks.
• Code quality: readable, organised and maintainable code.
• Documentation: clear setup and usage instructions.
• Accessibility: for user interfaces, whether people with disabilities can use them, where the task asks.
• Security: no exposed secrets and sensible handling of input and data, where relevant.
• Originality and attribution: honest representation of your own work.
• Understanding: your ability to explain your implementation and decisions.

A task is never assessed on an aspect it does not mention.

• Every "Changes requested" or "Rejected" outcome comes with written feedback explaining why and, where possible, what to improve.
• After "Changes requested" or "Rejected", you may submit a revision. Earlier attempts and their feedback are kept and shown to you and the reviewer.
• The website allows up to 10 attempts per task. A task brief may set a lower limit, which will be shown with the task. To be confirmed: whether any task sets a lower limit
• While a submission is waiting for review, you cannot submit another attempt for that task. Once a submission is accepted, the task is complete and no further attempts are needed.
• Reviewers aim to review submissions promptly. To be confirmed: expected review time
• A reviewer may correct the written feedback or score after a decision; you will be able to see the updated feedback.

• Incomplete work is usually given "Changes requested" with feedback, so you can finish it.
• Late work is still reviewed (section 6).
• Inaccessible work (for example a broken link or a private repository the reviewer cannot open) cannot be accepted. The reviewer will request changes and explain what is needed, so you can fix access and resubmit.
• Rejected work can be revised and resubmitted, within the attempt limit.
• If you reach the attempt limit for a required task without an accepted submission, contact your reviewer. The case will be reviewed individually. To be confirmed: what happens when the attempt limit is reached

The following are academic misconduct:

• copying another person's work, including another student's, and presenting it as your own;
• submitting work written for you by someone else, paid or unpaid;
• sharing your solutions so that others can submit them as their own, unless the task allows it;
• falsifying evidence, such as commit history, screenshots, recordings, deployment URLs or demonstrations;
• submitting AI-generated work where the task does not allow it, or without the disclosure the task requires.

How concerns are handled:

1. The reviewer tells you, in writing, what the concern is and the evidence for it.
2. You have a fair opportunity to respond, for example by explaining your work or showing your process.
3. A decision is made and explained to you in writing.

Honest mistakes, such as a missing credit, are treated differently from deliberate or repeated misconduct. They will usually lead to guidance and a request to correct the submission.

Possible outcomes include a request to correct or redo the task, a rejected submission or, for serious or repeated misconduct, the steps in the Student Terms & Conditions. There are no fines. A certificate obtained through misconduct may be revoked, but only through the process in the Certificate Issuance & Verification Policy.

If you think a review outcome is wrong or unfair:

1. Ask your reviewer first to explain the decision, if you are comfortable doing so.
2. Request a reassessment in writing to support.gradopuslabs@gmail.com within To be confirmed: number of days of the decision. Say which task it is, which criteria you think were applied wrongly, and why.
3. Where possible, the reassessment is carried out by someone who did not make the original decision.
4. You will receive a written outcome with reasons. If the reassessment finds that your submission met the criteria, the outcome will be corrected in our records. To be confirmed: response time

Requesting a reassessment will never count against you. If you are still not satisfied, you can raise a grievance (section 25).

You complete a program when you meet all of its published completion requirements:

1. every required task has an accepted review or, for a non-assessed activity such as a reading module, is marked as done in the way the task describes; and
2. any other requirement stated in the program's internship details. To be confirmed: any additional completion requirements per program

• Project submissions count towards completion only once accepted. Submitting a link does not by itself complete a task.
• Optional tasks never affect completion.
• Paying the enrolment fee pays for taking part in the program. It does not mean your work will be accepted or that you will receive a certificate.
• Not every student completes every program, and a certificate is issued only when the completion requirements are met. There is no fee for a certificate.

Certificate issuance is explained in the Certificate Issuance & Verification Policy.

• Your submissions, attempts, feedback and review outcomes are stored so that you and the reviewers can see the history of your work, and so that completion and certificates can be checked later.
• Only you and the Gradopus Labs team can see your submissions. They are not made public by Gradopus Labs.
• How long submissions are kept, and how you can ask for them to be deleted, is explained in the Privacy Policy. Submissions are currently kept with no automatic deletion. To be confirmed: retention period for submissions

• Submitting work for review does not transfer ownership of it to Gradopus Labs. It gives Gradopus Labs permission to store, access, review and assess the work and keep a record of it, only for running the program, verifying completion and certificates, handling disputes and keeping records the law requires.
• Who owns work created in a program is explained in the Intellectual Property & Code of Conduct.
• Each task brief states whether you may publish the work publicly, for example in a public repository or portfolio. Work that includes confidential or client material must not be published without written permission.
• Gradopus Labs will not use your work, name, photograph or testimonial in promotional material without your separate, written permission. Refusing will not affect your assessment or certificate.

If your concern is not resolved through a reassessment, you can raise a formal grievance as described in the Student Terms & Conditions, by writing to support.gradopuslabs@gmail.com. You will not be penalised for raising a genuine concern.

We may update this policy. The current version is always published with its version number and effective date. Changes will not apply retrospectively to work already submitted or reviewed, and will not make the completion requirements of a program you have already joined harder to meet without your agreement.

Related policies:

• Internship Policy
• Student Terms & Conditions
• Privacy Policy
• Certificate Issuance & Verification Policy
• Payment, Refund & Stipend Policy
• Intellectual Property & Code of Conduct

• Version 1.1, 23 October 2026: Added the operator's location and the official support email address (support.gradopuslabs@gmail.com). Effective date still to be set after legal review.
• Version 1.0, 21 October 2026: First published version. Effective date to be set after legal review.