Security Solutionsसुरक्षा सॉफ़्टवेयर
The latest product update on this page is currently in English. Navigation and account services remain available in your selected language.
Sentinel ID · National identity & operationsExplore all four products →
Illustrative case studies

How the workflows fit real operational tasks

These scenarios explain the software workflow. They are not customer testimonials, verified deployments or measured results. Each scenario states its dependencies.

Illustrative scenario: Officer safety

An officer loses the connection during an SOS

An officer sends an SOS during patrol. A voice call to headquarters drops before the details are complete.

  1. Control receives the minimized pending-emergency badge and a new-alert sound. The emergency remains pending until acknowledged.
  2. The dispatcher opens the reported map location, checks the age of nearby officer positions and sends a nearby responder or chooses a specific officer.
  3. Control uses Call back to reach the originating officer directly. The responder accepts the dispatch and reports progress.

Practical value: A visible acknowledgement step and a linked response record help control follow up.

Conditions: The map needs reported coordinates. Voice reconnection depends on connectivity, permissions and a suitable relay configuration.

Officer safety interface with demonstration data
Demonstration interface. Scenario is illustrative.
Illustrative scenario: Identity history

A phone number belongs to a different person later

An investigator searches a number that a witness stopped using last year. Another person now uses the same number.

  1. The register retains the earlier person’s dated phone history and records the later assignment separately.
  2. The investigator compares the relevant dates, registered identifiers and case context.
  3. Any update follows the applicable permissions and approval policy, while the change history remains available.

Practical value: The record preserves context when a number changes hands.

Conditions: A shared or reassigned number is not proof that two people are the same person. Information remains subject to authorised verification.

Identity history interface with demonstration data
Demonstration interface. Scenario is illustrative.
Illustrative scenario: Field operations

A complaint starts where there is no signal

An officer takes a complaint on an approved Android tablet in an area with unreliable data coverage.

  1. The officer records the description and statement, reviews spelling suggestions and saves an encrypted local draft.
  2. When connectivity returns, the app retries synchronisation. An idempotency reference helps prevent duplicate complaints after a lost response.
  3. The case enters the agency’s normal assignment, evidence and review workflow.

Practical value: Field capture can continue while the network is unavailable.

Conditions: Server searches, live calls and external checks require connectivity. Device approval and storage must be correctly configured.

Field operations interface with demonstration data
Demonstration interface. Scenario is illustrative.
Illustrative scenario: Camera operations

A camera reports a vehicle on a lookout

An agency flags a vehicle associated with an open investigation. A connected camera sends a readable plate image.

  1. The camera submits the image using its dedicated key and registered location.
  2. The system records the sighting and raises the configured alert when the recognised plate matches a flagged record.
  3. An authorised operator reviews the source image, checks the record and issues a dispatch where appropriate.

Practical value: A camera observation can become a reviewed investigative lead with a location and time.

Conditions: Plate recognition depends on image quality, supported formats and deployment validation. This scenario does not claim an arrest or guaranteed match.

Camera operations interface with demonstration data
Demonstration interface. Scenario is illustrative.
Illustrative scenario: Partner integration

A travel watch receives an authorised partner event

An agency places a travel watch on a registered person. An authorised airline or border integration supplies an event.

  1. A scoped partner credential submits the supported event and its reference identifiers.
  2. The system records the event and evaluates the configured watch conditions.
  3. An authorised reviewer checks the alert and supporting records before taking action under the agency’s procedures.

Practical value: Partner events appear alongside other recorded activity for a permitted investigation.

Conditions: This requires an actual partner connection, data-sharing authority and matching identifiers. It is not evidence of a live airline or border deployment.

Partner integration interface with demonstration data
Demonstration interface. Scenario is illustrative.
Illustrative scenario: Access control

An unfamiliar device attempts to sign in

An administrator sees a sign-in attempt from an Android installation that has not been approved.

  1. The installation enters the configured device approval and key-enrolment process.
  2. An authorised administrator reviews the request and can refuse or revoke the device, investigate the account and rotate credentials.
  3. Web authenticator policy, session controls and audit records support the follow-up.

Practical value: Device review gives administrators an explicit control over field access.

