Keshav Bhardwaj

`cv.json` Documentation

Overview

cv.json is the canonical, public, machine-readable source of truth for Keshav Bhardwaj’s professional CV.

Canonical location:

/assets/api/json/cv.json

Canonical URL:

https://keshavbhardwaj.in/assets/api/json/cv.json

The file is designed to be consumed by:

the public /cv/ page;
the generated CV PDF;
Schema.org / structured-data generation;
other machine-readable applications;
future website features that require structured CV data.

The JSON contains professional facts and content metadata, not instructions for how the CV should look.

Design Principles

1. Single source of truth

Professional information should be entered here once and reused by all CV outputs.

The website, PDF generator, structured data, and other consumers should read from this file rather than maintaining separate copies of the same information.

2. Data vs. presentation

cv.json describes what is true about the CV, not how it should be displayed.

Do not add presentation-specific fields such as:

"show_on_page_1": true

"sidebar": true

"font_size": 10

"pdf_section": "sidebar"

The HTML and PDF templates are responsible for layout, typography, ordering, page breaks, and visual treatment.

3. Public-CV control with `pubcv`

pubcv is an in-house content-publication switch.

"pubcv": true

means the item is eligible for inclusion in the public CV.

"pubcv": false

means the item is retained in the canonical data but should not be included in the public CV presentation.

pubcv does not mean:

selected for an award;
selected for publication;
academically selected;
ranked;
more important in an objective sense.

It only controls whether the item is intended for the public CV.

Top-level structure

The current top-level structure is:

metadata
person
professional_summary
experience
education
research
works
projects
honours
professional_development
skills
languages
additional_information
professional_memberships
service_and_volunteering
presentations
conferences
teaching
grants
references
declaration

Each section is described below.

`metadata`

Contains information about the JSON document itself.

"metadata": {
  "schema_version": "1.0",
  "last_updated": "2026-09-05",
  "language": "en-IN",
  "canonical_url": "https://keshavbhardwaj.in/assets/api/json/cv.json"
}

Fields

Field	Type	Meaning
`schema_version`	string	Version of the CV JSON structure
`last_updated`	string	Date on which the canonical data was last updated
`language`	string	Language/locale of the CV content
`canonical_url`	string	Public canonical URL of the JSON document

Language

The current locale is:

en-IN

Use Indian English conventions in authored content and schema keys where appropriate.

Examples:

organisation
specialisation
optimisation

However, official organisation names must not be altered merely to enforce spelling conventions.

`person`

Contains identity, contact, profile, and basic personal information.

person
├── first_name
├── last_name
├── preferred_name
├── honorific
├── headline
├── summary
├── location
├── nationality
├── date_of_birth
├── contact
├── profiles
└── photo

`contact`

Contains public contact details.

"contact": {
  "email": [],
  "phone": null,
  "website": ""
}

email is an array because more than one public professional email address may be available.

Do not add private contact information to this public file.

`profiles`

Contains external professional/academic profile URLs.

Examples include:

LinkedIn
ORCID
Google Scholar
GitHub
ResearchGate
X
other profiles

Unavailable profiles should use null rather than invented URLs.

`photo`

Contains the public profile photograph reference:

"photo": {
  "url": "/assets/img/profile.webp",
  "alt": "Keshav Bhardwaj"
}

`professional_summary`

Contains reusable professional summaries.

"professional_summary": {
  "short": "...",
  "long": "..."
}

`short`

A concise summary suitable for:

CV header;
profile cards;
metadata;
compact CV versions.

`long`

A fuller professional summary suitable for:

detailed CV;
biography sections;
profile pages;
structured-data descriptions where appropriate.

Avoid maintaining another duplicate summary elsewhere in the JSON.

`experience`

An ordered list of professional employment and work experience.

Each entry uses a stable id.

Typical structure:

{
  "id": "unique-experience-id",
  "organisation": "...",
  "department": null,
  "role": "...",
  "employment_type": "...",
  "start_date": "YYYY-MM",
  "end_date": null,
  "current": true,
  "location": "...",
  "url": "...",
  "description": "...",
  "highlights": [],
  "research_areas": [],
  "projects": []
}

Important fields

Field	Meaning
`id`	Stable machine-readable identifier
`organisation`	Employer/organisation
`department`	Department, division, centre, etc.
`role`	Position held
`employment_type`	Full Time, Internship, etc.
`start_date`	Start date
`end_date`	End date; `null` for ongoing roles
`current`	Explicit current-status indicator
`location`	Location of the role
`url`	Relevant official organisation/page URL
`description`	Short description
`highlights`	Key responsibilities or achievements
`research_areas`	Research/policy areas associated with the role
`projects`	Named projects associated with the role

Project references

Where a project has its own entry in projects, prefer using its stable project ID rather than duplicating project data.

`education`

Contains academic and educational history.

Each record may contain:

