> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superadmission.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Core Capabilities

> How a profile gets verified, how documents get checked, how guidance gets calculated, how seats get matched, and how deadlines stay in sync, all explained in one place.

Everything on this page runs quietly underneath the profile and dashboard a student actually sees.

## One Verified Profile

A student verifies their identity through an <Tooltip tip="India's national biometric identity system">Aadhaar</Tooltip>-linked <Tooltip tip="One-time password, a short code sent to a registered mobile number to confirm identity">OTP</Tooltip>, the same method already used across most government services. This confirms who someone is without ever storing their Aadhaar number or any biometric data, only a verified yes-or-no status. A student without Aadhaar, or who doesn't want to use it, verifies through an alternate route instead, so this never becomes a hard requirement just to participate.

Once verified, a student's name, date of birth, and category are confirmed a single time. Every counselling system connected afterward reads from that same profile, instead of asking for the same details all over again.

<Accordion title="What a student actually controls">
  <CardGroup cols={2}>
    <Card title="Which systems to connect" icon="link">
      Connecting to JoSAA doesn't automatically connect to a state CET too. Each one is its own decision.
    </Card>

    <Card title="Which documents to share" icon="folder-open">
      A document verified once doesn't get shared with every connected system automatically.
    </Card>

    <Card title="Editing preferences before locking" icon="pen">
      Anything entered can be changed freely until it's actually locked in.
    </Card>

    <Card title="Confirming actions like accepting a seat" icon="square-check">
      Nothing that affects a real outcome happens without a student explicitly confirming it.
    </Card>
  </CardGroup>

  Each of these can be undone independently. Support is also available in more than one Indian language, since a portal that only works in English is a real barrier for a lot of applicants.
</Accordion>

## Document Vault

A document either gets fetched directly from <Tooltip tip="India's government-run digital document locker, where boards and universities place signed, verified copies of certificates directly">DigiLocker</Tooltip>, already signed by the board or university that issued it, or gets uploaded manually where it isn't available there yet. A manually uploaded document is automatically checked for format, completeness, and consistency, name matching across every other document submitted, certificate numbers formatted correctly, a scan that's actually readable, and this produces a confidence score that decides what happens next.

```mermaid actions={true} theme={null}
%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#003d5c',
    'primaryTextColor': '#ffffff',
    'primaryBorderColor': '#31497e',
    'lineColor': '#674f95',
    'background': 'transparent',
    'fontFamily': 'Inter, sans-serif'
  }
}}%%
flowchart LR
    A[Document uploaded] --> B[Automated checks run:\nformat, completeness, consistency]
    B --> C{Confidence score}
    C -->|80 to 100| D[Cleared automatically,\nminimal or no manual review]
    C -->|50 to 79| E[Sent to the standard\nreview queue]
    C -->|Below 50| F[Sent to priority review,\na person looks at it directly]
    D --> G[Marked verified]
    E --> G
    F --> G

    style A fill:#31497e,stroke:#003d5c,color:#fff
    style B fill:#674f95,stroke:#31497e,color:#fff
    style C fill:#a14e9a,stroke:#674f95,color:#fff
    style D fill:#ffa600,stroke:#ff7a47,color:#fff
    style E fill:#ff7a47,stroke:#f9596f,color:#fff
    style F fill:#f9596f,stroke:#d44c8d,color:#fff
    style G fill:#d44c8d,stroke:#a14e9a,color:#fff

```

<Accordion title="What happens on rejection">
  If a document is rejected, whether by the automated check or by a person, the student is told specifically why, a mismatch, an unreadable scan, a missing page, not just "rejected." Resubmitting a corrected version goes through the same process again. If a student believes a rejection was actually wrong, that's a dispute, handled the same way any other one is on [How a Dispute Actually Gets Resolved.](https://docs.superadmission.com/operations/how-a-dispute-actually-gets-resolved)
</Accordion>

Once verified, that status is shared rather than rechecked. JoSAA and a state CET both see the same "verified" mark from the same single check, which is the entire point of doing this once instead of three or four times.

## Probabilities and <Tooltip tip="Choice-filling : where candidates list their preferred colleges and courses in order of priority for seat allotment from most wanted to least wanted">preference list</Tooltip>

When a student is building their preference list, a probability appears next to each option. It's based on the student's own rank and category, past-year closing ranks for that specific programme, the current seat matrix, and how much that cutoff has historically moved year to year.

<Accordion title="Why it's shown as a band,">
  Your admission chances are based on past cutoffs: <br /> **High:** Your rank is safely within past cutoffs. <br /> **Moderate:** Your rank is right on the edge of past cutoffs. <br /> **Low:** Your rank is well beyond past cutoffs.

  We use these broad categories because specific percentages (like "73%") give a false sense of certainty. These estimates will update in real-time as new data comes in during the counselling round.
</Accordion>

<Warning>
  This is a historical estimate. A rank that would have cleared a cutoff last year isn't certain to clear it this year, demand shifts and seat counts change every cycle.
</Warning>