Conditions: Effective protection also requires secure device configuration, account hygiene and timely administrative review.

Access control interface with demonstration data
Demonstration interface. Scenario is illustrative.
Illustrative scenario: Continuity

A restore drill checks recovery readiness

The agency wants to confirm that an encrypted archive can restore a working copy before it relies on the backup process.

  1. An authorised operator creates an encrypted archive using the provisioned backup key.
  2. The team verifies it and restores into a separate, isolated recovery database and storage location.
  3. Operators compare the restored records and attachments and record the drill result against the recovery procedure.

Practical value: A completed drill provides evidence about that archive and recovery procedure.

Conditions: Protected keys, sufficient storage and an isolated recovery target are essential. This is not an uptime or recovery-time guarantee.

Continuity interface with demonstration data
Demonstration interface. Scenario is illustrative.
Illustrative scenario: Camera connection

A remote camera sends an image to control

A remote site has a camera that can upload images but cannot accept an inbound connection from the control room.

  1. An administrator registers the camera location and supplies its dedicated upload key and server connection details.
  2. The camera submits supported images over a reachable network connection. Source-IP allowlisting is not required for this image-upload service.
  3. The operator reviews recorded observations and configured alerts. The administrator can rotate or revoke the key.

Practical value: Outbound image upload offers a connection path for supported remote cameras.

Conditions: The camera must support the required image request, reach the server and protect its credential. Network coverage and camera compatibility need testing.

Camera connection interface with demonstration data
Demonstration interface. Scenario is illustrative.
Illustrative scenario: Video investigation

Investigators review a submitted video

An authorised investigator has approved CCTV footage relevant to an open case.

  1. The investigator submits a supported recording for video analysis.
  2. The system extracts candidate observations and compares supported biometric information with the registered records.
  3. The investigator reviews candidate matches, source frames and relevant timestamps before linking any finding to the case.

Practical value: The workflow helps organise review of recorded footage.

Conditions: Quality, visibility and representative recognition evaluation matter. A candidate does not establish identity or guilt.

Video investigation interface with demonstration data
Demonstration interface. Scenario is illustrative.
Illustrative scenario: Agency cooperation

Two agencies review an authorised shared case

A case owner needs a second agency to review permitted information without opening the entire case register.

  1. An authorised owner selects the receiving agency through a live backend search.
  2. Sharing rules and the receiving user’s permissions determine the available case information and actions.
  3. The teams record their notes and follow the normal evidence, assignment and approval processes.

Practical value: Explicit case sharing supports cooperation with a defined access boundary.

Conditions: Agency agreements, user permissions and evidence-handling procedures must be established. Sharing a case does not grant access to unrelated records.

Agency cooperation interface with demonstration data
Demonstration interface. Scenario is illustrative.
Illustrative scenario: Identity investigation

A claimed identity needs further checking

An officer has a permitted reason to verify a person’s claimed identity using an external fingerprint sample.

  1. The officer uses a compatible scanner integration or an approved imported sample. The phone’s built-in sensor only unlocks the app.
  2. The system returns candidate records under the configured search threshold and review policy.
  3. The officer checks independent identifiers and follows the required human verification and escalation procedure.

Practical value: The search provides leads for an authorised identity review.

Conditions: A suitable sample, hardware integration and evaluated recognition performance are required. No automatic detention or verified identification is implied.

Identity investigation interface with demonstration data
Demonstration interface. Scenario is illustrative.
Illustrative scenario: Identity review

Activity appears against a recorded deceased identity

A new recorded event refers to an identity marked deceased in the register.

  1. The configured workflow flags the inconsistency for authorised review.
  2. An investigator checks the original event, identifiers and provenance of the deceased-status entry.
  3. Any correction or escalation follows the agency’s evidence and approval procedures.

Practical value: The inconsistency becomes visible alongside the identity record.

Conditions: Incorrect source records and reused identifiers can produce misleading leads. An alert is not proof of fraud.

Identity review interface with demonstration data
Demonstration interface. Scenario is illustrative.

A demonstration built around your workflow

Review the evidence, hardware and integration requirements before a pilot.

Arrange a demonstration