id
institution
degree
level
field
specialisation
subjects
start_date
end_date
location
url
grade
status
thesis
highlights

`level`

Represents the educational category.

The current data uses arrays such as:

"level": [
  "Postgraduate",
  "Masters"
]

and:

"level": [
  "Undergraduate",
  "Bachelors"
]

If this structure is retained, values should remain consistent.

`status`

Examples:

completed
withdrawn

A withdrawn programme should remain factually represented as withdrawn; it should never be presented as a completed degree.

`specialisation`

Use the Indian-English spelling consistently.

`research`

Contains research interests and structured research areas.

research
├── research_interests
└── research_areas

`research_interests`

A concise list of subjects and topics of research interest.

`research_areas`

Structured descriptions of major research domains.

Each area has:

id
area
description
keywords

The id should remain stable once established.

`works`

Contains publications and other scholarly/research works.

Typical fields:

id
type
status
title
authors
venue
publication_date
publisher
volume
issue
pages
doi
isbn
url
description
keywords
pubcv

`status`

Describes the factual publication status.

Examples:

published
unpublished

Do not use status to mean whether the work appears on the public CV.

That is the purpose of pubcv.

`pubcv`

Controls inclusion in the public CV.

"pubcv": true

or:

"pubcv": false

`projects`

Contains structured descriptions of professional or research projects.

Typical fields:

id
name
status
role
organisation
start_date
end_date
description
methods
outcomes
url
pubcv

`status`

Describes the project’s factual state, such as:

ongoing
completed

`methods`

Describes methods or kinds of work involved.

`outcomes`

Records concrete outcomes where available.

An empty array is preferable when there are currently no documented outcomes.

`honours`

Contains scholarships, fellowships, awards, recognitions, and similar distinctions.

Typical fields:

id
type
name
issuer
date
status
description
url
pubcv

Important distinction

status describes the actual status of the honour.

For example:

awarded
unclaimed

pubcv independently controls whether it appears on the public CV.

Therefore:

"status": "awarded",
"pubcv": true

is different from:

"status": "unclaimed",
"pubcv": false

`professional_development`

Contains courses, specialisations, training programmes, workshops, and other professional-development activities.

Typical fields:

id
type
name
provider
platform
venue
length
date
status
credential_id
url
pubcv

Not every field applies to every entry.

Use null when a value is genuinely unavailable.

`type`

Examples currently used include:

course
specialisation
honours_course
training
workshop
capacity building program

The type should describe what the activity actually was, rather than how it should be displayed.

`skills`

Groups professional capabilities.

Current categories include:

research_and_analysis
policy_and_governance
technology_and_digital
programming
software_and_tools
communication_and_editorial

Skills that have meaningful proficiency information may use objects:

{
  "name": "Python 3",
  "proficiency": "Beginner"
}

Other capability lists may remain simple strings where a proficiency rating would be artificial or unnecessary.

Do not add proficiency ratings merely for visual consistency.

`languages`

Contains language capabilities.

Typical structure:

{
  "language": "English",
  "proficiency": "Fluent",
  "reading": null,
  "writing": null,
  "speaking": null
}

reading, writing, and speaking should remain null unless separate proficiency information is actually known.

Do not infer language proficiency from education, nationality, location, or other fields.

`additional_information`

Contains supplementary professional/personal CV information that does not naturally belong elsewhere.

Current structure:

additional_information
├── interests
├── foreign_travel
└── other

interests contains personal interests appropriate for a public CV.

The current interests include:

Flight simulation
Wargaming
Philately
Aviation patches
Books

Empty collection sections

The following sections are deliberately present even when currently empty:

professional_memberships
service_and_volunteering
presentations
conferences
teaching
grants

They provide stable extension points for future CV data.

An empty array means:

There are currently no records in this category.

Do not invent placeholder records simply to populate the section.

`references`

Contains professional references where applicable.

Current structure:

"references": {
  "available": false,
  "note": null,
  "people": []
}

Because this is a public JSON endpoint, references should only be added when their publication is appropriate and authorised.

Do not put private referee contact details into the public JSON without permission.

`declaration`

Optional declaration/signature information.

Current structure:

"declaration": {
  "text": null,
  "date": null,
  "signature": null
}

This section is retained for compatibility with formal CV formats but need not be populated for ordinary web use.

Date convention

Dates should be represented as strings using ISO-style precision appropriate to the information actually known.

Examples:

"date": "2026-07-31"

"start_date": "2026-05"

"start_date": "2021"

Rules

Use a string, never a bare JSON date.
Use YYYY when only the year is known.
Use YYYY-MM when month precision is known.
Use YYYY-MM-DD when the exact date is known.
Use null when a date is genuinely unavailable.
Do not manufacture precision that is not known.

Null vs. empty array

Use these deliberately.

`null`

Use when a field is applicable but its value is unavailable or not known.

Example:

"url": null

`[]`