The system will never change, reorder, or lock in choices on your list. Instead, it provides data-backed guidance at every step, giving students the same high-quality personalized advice as a paid consultant, available to everyone, for free.

## A chatbot built on verified data.

Beyond a fixed preference list, a student can also just ask PraveshAI a direct question, the way they'd ask a search engine or a general AI chatbot.

Factual questions, like "what's the fee for computer science at this college" or "does this institute have a hostel," get answered from[Manifes](https://docs.superadmission.com/intelligence-and-data/what-is-manifest)<Tooltip tip="The registry of every degree-granting institution in India curated by superadmission">[t](https://docs.superadmission.com/intelligence-and-data/what-is-manifest)'s</Tooltip> verified registry. The answer traces back to a government source or a disclosed enrichment method. Where Manifest's own data on a specific field is incomplete, the chatbot says so rather than filling the gap with a guess.

Personalized questions, like "which of these is actually better for me," draws on whatever a student has added to their own profile such as category,domicile state, gender etc. and any extra information student shares with the chatbot such as fee slab you want to maintain etc.

```mermaid actions={true} theme={null}
%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#003d5c',
    'primaryTextColor': '#ffffff',
    'primaryBorderColor': '#31497e',
    'lineColor': '#674f95',
    'background': 'transparent',
    'fontFamily': 'Inter, sans-serif'
  }
}}%%
flowchart LR
    Q[Student asks a question] --> T{What kind of question}
    T -->|Factual, about a\ncourse or college| F[Answered from\nManifest's verified registry]
    T -->|Personal, like\n"which is better for me"| P[Answered using only what\nthe student has shared in their profile]

    style Q fill:#31497e,stroke:#003d5c,color:#fff
    style T fill:#674f95,stroke:#31497e,color:#fff
    style F fill:#ffa600,stroke:#ff7a47,color:#fff
    style P fill:#d44c8d,stroke:#a14e9a,color:#fff
```

None of this runs on information a student hasn't chosen to share. The same layered consent that governs document sharing, covered on How a Student's Profile Actually Works, applies here too, a student's category or state isn't used for a suggestion unless it's already part of their profile. And the same honesty rule as the odds shown during choice filling still applies: this surfaces options and explains why they fit, it doesn't pick one on a student's behalf.

## Matching Students to Seats

This is the part that actually decides who gets which seat, using an approach called <Tooltip tip="An algorithm that matches two groups, here students and seats, by having each side make and reconsider proposals until no better match is possible for anyone">deferred acceptance</Tooltip>, already the basis for how JoSAA and most state counselling bodies run their own allocation today.

Each student has a ranked list of seats they'd accept. Each seat has a ranked list of students it would accept, by merit and eligibility. Students provisionally match to their best available option, and if someone with a better rank later wants the same seat, they can bump someone with a lower rank, who then moves to their next preference. This continues until nobody can be matched any better, a point called a stable match.

```mermaid actions={true} theme={null}
%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#31497e',
    'primaryTextColor': '#ffffff',
    'primaryBorderColor': '#003d5c',
    'lineColor': '#a14e9a',
    'background': 'transparent',
    'fontFamily': 'Inter, sans-serif'
  }
}}%%
flowchart LR
    A[Students' ranked\npreference lists] --> C[Matching process runs]
    B[Seats' eligibility\nand merit order] --> C
    C --> D{Better match\npossible for anyone?}
    D -->|Yes| C
    D -->|No| E[Stable match reached,\nresult goes to the authority]

    style A fill:#003d5c,stroke:#31497e,color:#fff
    style B fill:#003d5c,stroke:#31497e,color:#fff
    style C fill:#d44c8d,stroke:#a14e9a,color:#fff
    style D fill:#f9596f,stroke:#d44c8d,color:#fff
    style E fill:#ff7a47,stroke:#ffa600,color:#fff

```

Category and reservation rules aren't applied afterward, they're built into each seat's eligibility from the start, so a reserved seat simply never appears as an option for a student outside that category. This same approach can process well over a million applications in under an hour. What comes out is a proposed result, not a published one, it goes to the authority for review, and nothing reaches a student until the authority signs off, covered in full on How a Counselling Authority Actually Runs a Round.

## Keeping Every Deadline in Sync

Two counselling systems a student is registered with almost never share a calendar. A JoSAA deadline and a state CET deadline can land within hours of each other with nothing connecting the two, which is exactly the coordination gap described earlier in this whitepaper.

Every deadline a student is actually subject to, across every system they're connected to, is watched and surfaced together on one dashboard, sorted by urgency rather than by which portal it happens to belong to. Where two deadlines sit close enough that missing one is a real risk, that's flagged in advance, not discovered after the fact.

> One student might have a JoSAA acceptance window closing at 11:59 PM on a Tuesday, and a state CET window closing at 5:00 PM two days later. Looked at separately, both look like a comfortable three-day window. Shown together, it's immediately clear the real decision has to be made well before the first one closes, not right up against either deadline.

This works the same way for status, not just dates. If a seat is accepted in one system, the dashboard shows exactly what that means for a seat currently held in another, instead of leaving a student to work out the consequence on their own.