UKA Tarsadia University Students: Documenting Data Sources and Assumptions in Analytics Work

Document every data source and every assumption the moment you use them: keep a data dictionary that describes each field and an assumptions log that records each judgement call, who made it, and what would change it. Done daily, this takes about 15 minutes and means anyone can reuse your analysis after your internship ends, including a faculty guide or jury reading your report.

This guide is written for UKA Tarsadia University (UTU) students and is an independent resource. It gives you both templates in full, a 14-day schedule built around a two-week online internship, a worked illustrative example, and a section on how UTU’s published internship guidelines affect what you document.

Why undocumented analytics work fails at handover

Most analytics handovers fail for ordinary reasons, not technical ones. The notebook runs, the chart looks fine, but nobody knows what the numbers mean. Typical failures:

• Unknown origin. A CSV named final_v3.csv with no record of who supplied it, when, or from which system.
• Silent filters. Rows were dropped for being “outliers” or having blanks, but the rule was never written down, so totals cannot be reproduced.
• Ambiguous fields. A column called amount could be gross or net, in rupees or thousands, with or without GST.
• Hidden assumptions. Missing values were filled with the median, dates were read as day-first, duplicates were defined by phone number. None of it is visible to the next person.
• Lost context. The reader does not know which question the analysis was meant to answer, so they cannot judge whether it still applies.

A data dictionary solves the first, third and fifth problems. An assumptions log solves the second and fourth. Together they are the shortest route to work that survives your departure.

Data dictionary template for a student analytics project

Create one row per field in each dataset you use. Keep it in a spreadsheet or a Markdown file next to your code. Copy this structure:

The rows above are illustrative placeholders, not real data. Also add a header block at the top of every dictionary:

• Dataset name and file name exactly as received.
• Provider (person, team or public portal) and the date you received it.
• Licence or usage permission, or “not stated” if you were not told.
• Extraction method (export, API, scraped, shared drive) and the time period covered.
• Row count on arrival and a checksum or file size so changes can be detected.
• Sensitivity: whether it holds personal data, and whether you may share it outside the host organisation.

Assumptions log template with owner and impact columns

Log an assumption whenever you choose between two reasonable interpretations. If you hesitate for even a moment, it belongs in the log.

Status values to use: Open, Confirmed, Accepted risk, Rejected. At the end of the internship, every open item must either be resolved or listed in your handover note as unresolved.

What a good assumption entry looks like

• It is a full sentence a stranger could test against the data.
• It names a basis, even if the basis is only “my own judgement”.
• It states what would change in the results if the assumption turned out false.
• It has a named person who can confirm it.

A 14-day documentation plan for a two-week analytics internship

A short internship leaves no room for documenting at the end. Spread it out. If you join the free two-week online internship from CareerSwami, which includes an offer letter and a completion certificate after successful completion, this schedule fits its 14-day length.

Worked illustration: handing over a retail sales analysis

This example is illustrative. It does not describe a real project and no code was run for it.

Suppose a student analyses monthly sales for a small online retailer. On day 1 they receive sales_export.csv from a mentor. Their dictionary header records: provider (mentor), received date, “licence not stated”, covers April to September, 12,400 rows on arrival.

On day 3 they notice 310 rows with zero value. Without documentation, they quietly delete them. With documentation, they add assumption A3 (“zero-value rows are test orders”), note the count removed, and flag it for the mentor. On day 8 the mentor replies that zero-value rows are actually free sample shipments. The student reverses the rule, updates the log (status: Confirmed, rule changed), and records that earlier charts were regenerated.

Now compare the handover:

• Without logs: The next analyst sees revenue and order counts that do not match the finance report, cannot tell why, and discards the work.
• With logs: The next analyst reads that 310 free-sample rows are included in order counts but not revenue, sees who confirmed it and when, and can reproduce the numbers in an afternoon.

The difference was about ten minutes of writing on day 3 and five on day 8.

Metric definitions: the part of documentation people skip

Fields and assumptions are not enough. Add a short metric sheet, because two analysts can compute “conversion rate” differently and both be reasonable.

UTU students: documenting data work around the university’s internship guidelines

UTU’s published internship guidance has direct consequences for documentation, but you should read it carefully because of its scope. The relevant document is a Board of Studies summer internship resolution from 2018. It covers B.Tech programmes (with a parallel rule for diplomas) and sets a 5-8 week internship after semester 6, worth 3 credits and 100 marks. A 14-day online internship is shorter than that window, and the document says nothing about online internships, so do not assume a two-week programme satisfies it. Also note that the guidelines say paid internships will not be entertained and family-owned companies are not allowed. No rules were found for BCA, B.Sc, MCA, MBA or other programmes, so students outside engineering need written guidance from their own department.