Use when the field represents a collection and there are currently zero items.

Example:

"projects": []

Do not replace all nulls with empty strings.

Stable IDs

Records that have an id should have a stable, unique identifier.

Example:

"id": "cag-interlink"

IDs should:

be lowercase;
use hyphens;
remain stable after publication;
not depend on display wording;
not be changed merely because the title is edited.

Changing an ID can break references from other parts of the site.

`pubcv` rules

pubcv is the principal public-CV inclusion switch.

`true`

The record may be rendered in the public CV.

`false`

The record should remain in the canonical data but should be omitted from the public CV.

Important

pubcv is content metadata, not presentation metadata.

The renderer decides:

where the item appears;
how much space it receives;
whether it is shown in a compact or detailed form;
typography;
ordering;
page breaks.

The JSON only answers:

Should this record be considered part of the public CV?

Renderer responsibilities

Consumers of cv.json should handle presentation independently.

For example:

cv.json
   │
   ├── /cv/ HTML
   │
   ├── CV PDF
   │
   ├── Schema.org
   │
   └── Other machine-readable consumers

The renderer may:

filter records using pubcv;
format dates;
resolve project references;
construct links;
generate Schema.org data;
choose sections;
create page breaks;
select typography;
generate PDF output.

The renderer must not modify the canonical JSON.

Validation requirements

Before deployment, cv.json should be validated as JSON.

The build should fail if:

JSON syntax is invalid;
required structural fields are malformed;
dates are not strings;
an expected boolean such as pubcv contains another type;
duplicate IDs exist;
referenced project IDs cannot be resolved, if project-ID references are implemented.

A deployment should never publish a partially broken CV.

Updating the CV

When adding or changing professional information:

Edit assets/api/json/cv.json.
Preserve the existing structure.
Use the established field names.
Use Indian-English schema spelling (organisation, specialisation, etc.).
Use ISO-style date strings.
Add a stable id to new structured records.
Set pubcv deliberately where the category supports it.
Do not add PDF/layout instructions.
Validate the JSON.
Commit the change.

Generated HTML and PDF outputs should be produced by the deployment/build process rather than maintained separately.

What does not belong in `cv.json`

Do not add:

passwords;
API keys;
authentication tokens;
private correspondence;
private referee information;
internal notes;
PDF page numbers;
font sizes;
colours;
CSS classes;
HTML markup;
layout instructions;
renderer-specific settings;
cv_preferences;
arbitrary ranking/priority fields.

The file is public and should be treated accordingly.

Schema evolution

The current schema version is:

1.0

For backwards-compatible additions, the schema version may remain unchanged if the consuming templates can safely ignore the new field.

For structural or breaking changes, increment the schema version.

Examples of potentially breaking changes:

renaming a field;
changing a field from string to object;
changing the meaning of an existing field;
removing a field relied upon by renderers;
changing the structure of a major collection.

When changing the schema, update this documentation and all consumers together.

Current canonical data model

At a high level:

cv.json
│
├── metadata
│
├── person
│   ├── contact
│   ├── profiles
│   └── photo
│
├── professional_summary
│
├── experience
│
├── education
│
├── research
│   ├── research_interests
│   └── research_areas
│
├── works
│
├── projects
│
├── honours
│
├── professional_development
│
├── skills
│
├── languages
│
├── additional_information
│
├── professional_memberships
├── service_and_volunteering
├── presentations
├── conferences
├── teaching
├── grants
│
├── references
└── declaration

The canonical principle is:

cv.json contains the facts. The renderer decides the presentation. pubcv decides whether an eligible record belongs in the public CV.

Keshav Bhardwaj

cv.json Documentation

Overview

Design Principles

1. Single source of truth

2. Data vs. presentation

3. Public-CV control with pubcv

Top-level structure

metadata

Fields

Language

person

contact

profiles

photo

professional_summary

short

long

experience

Important fields

Project references

education

level

status

specialisation

research

research_interests

research_areas

works

status

pubcv

projects

status

methods

outcomes

honours

Important distinction

professional_development

type

skills

languages

additional_information

Empty collection sections

references

declaration

Date convention

Rules

Null vs. empty array

null

[]

Stable IDs

pubcv rules

true

false

Important

Renderer responsibilities

Validation requirements

Updating the CV

What does not belong in cv.json

Schema evolution

Current canonical data model

`cv.json` Documentation

3. Public-CV control with `pubcv`

`metadata`

`person`

`contact`

`profiles`

`photo`

`professional_summary`

`short`

`long`

`experience`

`education`

`level`

`status`

`specialisation`

`research`

`research_interests`

`research_areas`

`works`

`status`

`pubcv`

`projects`

`status`

`methods`

`outcomes`

`honours`

`professional_development`

`type`

`skills`

`languages`

`additional_information`

`references`

`declaration`

`null`

`[]`

`pubcv` rules

`true`

`false`

What does not belong in `cv.json`