AI Internship Portfolio Evidence for GTU Students: GitHub, Model Cards and Experiment Logs

Strong AI internship evidence is a public GitHub repository that lets a stranger understand, rerun and question your work in ten minutes. It needs four things: a clear repository structure, a model card, an experiment log and a one-page metrics summary. This guide gives you a template for each, written for students of Gujarat Technological University (GTU).

Why evidence matters more than the certificate

A certificate says you finished something. A portfolio shows what you did. When a recruiter, a faculty reviewer or a senior opens your link, they look for signs that you understand the problem, can separate training data from test data, and can say honestly where your model fails. Many student AI repositories contain only a notebook named Untitled3.ipynb and a screenshot of 98% accuracy. That tells a reviewer almost nothing.

The four artefacts below fix that. They are also cheap to produce if you create them while you work, not in the last evening before submission.

GTU’s affiliating structure and where an AI portfolio fits in an internship or project

GTU describes itself, on its Integrated Training & Placement (I-TAP) site, as a state university set up by the Government of Gujarat under Gujarat Act No. 20 of 2007. The same page says it has 400+ affiliated colleges served through five zones. Another college-hosted copy of a GTU “about” text gives different counts, so treat any single figure with caution. For a student, the point is that the university sets the framework while the day-to-day handling of internships and projects usually happens through your own college and guide.

For BE students, a 2022 Semester VIII “Internship/Project” course document (code 3180901), hosted on an affiliated college’s site, states that the internship is full time for its whole duration and that the student may submit a brief proposal of the work to be carried out. In practice, that proposal is a natural place to state your AI task, dataset and planned metrics, and the repository, model card and experiment log in this article can later show what was actually done. The document is an older copy, so check the current version with your department.

For MBA students working on analytics or AI-related projects, a GTU-headed Summer Internship cum Project work (SIP) document, hosted on an affiliated college’s site, says the SIP carries 200 marks and 4 credits and is done in one organization after a semester. A short, online-only AI exercise may therefore not map neatly onto it, so ask before assuming it counts.

The I-TAP page also says GTU set up Integrated Training & Placement Cell wings to help affiliated institutes with employability. Management students can also look at the GSMS Training and Placement Cell, which describes soft-skills and interview-skills sessions. These are places to ask for portfolio review, not guarantees of any outcome.

No portfolio format is shown as mandated here. Use this template as a public layer beside whatever report your college requires.

Checks before you publish your AI work

• Ask for the current internship/project course document for your branch and scheme, and compare it with the 2022 Semester VIII copy mentioned above.
• Ask your internal guide in writing whether a self-arranged online AI internship can be reported under the internship or project component, and in what form.
• Request the report template or a previously approved sample from your department coordinator.
• Get written permission before pushing any company, lab or guide-supplied data or code to GitHub.
• Confirm who countersigns: internal guide, external mentor, or your college’s training and placement cell.
• Check your college’s rules on reused code and AI-generated text before linking the repository in a submission.

The evidence pack at a glance

Use this table as your scorecard. If every row is complete, your portfolio is in good shape.

Part 1: GitHub repository structure

Keep one repository per project. Do not dump everything into a single repo called “internship”. A clean layout looks like this:

project-name/
├── README.md
├── requirements.txt        (or environment.yml)
├── LICENSE
├── data/
│   ├── README.md           (source, licence, how to download)
│   └── sample/             (tiny sample only, never the full private data)
├── notebooks/
│   └── 01_eda.ipynb
├── src/
│   ├── data.py
│   ├── train.py
│   └── evaluate.py
├── experiments/
│   └── log.md
├── docs/
│   ├── MODEL_CARD.md
│   └── METRICS.md
└── outputs/
    ├── figures/
    └── confusion_matrix.png

What the README must contain

1. One-sentence problem statement. Example: “Classify customer support tickets into five categories.”
2. Result in one line. State the metric and the dataset split it was measured on.
3. How to run. Three to five commands, in order.
4. Data note. Where the data came from and its licence.
5. Links to the model card, experiment log and metrics summary.
6. Internship context. Name the programme, the dates and your role in a sentence.

Repository habits that reviewers notice

• Commit small and often, with messages that say what changed (“add stratified split”, not “update”).
• Pin a random seed and write it down.
• Never commit API keys, passwords or personal data. Use a .gitignore and environment variables.
• Clear notebook outputs that contain private information before pushing.
• Do not commit large model weights; link to them or describe how to regenerate them.

Part 2: The model card template

A model card is a short document that describes what a model is for, how it was built and where it should not be used. Copy the headings below into docs/MODEL_CARD.md and fill each one in plain language.

The limitations section is the one reviewers read first. Be specific: if you saw the model fail on a type of input, say so. That honesty builds more trust than a high score.

