Passportiq

Check this application's phone, address, email, passport number, identity and document image hashes against every other seeded applicant for reuse. Returns one signal per reused identifier per matched application, with severity and confidence.

Build the applicant link-analysis graph for this application's cluster. Nodes are applications (coloured by risk level), edges are the identifiers they share. Traverses links transitively, so an applicant connected only through an intermediary still appears.

Record the officer's final decision on an application: approve, request clarification, or reject. Blocked until every verification stage has completed for that application. This is a human decision — the AI never auto-approves.

Run the full verification pipeline for one application, in order: document_validate, ocr_extract, identity/address consistency, duplicate-signal detection, risk graph, rule evaluation, risk scoring and explanation. Each stage emits pipeline.stage_completed as it finishes so the dashboard updates live. Does NOT decide the application — that is officer_decide, which stays a human action.

List every passport application in the queue with its applicant, document count, submission date, current status and verification progress. Use this to pick an application to verify — do not guess application IDs.

Full detail for one passport application: applicant fields, address, every submitted document with its type and image hash, current status, and any decision already recorded. This is the raw case file — verification findings come from the pipeline tools.

Group the entire applicant pool into clusters of applications connected by shared identifiers (phone, address, email, passport number, identity, document image). Answers "are there any fraud rings in the queue at all?" without verifying each application one by one — the intake-triage view.

Read the ordered event stream for one application — every pipeline.stage_completed and application.decided event, with its payload. Pass the last sequence number you saw as `sinceSequence` to fetch only what is new, so a dashboard can stream the timeline.

Which verification stages have completed for this application, which are still outstanding, and whether an officer decision is unlocked yet. Read-only — this asks the same question PipelineCompleteGuard enforces, without attempting a decision.

The append-only record of officer decisions: who decided, what they decided, when, the risk score on screen at the time, and which applications were linked. Omit applicationId for the full trail across every case.

Check the document set against the statutory checklist for this application type: which required documents are absent, which submitted documents have expired, and which expire inside the processing window. Returns a full per-document checklist, so the officer sees what was checked and not only what failed. Deterministic — no model involved.

AI-assisted field extraction from ONE submitted document: name, date of birth, address, document number and parent names where present, each with its own confidence. Reports `extractionMode` so the caller can see whether a model read the scan ('vision-llm') or the fields came from the deterministic path ('deterministic'). Call once per document type; the consistency stages then diff the results against each other.

Compare the applicant name and date of birth stated on EVERY submitted document against the application form and against each other. Name comparison distinguishes a genuinely different person from a filing convention — reordered names, an expanded initial or an omitted middle name are graded low rather than reported as identity conflicts, because a panel of false positives is what makes officers stop reading the panel. Dates of birth are compared exactly and are always high severity.

Compare the residential address on the application form against every address-bearing document. PIN code is compared exactly and graded high — it is the one machine-checkable address field, so a difference there is a real discrepancy rather than a transcription variant. City, state and street line are compared with normalisation. Documents that state no address do not participate: a photograph carrying no address is not an inconsistency.

ADVISORY FLAG, NOT A BIOMETRIC MATCH. Compares the photograph on two applications. When the two image files are byte-identical this is reported deterministically as a fact about the files. When they differ, the surrounding application context (shared identifiers, dates of birth, cluster membership) is reasoned over instead, and the payload states that no image comparison was performed. Optional stage — it is NOT required before an officer decision, and the score weights it low on purpose.

Apply the cited passport rulebook to everything the earlier stages established. Returns the rules that FIRED (each with a statutory citation, severity, source stage and evidence), the rules that were evaluated and passed, and — critically — the rules that were SKIPPED because an upstream stage had not reported. A skipped rule is unchecked, not passed: collapsing those two into one boolean is how an unverified application comes to look like a cleared one. Fully deterministic.

Combine every stage result into a weighted 0-100 risk score with a band, a per-category breakdown, and a named factor for every point in the total — so the number is reviewable rather than asserted. Also returns `confidence`, which reports how much of the pipeline actually reported in: a low score at low confidence is an UNASSESSED application, not a safe one, and the officer UI must render that caveat. Deterministic arithmetic; no model is involved, because a government risk score that changes between two identical runs cannot be defended in an appeal.

Turn the score and its findings into an officer-readable case note, an ordered evidence list, a recommended action and — if clarification is the recommendation — the specific questions to put to the applicant. The recommendation is computed deterministically; a language model, when configured, only phrases it. `narrationMode` states which happened. The recommendation is never a decision: officer_decide is a separate guarded human tool and nothing in this stage can reach it.

Run the autonomous verification agent on one application. The agent decides its own next action each turn based on what it has learned so far — it is not a fixed pipeline. It reacts to its own findings (for example, it only compares photographs when it has already found a reused document image, and it picks the comparison target from those findings), spends extra turns when its confidence is low, and terminates by handing the case to a human officer with a recommendation and a worst-first checklist. The agent CANNOT approve or reject an application — that authority is the officer's alone. Returns the complete reasoning trace for audit.

Autonomously investigate every pending application, then correlate the results ACROSS the queue to surface coordinated fraud rings that no single-file review can see. Returns the officer work queue ordered by genuine urgency — senior-review cases first, then by risk score, then by how many other applicants are implicated — plus the list of detected rings. Every row carries the agent run id that produced it, so any ranking can be traced back to the reasoning behind it.

Read back the agent's recommendation for an application from its most recent investigation, including the worst-first officer checklist and whether senior review is requested. This is a RECOMMENDATION ONLY: humanDecisionRequired is always true, and the agent has no path to officer_decide. Does not re-investigate — call agent_investigate first if no run exists yet, so that the rationale you read always describes the run that actually produced it.