Where the guidelines apply to you, the documentation habits above map neatly onto what is required. Students must submit a detailed report and present it to a departmental jury, and each student or group gets an internal faculty guide. A report with a clear data section, a dictionary appendix and an assumptions log gives the jury and guide something concrete to question. The guidelines also require an offer letter on the host’s letterhead and a signed, stamped completion certificate, so keep those documents alongside your project files. Because the guidelines are from 2018, check the current version before relying on them. The placement cell also runs its own site with process and policy pages, which are worth reading for current requirements.

Verification steps for UTU students before you start

1. Ask your department head or faculty coordinator in writing whether a 14-day online internship counts toward any credit, marks or requirement for your programme, and keep the reply.
2. Request the current internship or training scheme for your specific course and batch, and compare it with the 2018 document.
3. Ask your faculty guide what the report must contain and whether a data dictionary or assumptions appendix is welcome in the format.
4. Check with the host or mentor whether the data may be shown to a jury or included in a report, and whether it must be anonymised.
5. Browse the placement cell’s official page for current policy documents and note any that apply to you.
6. Confirm the format and signatories needed for the offer letter and completion certificate before the internship begins.

Handover note template for the last day of your internship

Write this on day 14 as a single page. Use these headings:

1. Purpose: the question the work answers, in one or two sentences.
2. Deliverables: file names, locations and versions.
3. Data used: dataset names, providers, dates received, link to the dictionary.
4. How to reproduce: the order in which to run files, software versions, required packages.
5. Key assumptions: the top three by impact, with IDs from the log.
6. Open items: unresolved assumptions and who might answer them.
7. Known limitations: what the analysis cannot support.
8. Contact: how the reader can reach you with questions, if you are willing.

Self-check scorecard for your documentation

Score each line 0 (absent), 1 (partial) or 2 (complete). A total below 20 out of 28 suggests a stranger would struggle.

Habits that keep documentation honest and short

• Write at the moment of decision. Memory of why you filtered a column fades within a day.
• Prefer counts to adjectives. “Removed 310 rows” beats “removed a few bad rows”.
• Separate fact from guess. Mark which dictionary entries came from a provider and which you inferred.
• Never overwrite raw files. Save cleaned outputs under new names.
• Keep the log in one place. Scattered notes across chats and notebooks defeat the purpose.
• Respect confidentiality. Do not paste real customer data into public repositories or portfolios without permission.

Using your documentation in a portfolio or interview

Your dictionary and log are evidence of analytical discipline. In a portfolio, use a public or synthetic dataset, or an anonymised version approved by the host, and include a short “Data and assumptions” page. In interviews, describe one assumption you logged, what it risked, and how you resolved it. That answer is more convincing than listing tools, because it shows you understand that results depend on choices.

Frequently Asked Questions

What is the difference between a data dictionary and an assumptions log?

A data dictionary describes what the data is: fields, types, units, allowed values and source. An assumptions log records what you decided where the data or brief was unclear. The first describes the material, the second describes your judgement.

How long should these documents be?

As long as needed to make the work reproducible, usually one dictionary row per field used and a handful to a few dozen assumptions in a short project. A two-week internship rarely needs more than a few pages in total.

Do I need to document fields I did not use?

Briefly. List them with the note “not used” and, if you know why, a reason. This tells the next person you saw them and did not overlook them.

Which tool should I keep these in?

Any shared, versioned format works: a spreadsheet with separate tabs, a Markdown file beside your code, or a notebook section. Choose what your mentor can open easily and keep one master copy.

Can I include the host’s real data in my UTU report?

Do not assume you can. Ask the host in writing what may be shown, whether values must be masked, and whether the jury may see it. Also ask your faculty guide what the department expects.

Does a 14-day online internship satisfy UTU’s internship requirement?

UTU’s 2018 guidelines for B.Tech describe a 5-8 week internship and do not mention online internships, so a 14-day programme should not be assumed to qualify. Ask your department in writing. CareerSwami’s programme offers a free offer letter and a free completion certificate after successful completion, but it does not promise academic credit.

What should I do with assumptions my mentor never answers?

Keep them as Open, state the impact if wrong, and list them in the handover note. Do not quietly promote them to facts. Sending one consolidated question list around day 8 improves your chance of a reply.

How do I know my documentation is good enough?

Run the reproducibility check: wait a day, then try to rebuild one headline number from raw data using only your notes. If you get stuck, the gap you hit is exactly what to add.

Related Data Analytics guides

• Cotton University Students: Data Analytics Internship Ideas for Science and Arts Majors
• Kachchh University Students: Using Local Economic and Weather Data for an Analytics Project
• University of North Bengal Students: Analysing Tea and Tourism Data in a Short Internship
• All Data Analytics internship guides