Part 3: The experiment log template

An experiment log records every run you try. It protects you from the most common student mistake: tuning against the test set and then reporting the best number as if it were a first attempt. Keep it as a Markdown table or a CSV that you update after each run.

Rules for a useful log

• Log failed runs too. A rejected idea with a reason is evidence of method.
• Change one thing at a time, or note clearly that you changed several.
• Record the seed, data version and library versions for every run.
• Use the validation set for decisions. Touch the test set once, at the end.
• Write the observation in words, not only numbers.

Part 4: The metrics summary

This is a one-page file, docs/METRICS.md, that a hiring manager can scan in under a minute. It should contain:

1. Task and metric choice. One sentence on why this metric fits the problem.
2. Baseline versus final. A small table, as shown below.
3. Per-class or per-segment results. Averages hide weak groups.
4. Error analysis. Five to ten misclassified examples with a guess at why.
5. Caveats. Dataset size, possible leakage, anything that limits the claim.

Worked example: AI internship portfolio evidence (illustrative)

The example below is invented to show how the pieces fit together. It is not a real project, and no code or results here were run or measured. Numbers are placeholders.

Project: a text classifier that sorts short support messages into “billing”, “technical”, “account” and “other”.

1. README line: “Classifies support messages into four categories; macro-F1 reported on a held-out test split. See docs for limits.”
2. Data note: “Public dataset; licence checked; only a 50-row sample is included in data/sample/.”
3. Experiment log excerpt: E01 majority baseline; E02 TF-IDF with a linear classifier; E03 class weights added after the per-class table showed “other” being missed; E04 larger n-grams rejected because validation did not improve.
4. Model card limitation: “Very short messages with no keywords are often labelled ‘other’. Mixed-language text was not tested.”
5. Metrics summary error analysis: eight misclassified messages pasted in a table with a one-line reason each, for example “ambiguous between billing and account”.

A reviewer reading this learns that the student chose a metric on purpose, compared against a baseline, found a weakness, acted on it and was open about what remains untested. That is the whole point.

Where the internship fits

If you do a short online internship, document it as a time-boxed project. CareerSwami runs a free two-week online internship with 26 tracks, a free offer letter and a free completion certificate after successful completion. Whichever programme you join, reference the offer letter and certificate in your README footer and keep the work itself as the main evidence. Do not describe the programme as paid, credit-bearing or a route to a job; state only what it actually provides.

A 14-day documentation plan

Final self-check before you share the link

• Can someone clone the repo and follow the README without messaging you?
• Is every number in the README traceable to a log entry or metrics file?
• Did you evaluate on data the model never saw during tuning?
• Does the model card name at least two real limitations?
• Are secrets, personal data and restricted files absent from the history?
• Is your name, date and the internship context stated?

Frequently Asked Questions

Do GTU students have to submit a GitHub portfolio?

Do not assume so. Requirements depend on your programme, college and guide. Ask your department coordinator what documentation is required for the internship or project, and get the answer in writing. Use GitHub as a public supplement either way.

Is a model card necessary for a small student project?

It is not a formal requirement for small projects, but a half-page card is quick to write and shows that you understand limits and responsible use. It often distinguishes your repository from a plain notebook upload.

What if my project uses private or company data?

Do not upload it. Publish a tiny synthetic or public sample, describe the real data in words, and get written permission from the data owner before sharing any outputs.

How many experiments should the log show?

Quality matters more than count. Four to eight well-explained runs, including rejected ones, are more convincing than thirty unlabelled runs.

Which evaluation metric should I report in my AI internship model card and metrics summary?

Choose it from the problem. For imbalanced classification, report macro-F1 or per-class recall alongside accuracy. For regression, report MAE or RMSE with a naive baseline. Always explain the choice in one sentence.

Can I use pretrained models or AI coding assistants?

Often yes, but state it. Name the pretrained model, its licence and what you changed. Check your college’s rules on AI-assisted work, and be able to explain every line you submit.

Should the repository be public or private?

Public is better for recruiters, provided there is no restricted data or credentials. If your college asks for private submission, share a private invite with your guide and make a cleaned public version later.

Does a completed internship certificate count for academic credit?

That is decided by your college, not by the internship provider. Ask your internship coordinator whether the certificate can be accepted for any curriculum requirement, and keep their reply on record.

Related Artificial Intelligence guides

• AI Internship Interview Preparation for Savitribai Phule Pune University Students
• Comparing AI Internship Subfields for University of Mumbai Students: ML, NLP and Vision
• Selecting an AI Internship Project as a JNTUH Student: Scope, Data and Evaluation
• All Artificial Intelligence internship guides