Fetch the complete step-by-step reasoning trace of an agent run — every thought, the action chosen, the arguments it derived, what it observed back, its confidence at that point, and whether the turn was planned by an LLM or by the deterministic policy. Failed steps and overridden LLM proposals are included on purpose: this is an audit record, not a highlight reel. Pass runId for a specific run, or applicationId for the most recent run on that application.

STEP 1 OF THE PASSPORT PROCESS. File a new passport application and open a case. Generates an ARN (Application Reference Number), registers the applicant in the verification pool, and reindexes the cross-application fraud graph so the new application is immediately comparable against every existing one. Returns the ARN, the fee due, and the document checklist for the chosen application type.

STEP 2. Collect the application fee against an ARN and issue a receipt. Amount is derived from the application type and the tatkal flag using the Passport Seva fee schedule. Refused unless the case is at the "submitted" stage.

STEP 3. Allot a Passport Seva Kendra appointment slot for a paid application. The PSK is chosen from the applicant's state unless one is named. Tatkal cases get the next working day; normal cases three days out.

STEP 4. Record a completed Passport Seva Kendra visit: counter A (document granting), counter B (biometrics — photo, ten fingerprints, signature) and counter C (final granting). Counter C only clears when every mandatory document for the application type was produced; an incomplete checklist is recorded, not hidden, and will block verification.

The applicant answers an officer's clarification request, returning the case to the officer review queue. Only valid while the case is held at "clarification".

The applicant withdraws the application. Closes the case at any non-terminal stage and records the reason. Irreversible — a withdrawn case cannot be reopened, a fresh application must be filed.

STEP 5. Run the full PassportIQ verification pipeline against a case whose PSK visit is complete: document checks, field extraction, identity and address consistency, cross-application duplicate signals, the fraud graph, the government rulebook, the weighted risk score and a plain-language explanation. Refuses to run when counter C is unresolved. Attaches the score, the signals and the linked-application cluster to the case.

STEP 6. Raise a police verification request with the district covering the applicant's address. Requires the verification pipeline to have completed every mandatory stage — the district should not be asked to visit an address the system has not even checked.

STEP 7. File the district police verification report against a case and move it into the officer review queue. An "adverse" or "incomplete" verdict does NOT reject the application — it is evidence the officer reads. Only a human officer decides.

STEP 8. Allot a passport number and print the booklet. Requires a recorded grant by a named officer — checked against the case record independently of the stage, so no refactor can produce a passport nobody approved.

STEP 9. Hand the printed booklet to Speed Post and issue a tracking number the applicant can follow.

STEP 10 — the last one. Confirm the applicant received the passport. Closes the case permanently.

Read one passport case end to end: current lifecycle stage, SLA clock, every artefact produced so far (fee receipt, PSK appointment and counter results, police verification report, printed booklet, dispatch tracking), the complete journal of who moved it and why, and the single next step available. This is the tool to call before acting on a case.

List passport cases in the register, optionally filtered by lifecycle stage, by whether they are blocked on a human, or by SLA breach. Use waitingOnHuman=true to get exactly the officer's inbox — the cases PassportIQ has carried as far as it is allowed to and handed over. Returns a stage histogram alongside the rows.

The whole passport pipeline as a board: one column per lifecycle stage, in process order, every case as a card with its SLA clock and its next available step. Also returns the lifecycle definition itself (every declared transition, and which of them PassportIQ is permitted to perform unattended) so a client can reason about the process without hard-coding it.

CITIZEN-FACING STATUS CHECK. Track a passport application by ARN and get the plain-language status a Passport Seva enquiry counter would read out: which stage it has reached, what happens next, the expected date, and the applicant-owned artefacts (fee receipt, appointment slot, Speed Post tracking number). Internal fraud reasoning, officer notes and agent rationale are deliberately NOT returned.

AGENTIC DRIVER. Move one passport case forward through as many lifecycle steps as PassportIQ is permitted to perform unattended, then stop and explain why it stopped. Each step returns the reasoning composed BEFORE the action was taken, the tool invoked, and the outcome. The loop always halts at officer_review — granting a passport is reserved for a human and no number of steps will cross it.

Control the autonomous lifecycle loop that walks the entire case register on a timer: arm it (start), disarm it (stop), or run exactly one pass right now (tick). A tick perceives every open case, prioritises by tatkal and SLA breach, executes the permitted transitions, and narrates what it did and what it refused to do. Use action=tick for a deterministic, demonstrable single pass.

Report what the autonomous autopilot is doing right now: whether it is armed, which application it is currently investigating, how many it has swept, how many it escalated to a human, and when the next sweep runs. Use this to answer "is the system working on anything?" without triggering work. The autopilot investigates on its own schedule and always stops at the officer handoff — it never records a decision.

Arm, disarm, or immediately trigger the autonomous autopilot. action="sweep" runs one sweep now and waits for it, returning what the agent concluded; action="start" arms the recurring schedule; action="stop" disarms it. The autopilot only investigates — it cannot approve, reject or request clarification, so this tool cannot change any application's outcome.

The officer's prioritised work queue: every application ordered by how urgently a human is needed (undecided first, then highest risk, then largest linked cluster, then least progressed). Each row carries a one-line reason for its position, so this answers "what should I look at next, and why?" in one call. Read-only.

The live activity feed: every pipeline stage completion, agent step, autopilot sweep and officer decision, in order, with a monotonic id so a caller can poll for only what is new. This is the audit-grade record of everything the machine did, including work no human triggered. Read-only.

Talk to PassportIQ in plain language. The copilot routes the instruction to the real MCP tools (triage, investigation, pipeline runs, risk explanations, guarded officer decisions), executes them, and answers with every tool call it made listed for audit. It recommends but never decides — "approve X" goes through officer_decide behind the same completeness guard as every other caller.