POLARIS

Police Officials’ Language-based Analytical Retrieval & Intelligence System

Empowering Sindh Police with Intelligent, Multilingual Information at Your

Fingertips

Developed by:
Sindh Police IT & Tech Innovation Unit
Deployment: On-Premises (Sindh Police Headquarters)

Table of Contents
1. Project Name & Acronym
2. Purpose and Objectives
3. Project Scope (Sindh Province)
4. Timeline and Milestones
5. Scrum Team Management Plan
6. Required Skill Set
7. Team Composition
8. Tasks Suitable for Outsourcing
9. Training and Tutorial Strategy
10. Documentation Strategy
11. Development Workflow: User Stories, Epics, Issues, Tasks
12. Identified Entities (Data and Domain Model)
13. Concurrency and User Load Validation
14. Licensing and Software Costs (2-Year Breakdown)
15. UI/UX Design Approach (Figma Prototypes & Style)
16. Field Usage Scenario – Video Concept

1. Project Name & Acronym

Back to TOC

POLARIS: Police Officials’ Language-based Analytical Retrieval & Intelligence System...

[Continue with the detailed sections as previously provided in the full report, with each
section ending with a "Back to TOC" hyperlink.]

Great. I’ll create a comprehensive report for your AI-powered software system tailored for
police officials in Sindh. It will support inference-based natural language queries in English,
Urdu, Pashto, and Sindhi, drawing data from structured PDFs, call records in Excel, and MS
SQL databases. The system will be designed for 100 concurrent users and developed with
Figma and low-code tools for mobile (Android/iOS) and web/desktop admin control.
Deployment will be on-premises using Lenovo SR 650 V3 hardware with under-40B
parameter AI models (with a strong recommendation included).

I'll include detailed sections for purpose, objectives, scope, timeline, team composition, skills,
architecture, Figma images, system flows, licensing, and a video concept of a Pakistani
officer using the app.

I’ll get started and update you soon with a well-structured report.

Project POLARIS – Police Officials’

Language-based Analytical Retrieval &
Intelligence System
1. Project Name & Acronym (Purpose)
The project is named POLARIS – an acronym for Police Officials’ Language-based
Analytical Retrieval & Intelligence System. The name embodies the system’s purpose: to
serve as a guiding “north star” for law enforcement officers by enabling natural
language queries and intelligent information retrieval. POLARIS will allow Sindh police
officials to ask questions in Urdu, English, Pashto, or Sindhi and get inference-driven
answers from diverse data sources. The acronym highlights the focus on police officials using
everyday language to perform analytical retrieval of records and legal intelligence, aligning
the system’s identity with its mission.

2. Purpose and Objectives

Purpose: POLARIS is designed as an AI-driven assistant to help police officers in Sindh
quickly retrieve and infer information from large volumes of disparate data. Instead of
manually searching through files, databases, or legal books, officers can ask questions
naturally (e.g., “ ‫“ – ”فلان کیس کی تفصیل بتائیں‬Tell me the details of case XYZ”) and receive
relevant answers. This improves decision-making speed and accuracy in the field and at the
station.

Key Objectives:

 Unified Query Interface: Provide a single platform where officers can query legal
statutes, case records, and call logs in plain language, and get aggregated answers
that draw from all relevant sources.
 Multilingual Support: Enable queries in Urdu, Sindhi, Pashto, and English,
ensuring officers are comfortable using their native language. The NLP engine will
handle these languages (modern multilingual models cover languages like Urdu,
Pashto, and Sindhi (GitHub - facebookresearch/XLM: PyTorch original
implementation of Cross-lingual Language Model Pretraining.)).
  Inference & Contextual Answers: Go beyond keyword search – the AI will infer
answers. For example, an officer might ask, “Which section of the law applies if a
suspect was found with unlicensed arms?” The system will interpret the query, search
the indexed legal documents, and return the relevant act/section with an explanation.
It can cross-reference the question with the 200 law PDFs to find applicable sections,
and even suggest answers based on precedent or related cases if available.
 Fast Access to Large Data: Instantly retrieve information from millions of records.
The system should handle questions like “List previous offenses of person X” by
searching the 0.7 million arrested persons database and 0.6 million case records,
compiling a quick profile. It should also handle temporal queries (e.g., “What calls
did suspect Y make last Friday?” searching the Excel CDRs) and relational queries
across databases (linking persons to cases to call records).
 Field Officer Empowerment: Empower officers during patrols or investigations with
on-the-spot information. By simply asking their mobile app, they can verify a
suspect’s background or get guidance on legal procedures, improving efficiency and
reducing reliance on calling back-office staff.
 Improved Decision Making: By having relevant data at their fingertips, officers can
make informed decisions rapidly. For instance, knowing the appropriate legal section
to charge a suspect with, or identifying if a suspect is already wanted in another case,
all through a quick query, enhances the quality of police work.

These objectives align with the broader goal of modernizing policing through technology –
much like the recently introduced “Talaash” app in Sindh which provides fast search in
criminal databases (Sindh police launch Talaash app with record of 1.5m criminals) – but
POLARIS will focus on natural language intelligence and a broader set of data (legal
references, telephony data, and case files) for a comprehensive assistant.

3. Project Scope (Sindh Province)

The scope of POLARIS is limited to the Sindh province in Pakistan, focusing on the needs,
data, and context of Sindh Police. Key aspects of the scope include:

 Geographical & Organizational Scope: The system will be deployed for Sindh
Police officials across the province (e.g. Karachi, Hyderabad, Sukkur regions). It is
not intended (in this phase) for other provincial police or federal agencies. All data
and use-cases pertain to Sindh’s jurisdiction (e.g., Sindh local laws and records). The
user base is internal police personnel (investigators, station house officers, etc.),
roughly up to 100 concurrent users as a target.
 Data Sources In-Scope: The system will integrate the following data specific to
Sindh Police:
o Legal Acts and Sections: ~200 structured PDF documents containing
provincial and federal acts, regulations, and their sections (including tables
and schedules). These likely include the Pakistan Penal Code, Sindh local acts,
criminal procedure code, etc., as applied in Sindh. POLARIS will parse and
index these documents so that officers can query any section by keyword or
ask questions like “What is the penalty under section 324?” and get the answer
with text from the law.
o Call Detail Records (CDRs): For each case, up to 10 Excel files of telephone
call logs may be attached (e.g., suspects’ phone records). The system will
 support querying these, e.g., “Did suspect A call suspect B in March 2025?”
by analyzing the CDR spreadsheets.
o Relational Databases (MS SQL): Large existing police databases:
 An Arrested Persons Database (~0.7 million records) with details of
individuals arrested or under investigation (names, CNICs/IDs,
fingerprints maybe, etc.).
 A Cases Database (~0.6 million records) tracking FIRs (First
Information Reports), case statuses, crime types, involved persons, etc.
 Other Police Records (~4 million records) – this includes ancillary
data such as Crime Record Office (CRO) records, wanted persons lists,
vehicle registrations (possibly from Excise department), stolen vehicle
lists, criminal trial statuses, and any other digitized records. These
match the scale of data in apps like Talaash, which holds about 1.5
million criminal records and related data (Sindh police launch Talaash
app with record of 1.5m criminals). POLARIS will leverage similar
data available in Sindh’s systems.
o User Directory: (If needed) Data about police officers using the system (for
authentication and auditing) – likely integrated with an existing HR or
authentication system (e.g., Active Directory or a simple user DB). This
ensures only authorized personnel access the app.
 Language Support: The system will handle content and queries in the four languages
prevalent in Sindh’s policing context:
o Urdu – the national language, commonly used in police work/reports.
o English – used for official documents and many legal texts.
o Sindhi – regional language for local officers and documents (some Sindh laws
might be in Sindhi or have Sindhi terms).
o Pashto – spoken by a segment of officers or in certain communities within
Sindh (e.g., Pashtun communities in Karachi); also useful if data or queries
involve Pashto (e.g., suspect aliases in Pashto). The NLP subsystem will either
use a multilingual model or translation layer so that a question asked in any of
these languages is understood and answered appropriately (GitHub -
facebookresearch/XLM: PyTorch original implementation of Cross-lingual
Language Model Pretraining.).
 On-Premises Deployment: All components will be deployed on premises in
Sindh (likely at the Police IT center or data center in Karachi). The hardware
specified (Lenovo ThinkSystem SR650 V3 server) will be used for hosting the AI
models, database, and application backend. This ensures data privacy (sensitive law
enforcement data remains in-house) and accessibility even if internet connectivity is
limited. The scope thus excludes any cloud-based services for core AI processing; the
solution must run locally on the provided server hardware.
 Out of Scope: Anything beyond the above is out of scope for this 3-month project.
For example, citizen-facing features (public complaint logging, etc.) or integration
with other provinces’ data are not included. Also out-of-scope are advanced analytics
like predictive policing or face recognition – POLARIS is strictly a query and
information retrieval assistant at this stage. Additionally, any data not already
digitized (e.g., paper-only records) are not included unless they are part of the
provided PDFs or databases. The focus is on leveraging existing digital data sources
within Sindh Police.
By confining scope to Sindh, the project can tailor the AI and language models to local
dialects and laws, ensuring relevant results. It also aligns with ongoing Sindh Police digital
initiatives (like the e-policing apps) while remaining self-contained for the province’s needs.

4. Timeline and Milestones (3-Month Plan starting May 1,

2025)
We will execute POLARIS over a 3-month schedule from May 1, 2025 to July 31, 2025.
The plan is broken into phases with specific milestones each month:

Phase 1 – May 2025: Planning, Setup, and Design

 Weeks 1-2 (Early May): Initiation & Requirements – Finalize requirements with
stakeholders (Police IT and end-user representatives). Conduct detailed interviews
with a few police officers to capture user stories (e.g., common questions they would
ask). Define the project backlog of features. Also set up the development
environment on the Lenovo SR650 server (install OS, databases, and any required
software).
 Weeks 2-3: UI/UX Design in Figma – Create high-fidelity designs for the mobile app
(Android/iOS) and the admin web panel. This includes a style guide (using the blue
and red police palette), screen layouts for query input and results display, navigation
flow, and any error/help screens. By mid-May, a design review with stakeholders will
be done to get feedback and approval on the Figma designs.
 Weeks 2-4: Data Preparation – Begin processing data sources: convert the 200 PDF
legal documents into text indexes (ensure tables and sections are correctly
segmented), connect to the SQL databases and verify we can query them, and gather
sample call record files to design how they’ll be parsed. If needed, develop scripts to
ingest/index this data. Also, choose the AI model and set it up: for example,
download and install the selected <40B parameter language model on the server (such
as Falcon-40B or a similar model). Ensure the model runs in a basic Q&A scenario
with sample data.
 Milestone (End of May): Design & Setup Complete – We expect to have: finalized
UI designs, a working development environment, initial data indexed, and the
baseline AI model running locally. A prototype of the Q&A engine with a small
subset of data will be demonstrated (e.g., ask a sample question to the model with a
few legal documents). Stakeholder sign-off on designs and a refined project plan for
build phase will be obtained.

Phase 2 – June 2025: Core Development (Iterative Sprints)

 Weeks 5-6 (Early June): Sprint 1 – Backend & AI Integration: Focus on building
the backend services. This includes developing the NLP query pipeline: language
detection (to route multi-language queries appropriately), text pre-processing (e.g.,
transliteration if needed for Sindhi/Pashto), and hooking up a retrieval-augmented
generation approach. For instance, implement a module to fetch relevant text
passages from the legal documents or databases based on the query (to feed into the
AI model for context). Develop the initial API that the mobile app will call: an
endpoint like /query that accepts a question and returns an answer. Also, integrate
the MS SQL databases – e.g., write SQL queries or use an ORM to retrieve data (like
 searching persons by name or CNIC). By end of Sprint 1, a rudimentary query on
each data source should work (tested via a backend stub or Postman).
 Weeks 7-8: Sprint 2 – Mobile App (Low-Code) & UI Implementation: Using a
low-code development tool, start building the mobile application according to the
Figma design. For example, using Microsoft Power Apps or a similar tool, create
screens for login (with biometric authentication if needed), query input (text field or
voice input), and results display (list of answers or a detailed answer view). Leverage
the low-code tool’s ability to import the Figma design for accurate UI (Figma
Integration | Thunkable Docs). Implement the logic to call the backend API. This
sprint will also produce the basic web admin panel (e.g., an internal dashboard to
view logs of queries or manage user access). Concurrently, refine the AI model
responses – adjust the prompt format for the model to ensure it cites section
references or highlights the source of information, as needed. Internal testing of the
mobile app on a few devices will begin.
 Weeks 9-10: Sprint 3 – Feature Completion: Add remaining features and polish.
This includes handling edge cases in queries (e.g., if the question is unclear, the
system should ask for clarification or provide multiple options), implementing
multilingual response generation (the answer should ideally come back in the same
language the question was asked, where applicable – e.g., question in Urdu yields
answer in Urdu), and optimizing performance (caching frequent query results, etc.).
Security features are also handled now: ensure authentication is in place for the app
and web panel (likely integrate with Sindh Police’s existing authentication system or a
simple secure login with role-based access). Finish any features on the admin panel
(like user management, usage statistics). By the end of June, the system should be
feature-complete in development, meaning all core user stories are implemented in
some form.

Phase 3 – July 2025: Testing, Deployment, Training

 Weeks 11-12 (Early July): Testing (Sprint 4): Conduct thorough QA testing. A
dedicated QA engineer will perform test cases for each user story: Does a query in
each supported language return a correct answer? Are legal citations accurate? Is the
mobile UI working on various devices (Android/iOS)? We will also do load testing to
validate concurrency: simulate 100 users querying simultaneously and measure
response times, refining the system (maybe adjusting thread pools or caching strategy)
to ensure acceptable performance. Any bugs found are logged as issues and fixed in
this sprint. We’ll also get a small group of actual police officers (beta users) to pilot
the app in a controlled environment and provide feedback on the accuracy and
usefulness of answers.
 Weeks 13- 14: Deployment & User Training: Prepare for production deployment on
the on-prem server. This includes hardening the system (ensuring it runs as a service,
auto-start on server reboot, backup procedures for data indexes, etc.). Deploy the
mobile app to devices – if not going through an app store, we’ll distribute it via MDM
(Mobile Device Management) or direct APK/IPA for iOS via enterprise signing. In
parallel, create training materials (see section 9) and conduct training sessions. For
instance, organize a workshop by mid-July for 20 key officers (who will then train
others). This is also the time to finalize documentation (user guide, admin guide – see
section 10).
 Milestone (End of July): Go-Live – By July 31, 2025, POLARIS v1.0 will be live for
Sindh Police. The final deliverable includes the running system, trained users, and all
 documentation. We will schedule a project closure meeting with stakeholders to
review that objectives were met and outline any post-deployment support or future
enhancements (e.g., proposals for phase 2 if needed).

Note: The project follows agile principles, so while the above timeline is structured by
phases, we will remain flexible. If certain tasks take longer, we’ll adjust scope or schedule
within the 3-month window by reprioritizing features (ensuring core functionality is delivered
first). Regular progress demos will be done at the end of each sprint (bi-weekly) to keep
stakeholders in the loop.

5. Scrum Team Management Plan

We will employ a Scrum Agile methodology to manage this project, using a single cross-
functional Scrum team. Key elements of the management plan:

 Single Scrum Team: All development, AI integration, and design activities will be
handled by one Scrum team comprising 7 members (developers/designers/testers) and
one Product Owner (from the police side, likely an officer or IT lead). This ensures
everyone works off a single prioritized backlog, promoting focus and fast iteration.
There will also be a Scrum Master to facilitate the process.
 Roles and Responsibilities: Each team member has defined roles (detailed in section
7), but the team works collaboratively. The Product Owner (PO) will be a
representative of the Sindh Police (or Police IT) who deeply understands the
requirements and will prioritize the backlog. The Scrum Master (could be the project
manager or tech lead) will run scrum ceremonies and remove impediments.
Developers (AI engineers, app developers, etc.) will self-organize to pick up user
stories each sprint. Everyone will participate in design, development, and testing as
needed to meet sprint goals.
 Ceremonies & Cadence: We plan 2-week sprint cycles (approximately six sprints in
3 months).
o Sprint Planning: At the start of each sprint, the team and PO will select high-
priority user stories from the backlog to implement. Acceptance criteria for
each story will be reviewed (e.g., “Given an officer asks a question in Sindhi,
the system returns an answer in Sindhi with relevant law references” – the
criteria define what success looks like).
o Daily Stand-ups: Every day the team will have a brief stand-up meeting (15
minutes) to synchronize – each member shares what they did yesterday, plans
for today, and any blockers. For example, the ML engineer might say
“Blocking on getting Pashto text to display correctly” and the Scrum Master
will note to resolve that blocker (maybe by consulting a language expert).
o Sprint Review: At the end of the 2-week sprint, we’ll do a live demo of
completed features to stakeholders (including police officials). This
demonstrates progress (like showing the mobile app can answer a query end-
to-end by Sprint 3) and gathers feedback early. The Product Owner will
formally accept completed stories if they meet criteria.
o Sprint Retrospective: After each sprint, the team will meet to reflect on what
went well and what can be improved. For instance, if in Sprint 1 we found
integration with Excel CDRs took longer than expected, we discuss how to
 better estimate or if we need a different approach. Continuous improvement
will be a focus given the tight timeline.
 Backlog Management: All features will be tracked as user stories in a product
backlog, likely using an issue tracking tool (such as Jira, Trello or Azure DevOps
Boards). Each story will be linked to an epic (higher-level feature grouping) and have
tasks as needed. The Product Owner will prioritize this backlog continuously,
ensuring the most critical features (natural language query handling, data integration)
are developed first. Less critical enhancements (nice-to-have features or cosmetic
improvements) will be scheduled later or dropped if time doesn’t permit.
 Communication and Reporting: The Scrum Master/Project Manager will provide
weekly status reports to stakeholders summarizing progress, upcoming work, and any
risks. Because the team is small and co-located (assumed at the Police IT office),
communication will be mostly via daily face-to-face/online meetings and a team chat
(e.g., Microsoft Teams or Slack) for quick questions. The Product Owner is
encouraged to be available for queries or quick decisions throughout the sprints (this
ensures we maintain momentum and alignment with police needs).
 Risk Management: Using Scrum allows early visibility into challenges – if by Sprint
2 we see the chosen AI model is too slow, we can pivot (e.g., fine-tune a smaller
model). The iterative approach means the project can adjust within the 3-month
window rather than discovering issues at the end. The Scrum Master will maintain a
risk log and ensure mitigation actions (for example, have a fallback plan if certain
data isn’t ready in time, etc.).
 Definition of Done: The team will agree on what “Done” means for work items –
typically a user story is done when it is coded, tested (unit/integration tested),
integrated into a build, and accepted by PO. Additionally, for this project, “done”
might include that the feature is documented and that the AI responses are evaluated
for accuracy by domain experts. This clarity ensures quality is maintained.

By following this Scrum management plan, the project remains adaptive and transparent. The
police stakeholders will see continuous progress, and the development team can handle the
complex AI integration in incremental steps, reducing project risk and delivering value within
the short timeframe.

6. Required Skill Set

Building POLARIS demands a multidisciplinary skill set. Below are the key skills and
expertise areas required among team members to successfully develop and deploy the system:

 Natural Language Processing (NLP) & Machine Learning: Deep understanding of

NLP techniques, especially question-answering systems and large language models.
Skills in working with AI models (e.g., experience with PyTorch or TensorFlow,
Hugging Face transformers) to fine-tune or prompt large language models under 40B
parameters. Knowledge of multilingual NLP is crucial (handling Urdu script, Pashto,
Sindhi text). The ML expert should be comfortable optimizing model inference on
CPU (using techniques like quantization or efficient batching).
 Data Engineering & Database Management: Ability to handle large-scale data.
This includes parsing and indexing unstructured data (PDFs, text) and handling
structured data in MS SQL databases. Strong SQL skills are needed to query and
join large tables (0.7M+ records efficiently). Experience with ETL (extract-transform-
load) processes to update or preprocess data (e.g., converting Excel CDR files into a
 queryable format) is needed. Also, familiarity with data cleaning and validation
(ensuring data from disparate sources can be correlated by keys like CNIC, case
number, etc.).
 Backend/API Development: Proficiency in server-side programming (e.g., Python
for an AI service or C#/.NET if integrating with existing systems, depending on tech
chosen) to develop an API layer that interfaces between the AI model, databases, and
client apps. Skills in building RESTful APIs and ensuring secure access
(authentication, encryption). The backend developer should also know how to
integrate with low-code platforms (maybe exposing APIs or using connectors) and
possibly experience in microservice architecture if we break components apart.
 Mobile App Development (Low-Code Platforms): Experience with low-code/no-
code mobile development tools such as Microsoft Power Apps, FlutterFlow,
Mendix, or similar. The developer should understand how to translate Figma designs
into those platforms, use components, and implement logic flows. Skills in mobile
UI/UX design principles (making an app intuitive for non-technical police officers,
with possibly larger text, clear buttons in bilingual labels) are important. If using
Power Apps, knowledge of its formula language and connectors is needed; for
FlutterFlow, knowledge of Flutter basics is useful, etc. The ability to integrate device
capabilities (camera, microphone for voice input, biometric login) via the low-code
tool is also desirable.
 Web Frontend Development: For the admin panel (desktop/web interface), skills in
web technologies (HTML/CSS/JavaScript) or the chosen low-code web builder (could
be same as mobile if platform supports responsive web, or something like Retool).
Understanding of creating responsive dashboards, tables to display records, forms for
search or user admin. This role may overlap with the low-code mobile developer if
one platform handles both.
 UI/UX Design: Strong user experience design skills to craft an interface suitable for
the target users. Proficiency in Figma to create interactive prototypes and design
systems (color palettes, typography that aligns with police branding). The designer
should be adept at designing bilingual interfaces (for example, ensuring UI can
accommodate Urdu right-to-left text and English side by side without breaking
layout). They also need to consider usability in field conditions – high contrast for
outdoor readability, simple navigation for possibly stressful scenarios (like an officer
quickly needing info).
 Quality Assurance (QA) & Testing: Expertise in creating test plans and test cases,
including edge cases for AI systems (e.g., testing queries phrased differently, or in
mixed languages). Familiarity with testing mobile apps (on different devices/OS
versions) and web apps (browser compatibility). Also important is knowledge of
performance testing tools or techniques to simulate concurrent users and measure
system load. Since the system involves AI, the QA person should have an eye for
validating content accuracy (perhaps with the help of domain experts) – e.g., verifying
that if the system cites Section 144 of the code, it indeed matches the text in the legal
PDF.
 DevOps & Deployment: (This might be a secondary skill within the team) –
Knowledge of server administration on the Lenovo SR650 on-prem hardware. This
includes OS management (likely Windows Server for MS SQL, or Linux if we host
the AI service on Linux), setting up runtime environments for the AI model (maybe
using Docker containers or a virtual environment), and ensuring networking (the
mobile app should securely reach the on-prem server). Skills in monitoring and
maintaining an AI service (setting up logs, catching errors, scheduling regular data
 index updates) are also needed. Security know-how is key: configuring firewalls, user
access controls, and data encryption in transit.
 Domain Knowledge (Law Enforcement): While not a technical skill, having
familiarity with police processes and terminology is important. Team members
(especially the BA/PO and QA) should understand concepts like FIR, sections of law,
how police query records, etc. This will help in interpreting user needs and validating
that the system’s answers make sense in context. The Product Owner will mainly
provide this, but developers should be open to learning some domain context.

Each of these skill sets will be represented in the team (one person may cover multiple areas).
For instance, one team member might be both the data engineer and backend developer, or
the Scrum Master might also handle DevOps tasks. The combination of these skills ensures
the team can cover all aspects: from designing a friendly UI to wrangling data and building a
robust AI backend.

7. Team Composition (7 Members + 1 Product Owner)

To optimally execute the project, we propose a team of 7 core members (the Scrum Team)
with a dedicated Product Owner. This ensures all necessary roles are covered while keeping
the team small enough for efficient communication. Here is the recommended team
composition and their primary roles:

Role Count Key Responsibilities and Skills

Responsibilities: Define and prioritize requirements, accept
delivered features. Acts as the voice of the end-user (police
officers) and the stakeholder ensuring the project delivers
1 (from
Product Owner value. Profile:Likely a Sindh Police official or IT liaison with
client
(PO) domain expertise (law enforcement operations and data).
side)
Ensures the system aligns with actual policing needs. Not part of
day-to-day dev, but closely involved in backlog grooming and
reviews.
Responsibilities: Facilitate Scrum ceremonies, remove blockers,
and manage project timeline. Ensures the team adheres to Agile
practices and coordinates across roles. Profile: Could be a
Scrum Master /
1 project manager with Scrum experience or a senior developer
Project Manager
taking on Scrum Master duties. Needs strong communication
and risk management skills. Might also contribute in
development planning (e.g., architecture decisions).
Responsibilities: Selection and setup of the AI model (<=40B
parameters), fine-tuning or prompt engineering it on legal text
Q&A, optimizing inference on the given hardware. Develops the
language understanding and question-answering logic (including
any retrieval mechanisms). Also handles multilingual processing
NLP/AI Specialist
1 (tokenization for Urdu script, etc.) (GitHub -
(ML Engineer)
facebookresearch/XLM: PyTorch original implementation of
Cross-lingual Language Model Pretraining.). Profile: Data
scientist or ML engineer experienced with large language
models, and possibly with knowledge of Urdu/Sindhi text
processing. Works on integrating model with backend API.
 Role Count Key Responsibilities and Skills
Responsibilities: Integrate and manage the databases and data
pipelines. Sets up connections to MS SQL databases, writes
complex queries or stored procedures for retrieving data (e.g.,
search persons by partial name, get all cases for a person, etc.).
Also responsible for processing PDF and Excel data (writing
Data Engineer / scripts to parse PDFs, or converting Excel CDRs into a database
Backend 1 or directly querying them). Ensures data from all sources can be
Developer accessed efficiently. Profile: Strong SQL skills, scripting
(Python or similar) for ETL. This person also builds backend
logic to combine results from AI and DB (for example, merging
an AI textual answer with relevant records). Might double as
the Backend API Developer if skillset overlaps (implementing
the REST API that the app calls).
Responsibilities: Develop the server-side application (the
“brain” that handles incoming queries). Implements API
endpoints (authentication, query submission, returning results).
Orchestrates calls between the AI model and the databases: e.g.,
when a query comes in, it might first fetch relevant data from
the legal text index or DB, feed it to the AI model, then format
Backend/API the model’s answer. Also handles concurrency (making sure
1
Developer multiple requests are handled via threading or async). Takes
care of security in the API (ensuring only authenticated requests
from the app are served). Profile:Experienced in back-end
frameworks (could be Python Flask/FastAPI if using Python for
AI, or Node.js/Java depending on stack). Can be same person as
Data Engineer if full-stack, but ideally separate to focus on
robust API development.
Responsibilities: Build the front-end mobile application for
Android & iOS using low-code tools. Implements the UI screens
Mobile
in line with the Figma design, sets up navigation and form
Application
1 elements for query input. Integrates the app with backend via
Developer (Low-
API calls or using a connector (for example, in Power Apps,
code Specialist)
using a custom connector to call our AI API ([Microsoft Power
Apps Pricing & Benefits Explained
Responsibilities: Design the user interface and ensure a great
user experience. Produces and iterates on Figma designs for the
mobile app and web admin. During development, works with
the developers to adjust designs for technical feasibility. Also
designs logos or icons as needed (like an app icon, or custom
icons for features). Ensures the color palette (blue/red) and fonts
are consistently applied, and that the interface is localized (e.g.,
UI/UX Designer 1
space for longer text in Sindhi script). Conducts usability testing
with sample users and refines the workflow if something is
confusing. Profile: A creative UI/UX specialist familiar with
designing for government or enterprise apps. Proficient in Figma
and knowledgeable about responsive and accessible design.
Even after design phase, remains involved to fine-tune UI
details.
 Role Count Key Responsibilities and Skills
Responsibilities: Plan and execute testing of the entire system.
Writes test cases covering each user story (e.g., “When I ask in
English about a case, I get the correct case details” – and also
tries variations in Urdu, etc.). Performs manual testing on the
mobile app (checking layout on different phones, languages
displayed correctly, etc.) and on the web admin panel. Also
conducts performance and concurrency testing: simulating
multiple users and measuring if response times are within
Quality
acceptable range. Reports bugs in the tracking system and works
Assurance (QA) 1
with developers to clarify and verify fixes. Additionally, the QA
Engineer
will verify the content of answers by comparing with source
data – for critical queries, ensuring the AI’s answer matches the
official record or law text. Profile: A tester with experience in
both web and mobile application testing. Familiar with tools for
load testing and perhaps automation (though in 3 months mostly
manual or script-based testing will be done). Ideally, someone
with basic understanding of Urdu/Sindhi to verify those outputs,
or coordinates with the PO for content verification.

Total = 7 team members + 1 Product Owner.

In practice, some roles might be combined if one person has multiple skills (for example, the
Backend Developer and Data Engineer might be the same individual, and the Scrum Master
could be the Backend lead as well). But we list them distinctly to ensure all responsibilities
are accounted for.

This 7+1 structure is optimal: it covers the full stack (UI, backend, AI, data, testing) without
redundancy. Each member has a clear focus area, and together under the Scrum framework,
they can deliver the complex system in a short time. The Product Owner (not counted among
the 7 dev team members) is crucial for guiding priorities and providing domain input,
ensuring the team builds the right product.

8. Tasks Suitable for Outsourcing

While the core development will be done by the in-house Scrum team, certain smaller or
ancillary tasks can be efficiently outsourced to third-party contractors or specialists.
Outsourcing these can save time for the core team to focus on critical development. Such
tasks include:

 Data Digitization & Cleanup: Preparing the content of the ~200 PDF documents
could be outsourced. For example, if these PDFs are scans or need formatting, a
contractor could convert them to clean text or XML. They could also create a tagged
dataset of sections/clauses for easier indexing. This frees the team from manual data
entry or cleanup work.
 Transcription/Translation Services: If any of the data (like portions of legal text or
user interface strings) need translation between English, Urdu, Sindhi, Pashto, we
might outsource to professional translators. Also, creating a consistent terminology
glossary (like ensuring the legal terms are uniform across languages) could be done
 externally. Similarly, if voice input is to be supported, training data for speech
recognition in these languages could be outsourced to specialists (like recording
utterances).
 UI Graphic Design Assets: While the UI/UX designer will handle overall design,
specific graphic assets might be outsourced. For instance, designing a logo for the app
or custom icons/illustrations (perhaps an icon for the POLARIS app, or tutorial
infographics) could be given to a freelance graphic designer. This ensures high-
quality visuals and lets the UI/UX designer focus on the user flow.
 Video Tutorial Production: Creating the training video content (outlined in section
9) can be outsourced to a multimedia production team. For example, after we script
the usage scenarios, a video producer can film or animate the scenario of a police
officer using the app, add voiceover in Urdu/Sindhi, and edit it professionally. This
would result in a polished training video. Outsourcing here is practical as it requires
video editing expertise and possibly on-site filming which a dedicated team can
handle better.
 User Testing (Beta Testing): We can engage an external group of testers for a short
period to do usability testing. This could be a small firm or group that specializes in
testing apps with end-users. They can simulate being police officers (or ideally actual
off-duty officers as contractors) trying the app and provide unbiased feedback on user
experience, which can then be fed into improvements. This is semi-outsourcing as it’s
orchestrated by us but executed by external participants.
 Content Writing (Documentation): Preparing user manuals, help center FAQs, or
technical documentation could be partially outsourced to technical writers. For
instance, once the team provides the raw info, a technical writing consultant can
format it into a professional handbook in English, and even translate it to Urdu for
officer training material. This ensures clear, user-friendly documentation (and saves
developer time).
 Infrastructure Setup/Maintenance: Although core deployment is in-scope, some
organizations outsource parts of IT setup. We might outsource the server room
setup or network configuration (setting up the server hardware, backups, failover) to
an IT services company. This ensures the Lenovo server and network are properly
configured for production use (power, cooling, rack installation, etc.), while the dev
team focuses on software.
 Minor Coding Tasks or Integrations: If during development we identify a very
specific task that’s time-consuming but well-defined (e.g., writing a script to convert
all old case files from one format to another), we could outsource that small
development task to a contractor with clear specifications. The contractor’s output
would then be reviewed and integrated by our team.

Each outsourced task will be clearly defined with expected outputs and timelines to avoid
delays. By outsourcing these non-core tasks, the main team can maintain velocity on the
primary development and integration work. It’s important to manage the outsourced tasks
closely (perhaps assign a team member to liaise) to ensure quality and that they align with
project needs.

9. Training and Tutorial Strategy

Introducing POLARIS to police officers will require a thoughtful training approach. We plan
to create video tutorials and training materials to ensure users quickly learn how to use the
system effectively:
 Interactive Video Tutorials: Short, scenario-based videos (3-5 minutes each) will
demonstrate common use cases. For example, one tutorial video will show an officer
finding legal sections: “How to query the law database” – the video will depict an
officer typing an Urdu question about a law, and the app responding with the relevant
section. Another video might cover “Using POLARIS during an investigation” –
showing an officer retrieving a suspect’s call records via the app. These videos will be
narrated in Urdu (or Sindhi) for accessibility, with English subtitles if needed for
formal training sessions. By using realistic scenarios and a story format, officers can
relate the training to their daily job. We will ensure the pace is easy to follow, with UI
screen recordings and callouts (highlighting where to tap, etc.).
 Modular Training Content: The training will be broken into modules, each
focusing on a feature:
o Module 1: Logging in and App Navigation (how to authenticate, switch
languages, navigate the menu).
o Module 2: Asking Questions & Viewing Answers – tips on phrasing questions,
using voice vs text input, understanding the answer layout (e.g., law
references, database info in the answer).
o Module 3: Advanced Query Techniques – for example, how to filter queries
(asking for a date range in a question) or follow-up questions.
o Module 4: Admin Panel Usage (for authorized users) – how to view query
logs, manage user permissions, etc. Each module will have an accompanying
video and a one-page quick reference.
 Language and Clarity: Training materials (videos, guides) will primarily be
in Urdu and Sindhi since many officers are more comfortable in local languages. We
will use simple language, avoiding technical jargon. For instance, we’ll say “ ‫آپ ایسے‬
‫سوال پوچھ سکتے ہیں‬:” (“You can ask questions like this:”) rather than explaining “natural
language processing”. The idea is to build confidence that the system understands
them. Any on-screen text in the tutorials will also be in local language if it’s
demonstrating the app interface.
 Hands-On Workshops: In addition to videos, we propose running a few in-person
(or live online) training sessions. These could be train-the-trainer style: gather key
personnel from various districts, give them a half-day workshop using POLARIS, and
then they become champions who train their colleagues. During these workshops,
participants will watch the tutorial videos, then practice on training devices with the
app (with guided exercises such as “Find if John Doe was ever arrested before – now
try in Sindhi!”). This blended approach (video + live practice) reinforces learning.
 In-App Help and FAQ: The mobile app will include a Help section, likely a simple
FAQ or tips. We’ll populate it with frequently asked questions and answers (e.g., “Q:
What if I get no answer? A: Try rephrasing your question or check spelling.”). This
acts as on-the-spot guidance. We will also embed links to the tutorial videos in the
app help, if possible, so officers can watch them on their phone. For instance, a
“Watch how to use this app” link that plays the intro tutorial.
 Instructional PDF/Quick Cards: Some officers might prefer traditional materials.
We’ll prepare a concise User Guide PDF (10-15 pages with screenshots) in English
and Urdu. Additionally, a one-page “cheat sheet” could be given – a laminated card
that lists voice commands or example queries, and contact info for support. This cheat
sheet can be kept by officers for quick reference in the field.
 Follow-Up and Feedback: After deployment, the training doesn’t stop. We’ll set up
a feedback channel (maybe a dedicated WhatsApp group or an internal helpline)
where officers can ask questions if they’re confused. We plan to observe how new
 users interact with the system and maybe send out a short survey after a month to
gauge if they need any refresher training or additional tutorials on advanced features.
We could then make a second round of videos addressing any commonly
misunderstood points.
 Video Distribution: The tutorial videos will be made easily accessible – possibly
uploaded to an internal police portal or an unlisted YouTube/Vimeo link (if internet
access is available). They will also be distributed as files that can be played on
computers in police stations or on officers’ smartphones. During roll-out, we expect
each station or unit to have a session where these videos are shown and discussed.
 Admin/IT Training: Separate short training will be provided for IT staff or the
admin users on the system maintenance. This might include a tutorial on how to
update the legal documents repository when new laws are added, how to interpret
system logs, etc. This ensures the system can be smoothly operated and updated post-
launch.

By providing engaging video content and written guides, we cater to different learning
preferences. The overall goal is that every intended user knows when and how to use
POLARIS as part of their routine. Effective training will drive adoption, ensuring the
system’s benefits (speed, information access) are fully realized in day-to-day policing.

10. Documentation Strategy

Comprehensive documentation is critical for the success and maintainability of POLARIS.
We will pursue a two-pronged documentation strategy addressing both technical
documentation for developers/maintainers and user documentationfor end-users (police
officers and administrators). Key elements of the documentation strategy include:

 Living Project Documentation (Wiki): Throughout development, we will maintain a

project wiki (e.g., on Confluence or a GitHub/GitLab Wiki) accessible to the team and
stakeholders. This will include the evolving architecture diagrams, decisions made
(ADR – Architecture Decision Records), and how components interact. For example,
a page detailing “NLP Pipeline Architecture” will describe how a query flows from
the mobile app to the backend to the AI model and back, including sequence
diagrams. Keeping this up-to-date in real time ensures the whole team has a reference
and new developers can onboard quickly.
 Code Documentation: Developers will follow best practices for self-documenting
code: clear naming conventions and comments where non-obvious logic occurs. For
complex modules (like the query parser or the AI inference service), we will include
module-level docstrings/header comments explaining the purpose and usage. We plan
to use tools to generate documentation from code where possible. For example, if the
backend is in Python, we can use Sphinx to generate HTML docs from the docstrings,
or if .NET, use XML comments to generate docs. This ensures that the final codebase
has an accompanying API reference (listing all classes, methods, and their
descriptions).
 System Architecture & Deployment Guide: A technical manual will be written to
cover system architecture and deployment details. This will include:
o Architecture Diagram: showing all components (mobile app, web app, API
server, AI model, databases) and their relationships.
 o Deployment Steps: how to set up the system on a new server. For instance,
“Install Windows Server 2022, configure MS SQL, then run installer for
POLARIS backend or Docker compose up, etc.” It will list prerequisites like
specific OS settings, how to deploy updates, and how to start/stop services.
o Configuration Guide: Document any configuration files (like if there’s a
config for database connection strings, or a language model path). Also
include how to switch the model to a new one or retrain it, if needed, for IT
staff.
o Backup/Restore Procedures: Instructions on backing up the databases (likely
existing procedures in place for police DB, but ensure any new data like an
index or logs are backed up). And how to recover in case of system failure.
 User Manuals: We will deliver user-facing documentation in a clean, easy-to-read
format:
o Police Officer User Guide: A manual explaining how to use the mobile app.
It will mirror the training content but in reference form – e.g., chapters for
“Logging In,” “Asking a Question,” “Understanding the Answer,”
“Troubleshooting” (what to do if a query fails or if data seems wrong). This
guide will be written in English and then translated to Urdu and Sindhi for
wider accessibility. It will be provided as a PDF and possibly printed booklet
for distribution in police stations.
o Admin Panel Guide: Since the admin interface may be used by a smaller
IT/admin group, a guide for it will be made. This includes how to manage user
accounts (if that feature exists), view system logs or usage statistics, and any
maintenance tasks through the UI.
 Inline App Help: As mentioned, the app itself will contain short instructions or
tooltips. We will document these in the design so they are consistent. (For instance, a
tooltip icon next to the query box that says “‫“ – ” آپ یہاں اپنا سوال لکھیں‬Type your question
here”). All such inline help text will be listed in a document for translation
consistency and future reference.
 API Documentation: If the backend provides APIs (which it does for the app), we
will document these endpoints. We might produce a swagger/OpenAPI
documentation that describes the endpoints, request/response formats, and example
calls. This is useful if later integration with other systems is desired, or simply for the
team to test the endpoints. This documentation can be published on an internal URL
(like a swagger UI) or as part of the technical docs.
 Change Log & Versioning: We will maintain a CHANGELOG file or page that
tracks changes by version. Given the timeline, probably we will have an initial
version 1.0 release. But during development, internal versions (0.1, 0.2 etc.) will note
what features were added/fixed. This habit is useful post-deployment to track
enhancements or bug fixes.
 Issue Tracker and Resolutions: Although not traditional documentation, our use of
an issue tracker (JIRA or similar) will indirectly document issues and their fixes. We
will ensure to write clear issue descriptions and resolutions. Post-project, these can
serve as knowledge base (e.g., Issue #25: “Fixed Unicode bug for Sindhi text input –
cause and solution described”). This can help future developers avoid reintroducing
known issues.
 Hand-over Knowledge Transfer: At project close, we will conduct a documentation
handover session with the Police IT team. We’ll walk through the key documents and
perhaps record this session. This, combined with written docs, ensures that the
organization’s IT staff can understand and manage the system going forward.
  Documentation Maintenance: We will advise the client on keeping docs up to date.
For example, if new legal documents are added to the system after a year, the “Data
Sources” section of the documentation should be updated accordingly. Perhaps
designate someone in IT as a documentation owner. We’ll use version control for
documentation (maybe storing it in a repository) so changes are tracked.

All documentation will be delivered in standard formats (PDF/DOCX for manuals, HTML
for generated tech docs, etc.) and organized clearly (we might deliver a zip file or a
knowledge base link with categorized docs). The strategy ensures that six months or a year
later, any new team or existing IT personnel can refer to documentation to understand how
POLARIS works, how to use it, and how to troubleshoot or extend it. This reduces long-term
dependency on the original developers and contributes to the sustainability of the project.

11. Development Workflow: User Stories, Epics, Issues,

Tasks
We will structure the development work using Agile principles, breaking everything down
into Epics, User Stories, and Tasks. The idea is to maintain clarity on what needs to be done
at every level and ensure traceability from high-level requirements to implementation. Here’s
how we’ll organize and execute the work items:

 Epics: Epics are large feature areas or goals, each encompassing multiple user stories.
We have identified epics that align with the major functional areas of POLARIS. For
example:
o Epic 1: Multilingual Query Handling – covers everything related to
understanding questions in Urdu/Sindhi/Pashto/English and responding
appropriately.
o Epic 2: Legal Documents QA – covers the ability to ask questions about legal
acts/sections and retrieve answers from the 200 PDFs.
o Epic 3: CDR Analysis – covers queries on the call detail records (Excel
integration and query logic).
o Epic 4: Police Records Search – covers querying the SQL databases (persons,
cases, etc. and any relational queries between them).
o Epic 5: Mobile App Interface – covers building the front-end application
features (UI screens, login, query input UX, results display).
o Epic 6: Admin & Security – covers user management, auditing, admin panel
features, and security aspects like authentication and permissions.
o Epic 7: Performance & Concurrency – covers non-functional requirements
like handling 100 users, optimizing speed, etc. Each epic will be tracked in our
project tool, and we’ll periodically review epic progress with stakeholders
(e.g., by end of June, Epics 1-5 should be completed for a releasable product).
 User Stories: Under each epic, we will write user stories that follow the classic
format “As a [type of user], I want [some goal] so that [reason].” These stories
capture specific functionalities from the end-user perspective. For instance:
o Under Multilingual Query Handling: “As a police officer, I want to ask a
question in Sindhi and receive the answer in Sindhi, so I can use the app in my
preferred language.”
o Under Legal Documents QA: “As an investigator, I want to ask what law
applies to a scenario (e.g., an unlicensed weapon) and get the relevant
 Act/Section and punishment details.” (This would involve parsing the law
documents).
o Under CDR Analysis: “As an officer, I want to input a phone number and a
date range to see if that number appears in the call records of a case.”
o Under Records Search: “As an investigator, I want to know if a suspect has
prior arrests by querying their name or ID, so that I’m aware of their history
on the spot.”
o Under Mobile App: “As a user, I want to login with my police ID and
biometric verification, so that the app is secure and only I can access it.”;
another could be “As a user, I want to view a list of recent queries I made, so I
can tap and re-run a previous query.”
o Under Admin & Security: “As an admin, I want to see a log of queries made
(time, user, query) so that I can audit usage for any misuse.” We will ensure
each story has clear acceptance criteria. For example, acceptance criteria for
the Sindhi query story might be: (1) User sets language to Sindhi, asks a
question in Sindhi script. (2) System returns an answer in Sindhi that correctly
addresses the question. (3) If the answer is sourced from law text, it appears in
Sindhi if available or transliterated if not.
 Issues/Tasks: Each user story will be broken down into tasks (issues) that developers
can pick up. Tasks are the actionable to-dos needed to fulfill the story. For example,
for the story “ask a question in Sindhi and get answer in Sindhi,” tasks might include:

1. Integrate language detection library to identify Sindhi vs Urdu vs English

input.
2. Ensure the chosen language model or pipeline can output Sindhi (this might
involve fine-tuning or adding a translation step).
3. UI task: Add a language switch or auto-detect feature in the app interface.
4. Testing task: Create test queries in Sindhi to verify the end-to-end flow. Each
task will be tracked as an issue in our system (with a unique ID). No subtasks
will be separately managed; we consider tasks as the smallest unit. So if a task
is complex, we’ll word it as a single clear action. If it seems to need subtasks,
we’ll actually break it into multiple tasks instead.

 No Subtasks Policy: As requested, we will avoid deep hierarchies of subtasks to keep

it simple. Essentially, our hierarchy stops at tasks under stories. If something is too
big, it’s a story or an epic, not a task. This clarity prevents things from getting lost.
Our development board will thus have Epics -> Stories -> Tasks. Example mapping:
Epic “Mobile App Interface” -> Story “Login with biometric” -> Tasks like
“Implement fingerprint API call (Android)”, “Implement FaceID (iOS)”, “Design
login screen UI in Figma (done)”, “Connect login API to backend”.
 Traceability: We’ll maintain links between each story and the epic it belongs to, and
between tasks and their parent story. This way, at any time, anyone can trace why a
task is being done (which user need it serves). We also ensure that for every
requirement mentioned in this document or by stakeholders, there is a corresponding
user story or epic – nothing falls through the cracks.
 Issue Tracking Tools & Workflow: We will use a tool like Jira or Azure DevOps.
Each issue (task or story) will have statuses (To Do, In Progress, In Review/Test,
Done). As the team works, we’ll move tasks through these statuses. The Scrum
Master will monitor progress via burn-down charts, etc., which are byproducts of
 updating these tasks. We will also tag tasks with any relevant labels (e.g., “UI”,
“Backend”, “AI”) so we can filter if needed to see all AI-related tasks, for example.
 Examples of Stories and Tasks (illustrative):
o Story: “As a user, I want to use voice input to ask a question so that I can use
the app hands-free.”
 Tasks: Implement microphone permission and recording in app;
Integrate speech-to-text service (perhaps offline library or an API if
allowed) for Urdu voice; Map the transcribed text to the query
pipeline; Test with sample voice queries.
o Story: “As a system, I want to ensure no two users have the same session, so
that queries don’t mix up data.” (This is more of a technical story ensuring
multi-user isolation).
 Tasks: Implement token-based authentication; Maintain session
context in the backend for personalization if needed; Write unit tests
for auth workflow.
o Story: “As an officer, I want to get clarifying questions if my query is
ambiguous (e.g., just one word), so that I can refine it.”
 Tasks: Define rule for detecting ambiguous queries (maybe length < 3
words); Implement response that prompts user (“Did you mean X or
Y?”); Update UI to handle follow-up selection.
 Review and Adaptation: We’ll have the Product Owner review and accept user
stories when done (during sprint reviews). If new requirements emerge or changes are
needed (likely in such innovative projects), we’ll write new stories or adjust existing
ones, and re-prioritize epics if necessary. For instance, if during beta testing we
discover officers want a feature to export results as PDF, we’d create a story “As a
user, I want to export an answer to PDF to attach in case files” and schedule it if time
permits or note it for a future phase.
 No Gold-Plating: Every task will tie back to a user need. We will avoid doing work
that doesn’t map to a story in the backlog. This prevents scope creep. Developers will
be encouraged to always know which story their current task is serving. The Scrum
Master/PM will oversee that our daily work corresponds with the defined tasks (no
one going off to build a “cool feature” that wasn’t agreed upon).

By using this structured workflow, we maintain clarity and focus. The user stories keep us
user-centric, epics ensure we see the big picture, and tasks break down the complexity for
execution. This approach also makes progress measurable (we can count done stories,
burndown tasks, etc.) and ensures by project’s end we have implemented all required
functionality methodically.

12. Identified Entities (Data and Domain Model)

POLARIS will interact with various data entities drawn from the police domain and the
integrated data sources. Identifying these entities clearly is important for database design, AI
training, and ensuring comprehensive coverage of the domain. Below are the primary entities
in our system, along with a brief description of each:

 Law/Act Section – Represents a specific section or clause in a legal document.

Attributes include Act Name (e.g., “Pakistan Penal Code”), Section Number (e.g.,
144), Section Title, and Section Text (the full description of that law section). We will
 also capture metadata like the PDF document reference and page number. This entity
is used when answering legal questions; the AI might fetch a Section entity to quote
the law. For example, Section 144 might have attributes: Act = “Criminal Procedure
Code”, Text = “Whoever, being armed with any deadly weapon... [punishment
details]”.
 Police Case (FIR) – Represents a police case record, often initiated by an FIR (First
Information Report). Attributes could include Case/FIR Number, Date, Police Station,
Crime Type, Status (open, under investigation, challaned to court, etc.), and a
summary of charges. It may also link to persons (accused, complainant, victims). This
entity is what officers query to get case histories. For instance, an officer asking
“detail of FIR 123/2021” would retrieve this entity’s details. The existing ~0.6M
records in the police case database map here.
 Person (Individual) – Represents an individual who might appear in police records,
such as an arrested person, suspect, or wanted criminal. Attributes: Name (with
possible aliases), CNIC (national ID) or other identifier, Date of Birth, Address, and a
list of associated case IDs or arrest records. The ~0.7M arrested persons records fall
under this entity. We will also consider sub-roles: whether the person was accused,
witness, etc., though that might be relation rather than attribute. When an officer asks
“Who is John Doe?” the system might pull up the Person entity with all known info
and maybe a summary of past records.
 Call Record (CDR Entry) – Represents a single call detail record entry. Attributes
include Phone Number (calling), Phone Number (called party), Timestamp/Date,
Duration, and perhaps cell tower location (if available in data). Since CDRs are in
Excel per case, we might import them into a structure where each row is a Call
Record linked to a case or Person. For example, if querying “show calls between A
and B”, the system will filter these entities where (Number = A and Other Number =
B or vice versa). We might have millions of such records if we ingest all Excel files,
but since it’s per case, we might handle them on the fly. Still, conceptually it’s an
entity.
 Police Officer (User) – Represents a user of the system (police official). Attributes:
Name, Rank, Badge/ID, Station/Unit, and login credentials/permissions. Also,
possibly language preference for the app. While not part of the data the system
searches, this entity is important for security and auditing – we’ll log which Officer
queried what. For admin functions, an Officer entity with role “Admin” might have
rights to view logs. Product Owner will decide if every officer gets an account or it’s
device-based auth, but likely an entity exists for each user.
 Query (Interaction) – Represents a user query instance and its result. Attributes:
Query Text, Language, Timestamp, User (link to Officer), and perhaps the Results or
Answer given. We consider this an entity from a logging perspective. It’s not
something pre-existing in databases but something we will generate and store for
audit. If an issue arises (like incorrect answer), admins can review the Query log. This
can also help train the AI further by analyzing queries.
 Legal Document – We have Law/Act Section as fine-grained, but also the overall
document (like “Sindh Arms Act 2013 (PDF)” as an entity for reference). Attributes:
Title of document, publication year, maybe a category (Criminal Law, Procedural
Law, etc.). We might not need this explicitly in the system, but it’s useful for
organization. For example, the app might allow browsing acts by name. This entity
would group Section entities.
 Location/Police Station – This is a minor entity but in case data we’ll have police
station or district. If queries like “cases reported in Karachi in Jan 2025” were to be
 supported, we’d use this. Attributes: Name of station/district, location. It links to
cases. Given our focus is more on specific retrieval, we might not have many queries
by location right now, but it’s part of the data model in cases.
 Vehicle – If included in the “4 million other records”, there might be stolen vehicle
data or registration records. For completeness: Attributes: Registration number,
Make/Model, Owner, Status (stolen/recovered). This would be used if an officer
queries a plate number. The Talaash app example included vehicle checks (Sindh
police launch Talaash app with record of 1.5m criminals). If our scope includes it
(depending on that other data), we treat it as an entity.
 Fingerprint/Biometric Record – Possibly, in arrested persons DB, biometric
references (fingerprint IDs or NIC) exist. In Talaash they had biometric verification
(Sindh police launch Talaash app with record of 1.5m criminals). If relevant, an entity
“BiometricRecord” linking a fingerprint ID to a person could exist. But unless we
integrate fingerprint scanners, this might not surface in our user queries, so likely not
used directly in NLP queries (more of a background verification entity).
 UserFeedback/Issue – We may include an entity for feedback if officers can flag an
answer as incorrect or send a correction. While not initially planned, it’s worth noting
as an extension: attributes would be user, query, their feedback comment. This could
help continual improvement but may be outside initial scope.

Relationships between these entities:

 A Person can be associated with one or many Cases (as accused or victim, etc.). A
Case can have multiple Persons. We will mirror these links from the police DB.
 A Case can have many Call Records (if we tie CDRs to case ID).
 An Officer (user) can perform many Query interactions.
 Law Sections are standalone but might reference each other (e.g., a compound section
or schedule). We might not explicitly model that relation unless needed (not likely
needed for the queries, as long as text search works).
 If modeling, Case could link to law sections for charges applied, but in practice, that
might be in narrative or charge sheets, which we aren’t explicitly loading now.
 Station would link to Cases (one-to-many).
 Vehicle could link to Person (owner) and possibly Case (if a stolen vehicle case).
 Officer could link to Case as Investigating Officer, but that’s not likely needed for
queries (the queries from an officer likely aren’t about who the IO is; they’d know
that).

By identifying these entities, we ensure our system design (both database indexing and the
AI’s knowledge representation) covers them. The AI model itself will not explicitly know an
“entity” in database terms, but through the retrieval system, when a question is asked, we
essentially fetch instances of these entities to feed into the answer. For example, a query
“What is John Doe’s criminal history?” will retrieve Person entity for John Doe and related
Case entities, then the AI will compose an answer.

We will maintain an entity mapping document that maps fields from the existing databases
and documents to these conceptual entities. This way, when parsing data or building the
knowledge base, developers know where each piece fits.
Clear entity identification also helps in the testing phase – we can ensure we have test
queries that cover each entity type (laws, cases, persons, calls, etc.) to verify all are handled
correctly by the system.

13. Concurrency and User Load Validation

One of the system requirements is supporting 100 concurrent users. We have to ensure that
POLARIS’s architecture and deployment can handle this load, or clarify what the realistic
limits are on the given infrastructure. Here’s our assessment and plan for concurrency:

 Understanding “100 Concurrent Users”: In practical terms, 100 concurrent users

means up to 100 police officers might be using the app around the same time. This
does not necessarily mean 100 queries being processed in the exact same millisecond,
but rather that up to 100 users could be logged in and sending requests within the
same general timeframe (e.g., during peak hours). We anticipate usage patterns such
that queries are somewhat sporadic – an officer might ask a question, get an answer,
maybe ask a follow-up, then not use it for a little while. So, concurrency in terms of
active requests might be, say, 5-20 truly simultaneous queries at any instant, and 100
users over a minute or so.
 Server Hardware Capability: The Lenovo SR650 V3 server (64-core Intel Xeon, 1
TB RAM) is quite powerful in terms of CPU and memory. Memory is abundant for
our AI model (even a 40B parameter model will fit in <1/4 of that RAM, leaving
headroom for caching data) (Welcoming Mistral, Phi, Jais, Code Llama, NVIDIA
Nemotron, and more to the Azure AI Model Catalog | Microsoft Community Hub).
CPU with 64 cores means we can handle multiple threads in parallel. We will run the
backend such that it utilizes multi-threading or asynchronous processing, allowing
multiple queries to be handled concurrently. For example, we might allow up to 16
threads for query processing, which means up to 16 heavy AI inference tasks at once.
 AI Model Performance: The AI model is the heaviest component. A large model
(like ~30-40B parameters) on CPU might take a few seconds to generate an answer
for a single query (depending on how it’s optimized). We will optimize this by:
o Using quantization or optimized libraries to speed up inference.
o Potentially using a smaller model if needed (the requirement allows suggesting
a modern smaller model if performance is an issue). For instance, a 7B or 13B
parameter model fine-tuned on our domain could be used, which would
respond faster and use less CPU, enabling more concurrent instances. There
are newer models like Mistral 7B that offer faster inference through efficient
attention mechanisms (Welcoming Mistral, Phi, Jais, Code Llama, NVIDIA
Nemotron, and more to the Azure AI Model Catalog | Microsoft Community
Hub).
o If one instance of the model isn’t enough for concurrency, we could
run multiple instances of the model in parallel processes (since we have huge
RAM, we could theoretically load, say, two different smaller models or two
instances of the same model in memory, and distribute queries among them).
 Throughput Estimates: Suppose a single query to the AI (with retrieval and answer
generation) takes ~5 seconds on average. If we have 10 parallel threads, we might
achieve roughly 2 queries per second throughput. Over a minute, that’s 120 queries.
It’s unlikely all 100 users fire queries continuously; typical usage might be each user
making a query, waiting, reading, maybe making another. So 120 QPM (queries per
 minute) likely covers 100 active users easily. We will test specifically with 100
concurrent simulated users issuing queries in a tight loop to see how the system holds
up. Our goal is to ensure the 95th percentile response time stays within an
acceptable range (say under 5-8 seconds) with 100 users.
 Bottleneck Analysis: The potential bottlenecks are:
o CPU (for AI and query processing): With 64 cores, we should be able to
handle dozens of threads. We will monitor CPU usage under load. If CPU
saturates at, say, 80% with 10 concurrent heavy queries, that might be our soft
limit. We can then decide to queue any beyond that concurrency (like have a
request wait in line a moment).
o Memory: 1TB is more than enough for the model and data indices, and some
overhead. Even with 100 users, memory won’t dynamically inflate drastically,
it’s mostly static usage for model and data. So we’re safe on memory.
o Disk I/O: The 4x1.9TB HDD (likely in RAID) is for storage. As long as our
indices and model are loaded into memory, disk I/O will not be heavy except
for logging. We might consider using one of the drives as an SSD or ensure
fast read for initial load. But query-time disk access will be minimal (maybe
for retrieving a PDF snippet, but we can cache those in RAM too).
o Network: All usage is internal (mobile devices connecting likely over a secure
network/VPN to the server). 100 users with text queries and text responses is
negligible bandwidth (a few KB per query). So network is fine. We will
ensure the server’s network interface can handle 100 simultaneous
connections (which is trivial for any modern NIC).
 Validation Plan: We will carry out a load test in the testing phase. Using a tool like
JMeter or Locust, we can simulate 100 users hitting the query API. We’ll prepare a
mix of queries (some simple, some complex) and run them in parallel to see how the
system behaves. We’ll measure response times and system resource usage. If we find,
for example, that beyond 50 concurrent requests the response time spikes to 15
seconds, we’ll investigate mitigations:
o Could we use asynchronous processing and stream partial results? Possibly not
needed for Q&A, but as a fallback maybe we show a “processing” indicator to
users for longer.
o Could we offload some queries that are simple directly to the database without
AI? Yes: e.g., a query that looks exactly like a name search could be answered
by a direct DB lookup faster. We can incorporate such shortcuts to lighten the
AI load.
o If absolutely needed, we might have to acknowledge a limitation or suggest
adding GPU accelerators. But given the hardware, we expect to manage 100
user load with careful optimization.
 Realistic Max Concurrency: With the above, we are confident 100 concurrent users
is achievable. If usage grew beyond that, say 200-300 users, the server might start
queuing requests. We’d state that the system in current single-server setup might
practically support around 100 active users with moderate query loads comfortably.
If substantially more concurrency is needed in future, scaling out would be the
approach (e.g., deploy a second server in cluster or add a GPU for the AI).
 Concurrent Access to Data: Since many will be hitting the same databases, we
ensure our SQL queries are optimized (use proper indexes on names, etc.). 100
concurrent DB queries is not heavy for a well-indexed SQL Server on such hardware,
as long as queries are simple (which they will be, mostly primary key or indexed field
 lookups). We’ll also use connection pooling in the backend to manage DB
connections efficiently.
 Session Management: We will not use heavy server-side session storage; each query
is stateless (except authentication token). This statelessness helps with concurrency
because the server doesn’t have to manage a lot of session data for 100 users – each
request is handled independently.
 Result Caching: For popular or repeated queries (maybe many might ask about the
same notorious criminal or same law section), we can cache those results in memory.
That way, if 5 officers coincidentally ask “What is Section 144?” around the same
time, the first query’s answer is cached and the next ones are served instantly from
cache. This drastically cuts down processing for duplicate queries, effectively
increasing throughput. We’ll consider a cache with a short TTL (time-to-live) for
answers.
 Worst-case Fallback: If many simultaneous requests do come in beyond capacity,
we’ll ensure the system degrades gracefully. Perhaps the 101st user’s request waits a
couple seconds in a queue rather than crashing the server. We’ll implement a request
throttle if needed (returning a busy indicator or message if truly flooded, which is
unlikely in this context, but we’ll plan for it).
 Conclusion on Limit: Based on the above, we will validate that 100 concurrent
users can be supported on the given infrastructure. Preliminary analysis suggests it’s
feasible, and our testing will confirm it. We anticipate that if queries are complex
narratives, response time might lengthen, but still within acceptable range for field use
(getting an answer in ~5-10 seconds is usually fine for officers). If queries are simpler
or if we use a lean model, responses will be faster (1-3 seconds). The system as
architected is likely to handle even slightly above 100 concurrent users, but for
transparency we’ll specify that beyond 100 simultaneous active queries, the
performance may start to degrade.
 Monitoring in Production: We will include monitoring tools or logs to keep track of
how many concurrent sessions/requests are active and how the system performs. This
will allow Sindh Police IT to observe real usage patterns and confirm that the system
remains within healthy limits. If needed, they could schedule heavy analytic queries
during off-peak or add hardware for more headroom.

In summary, yes – with the planned optimizations, POLARIS is expected to handle 100
concurrent users. The limit is primarily the AI processing; with our approach (and given that
not all 100 will hammer at once usually), we are within safe operating bounds. Should usage
intensity exceed expectations, we will advise on scaling strategies, but for the project
requirement of 100 concurrent users, the solution is valid and tested to perform.

14. Licensing and Software Costs (2-Year Breakdown)

Below is a breakdown of anticipated licensing, subscription, and software costs for POLARIS
over a 2-year period. All costs are estimated in USD and assume usage for 24 months post-
deployment. (Hardware costs are included for completeness as a one-time expense.)

Cost
Item / Software Type Estimate Notes
(2 Years)
Lenovo ThinkSystem Hardware (One- $25,000 High-end server with 64-core
 Cost
Item / Software Type Estimate Notes
(2 Years)
CPUs, 1TB RAM, 4x1.9TB
HDD. This is a one-time capital
SR650 V3 Server time) (approx.)
cost. (Includes standard 3-year
warranty).
License for server OS (if
required for MS SQL and
general environment). This
Windows Server 2022
License (Perpetual) ~$1,200 covers the physical server.
(Datacenter Edition)
(Sindh Police may have existing
licenses via an agreement,
otherwise a purchase.)
We assume the police
department already has SQL
Server licensed for their
databases. If not, a 64-core
Microsoft SQL Server License (Perpetual / Assumed
enterprise license could be
2019/2022 Core-based) existing
significant (>$100k). In this
plan, we consider it an existing
resource, hence not budgeting
anew.
We will use an open-source large
language model (Falcon-40B or
similar) which is **Apache 2.0
AI Model Software(e.g., Open-Source licensed (free for commercial
$0
Falcon-40B) License use) ([Welcoming Mistral, Phi,
Jais, Code Llama, NVIDIA
Nemotron, and more to the
Azure AI Model Catalog
Assuming we use Power Apps:
Low-Code Mobile App priced at ~$20/user/month for
Subscription (Cloud $48,000for
Platform (e.g., Microsoft unlimited apps ([Microsoft
or On-prem) 2 years
Power Apps) Power Apps Pricing & Benefits
Explained
Figma Professional plan at about
$12/editor/month (annual billing)
(Figma Pricing: Which Pricing
Plan to Choose? [2025]). For
e.g., 3 team members (UI
~$864 for 2
Figma (Design Tool) Subscription designer + 2 others
years
collaborating) = $36/month,
~$432/year. Two-year cost
~$864. (If using free plan, this
could be $0, but Professional
gives better collaboration.)
Domain SSL Subscription ~$100 If the server API is exposed over
Certificate (for secure (annual) HTTPS (VPN or intranet), a SSL
 Cost
Item / Software Type Estimate Notes
(2 Years)
certificate might be needed
(could use a government CA or
Let’s Encrypt free). We allocate
connections)
~$50/year if a commercial
certificate is used, so ~$100 for 2
years.
We will use open-source or
already-owned tools: e.g., VS
Development Code (free), Android Studio
Licenses $0
Tools(IDEs, etc.) (free) for any custom work,
Postman (free), etc. No
additional cost.
We plan to use open-source
solutions for monitoring (e.g.,
Monitoring/Logging
Open-Source $0 ELK stack for logs or Windows
Software
Performance Monitor) if needed.
No license cost.
Cost to produce professional
training videos by a third-party.
Assuming two short videos,
Video Tutorial including shooting/editing,
~$2,000
Production(outsourced Service Cost roughly $1000 each. This is a
(one-time)
one-time) one-time cost (not a software
license, but included as it is
project-related cost within 2
years, mainly upfront).
All programming libraries and
frameworks (Python libraries for
NLP, .NET runtime if used, etc.)
Misc. Software(libraries,
Open-Source $0 are free. For instance, Apache
etc.)
PDFBox for parsing PDFs,
PyTorch for AI, etc., are open
source.
The above does not include
human support contracts. If an
Maintenance & external support or cloud backup
Not
Support (Optional Service/Subcription service were needed, that would
included
extension) be extra. For now, assume the
police IT team handles
maintenance.

Total Estimated 2-Year Cost: ~$74,000 (plus any assumed existing licenses)

The bulk of this cost is the low-code app platform subscription (Power Apps), which at
around $24k/year is 64.8% of the two-year costs listed. If budget is a concern, one might
consider alternatives, like an open-source low-code platform (which could be self-hosted) –
that could reduce that cost, but might increase development effort. We balanced ease of
development and cost with Power Apps in this plan.

The hardware is a one-time expense. After 2 years, it remains an asset (with presumably
continued use). The software costs like Power Apps and Figma are recurring. After 2 years,
the organization would need to renew those to continue usage (or consider transitioning off if
they ever rebuild the app natively).

We’ve opted for open-source AI and tools where possible to avoid hidden costs. For example,
if we had chosen a proprietary AI solution or cloud AI service, there could be usage fees. By
using an on-prem open model, we incur no per-query charges – a significant cost saving
given potentially heavy usage.

Licensing Assumptions: We assume any Microsoft licensing (Windows Server, SQL

Server) can be covered under existing government agreements or already-owned licenses. If
not, an approximate figure for SQL Server Standard Edition for the hardware could be around
$14k (as Standard is ~$3,586 per 2 cores (SQL Server 2019—Pricing - Microsoft), for 16
cores needed at minimum). Enterprise would be much higher. However, since the databases
exist already, likely the licenses are in place.

Possible Variance: If instead of Power Apps, we used an alternative (say, Mendix or

OutSystems), costs could differ. Mendix, for example, might charge by app or user in a
similar range, often enterprise packages tens of thousands per year. We chose a commonly
used platform with transparent pricing. Another alternative is to custom-develop the mobile
app without low-code – that shifts cost from subscription to upfront dev effort (which might
mean more developer time rather than license fees). For this proposal, we stick with the low-
code approach as requested.

We will deliver a detailed breakdown with actual quotes if available by project start. All
software used will be properly licensed (no unlicensed or pirated software). Open-source
licenses (Apache 2.0, MIT, etc.) will be complied with (we will attribute any open-source in
documentation as required, though many like Apache 2.0 don’t require attribution in
deployment).

This cost table should help stakeholders budget for deployment and the first two years of
operation of POLARIS. After two years, the ongoing costs would primarily be the Power
Apps (or chosen platform) subscription and any support. Hardware might have maintenance
cost (if extended warranty or support contract after year 3, which could be a few thousand per
year for enterprise support). These can be decided based on usage and importance at that
time.

15. UI/UX Design Approach (Figma Prototypes & Style)

The user interface for POLARIS is being carefully crafted in Figma to ensure it is intuitive,
professional, and aligned with the needs of police officers in the field. We are adopting a blue
and red color palette and a clean design language that conveys authority (blue often
represents trust and stability, red is used for highlights or warnings, similar to police lights).
(Digital Korlantas POLRI Mobile - REVAMP by Lalu Husni Hawari on Dribbble) Figure:
Example of a police mobile app UI design illustrating a clean, easy-to-use interface. In our
design, the login screen welcomes the user with police branding (e.g., Sindh Police insignia)
and uses navy blue as the dominant color. Primary action buttons (like “Login” or “Ask
Query”) are highlighted in a bold red or bright blue for visibility. The example above
demonstrates a similar concept, with a simple login and a home dashboard with big icons –
our app will follow these usability principles.

Mobile App UI: The main interface of the mobile app consists of:

 A Home Dashboard with a search bar or voice mic icon prominently placed so the
officer can immediately start a query. There will be quick-access buttons for common
functions (like scanning a CNIC card QR or asking for help). The dashboard might
also show recent queries or a tip of the day.
 The Query Input Screen – essentially just the home screen doubling as query input.
We’ll support both text input (keyboard, supporting Urdu/Sindhi script input) and
possibly a tap-to-speak (microphone icon for voice input). The design ensures that if
an officer switches the app’s language, the interface labels also switch appropriately
(we’ll design UI variations for English vs Urdu text – considering right-to-left layout
for Urdu/Sindhi).
 Results Screen – after a query, the results will be shown in an easily readable format.
For narrative answers (like an explanation of a law or a summary of a person’s
record), it will appear in a chat bubble or card. Key info might be bold or colored. If
the answer contains multiple parts (like several related records), we might show them
as a list of cards the officer can tap for more details. For example, if the question was
about a person, the top of the answer might summarize “X has 2 prior cases” and
below that two collapsible sections for those cases.
 Navigation & Menu: A simple tab bar or menu drawer will allow access to other
sections: e.g., “Home (Ask)” tab, “History” tab (to see past queries asked), and
“Profile/Settings” tab (for language setting, logout, etc.). The design will keep the
number of screens minimal – likely 3-4 main screens – to reduce complexity. We
want an officer to accomplish everything (ask question, view answer, maybe refine
question) without jumping through many screens.

Design Style: We are following a flat, modern design with clear typography. Likely using a
font like Noto Nastaliq Urdu or Jameel Noori for Urdu/Sindhi for readability, and a sans-serif
like Segoe or Roboto for English – ensuring both look harmonious. Icons will be simple line
icons or filled icons (for instance, a microphone icon for voice, a book icon for law reference,
a phone icon for CDR query). The color scheme: a deep blue (#0B3D91 for example) for
headers, a bright red (#D32F2F) for accent or important buttons, and white/light grey
backgrounds for content areas. This provides good contrast, crucial for outdoor use in
sunlight.

We are also incorporating police theming elements subtly – e.g., perhaps a watermark of the
Sindh Police emblem in the background of the home screen, or using the pattern of a police
uniform (dark blue) as a background shade. These are done tastefully to maintain a
professional look (no clutter).

Figma Prototypes: Using Figma, we are building interactive prototypes. This allows us to
simulate the app flow – for instance, clicking the “Ask” button in the prototype will navigate
to a mock results screen. We’ve shared these prototypes with some officer representatives to
gather feedback early. Because Figma supports collaboration, our stakeholders can comment
directly on the designs. Once finalized, these designs will serve as the blueprint for
development. Furthermore, since we plan to use low-code tools, we will leverage Figma’s
design export features; some platforms (like FlutterFlow or Thunkable) allow importing
Figma frames (Figma Integration | Thunkable Docs), accelerating UI development.

Consistency and Accessibility: We ensure consistent use of UI components. All buttons,

inputs, and cards are derived from a Figma component library we created for POLARIS. This
makes it easier to update globally (if we decide to change the shade of blue, one edit updates
all screens). We also consider accessibility: text sizes are relatively large (no tiny fonts)
because officers might be reading in various conditions. Color contrast meets WCAG
guidelines – e.g., blue text on white, or white text on blue, ensuring readability. Any
important info conveyed by color will also have an icon or text (for colorblind accessibility).
For example, if we highlight a critical result in red, we’ll also mark it with a warning icon.

Admin Panel UI: The admin web/desktop interface will follow a similar color theme but
optimized for a larger screen. We are designing it as a responsive web page that could be
used on a desktop browser. It will have a sidebar with options (User Management, Query
Logs, Data Sync, etc.). Tables and charts might be used for things like usage statistics. We
keep it simple and functional, since admins are usually IT personnel. We plan to implement
the admin panel using the low-code tool’s web capabilities or something like a React
template integrated with the backend.

Design Review with Stakeholders: We’ll conduct a formal UX review with some end-users
(perhaps a small group of officers) by showing them the Figma prototype. Their feedback
(e.g., “make text bigger”, “change term X to local phrasing Y”) will be quickly iterated in
Figma. This all happens in the first month so by implementation time, we are confident in the
design.

By using Figma and focusing on UX early, we reduce changes needed later and ensure the
app is user-friendly. The look-and-feel will be modern (on par with consumer apps, not an
outdated enterprise UI), so that officers feel comfortable and maybe even excited to use it.
The design also subtly enforces the idea of a high-tech policing tool, hopefully instilling
confidence in users that this is a serious, reliable system.

16. Field Usage Scenario – Video Concept

To illustrate POLARIS in action, imagine a short concept video:

Scene: A busy street in Karachi, late evening. A police officer in uniform (we’ll call him
Officer Ali) is on patrol and stops a suspicious individual during a routine check. The
individual provides an ID card with a name.

 Officer Ali takes out his smartphone and launches the POLARIS mobile app. The
video shows the app’s home screen (matching our design) with the query bar.
 Use Case 1 – Person Check: Officer Ali taps the microphone icon and speaks in
Urdu: “ ‫“( ”اس بندے کا کریمنل ریکارڈ دکھائیں‬Show me this person’s criminal record”).
The app’s AI listens and the query text appears on screen (speech-to-text in Urdu
 script). Within a couple of seconds, POLARIS displays results: The video zooms into
the phone screen which shows the person’s profile (from the Person entity) – e.g.,
“Name: Ahmed Khan; Prior Arrests: 2; Wanted: Yes (in Case 456/2022)”. Officer
Ali’s eyebrows raise as he sees the person is wanted in an ongoing robbery case.
 The video overlays a quick cut to the POLARIS interface highlighting “Wanted in
Case 456/2022” in red. Officer Ali confidently tells the suspect he’s under detention,
and maybe calls for backup. This demonstrates how the app immediately provided
critical safety info.
 Use Case 2 – Legal Query: Next, the video shows Officer Ali later writing his report
or FIR at the station. He wonders under what section he should book the suspect for
possessing an illegal weapon found on him. He types in Sindhi this time: “ ‫غير قانوني‬
‫( ”پسٹل لاء سيڪشن‬Sindhi for “illegal pistol law section”). POLARIS quickly
searches the law documents. The video shows the screen with the answer: “Section
23(A) of Sindh Arms Act 2013 – Unlicensed firearm possession – Punishable with up
to 7 years imprisonment (Sindh police launch Talaash app with record of 1.5m
criminals).” We see the app even shows a snippet of the Act text for confirmation.
Officer Ali nods and notes that section in his report. This part of the video emphasizes
inference – he asked in Sindhi language, and the app inferred the relevant law section
correctly.
 Use Case 3 – CDR Analysis: The video scenario can include another officer, maybe
Officer Zahra, using POLARIS in an investigation room. She has two suspects who
claim they don’t know each other. Officer Zahra types a question in English: “Calls
between Suspect A’s number and Suspect B’s number last month?” The app
processes the Excel call records attached to the case. The video shows the screen
listing 3 call entries where one suspect’s phone did call the other’s phone on specific
dates and times, refuting their claim. Officer Zahra turns the phone towards the
suspects and says, “Care to explain these calls?”, demonstrating the app’s utility in
interrogation by quickly revealing connections from data.
 User Interface showcase: The concept video would intersperse these realistic
scenarios with close-ups of the app UI to show how the officer interacts with it. For
example, a shot of Officer Ali’s thumb tapping the “search” button, or selecting a
suggestion that the AI offers (maybe the AI can show a clarification, e.g., “Did you
mean Ahmed Khan born 1980 or 1990?” if multiple records, and he taps the correct
one).
 Environment & Emotion: We portray the officers as confident and efficient, with
the app as their empowering tool. Perhaps a voiceover narrator (in Urdu) explains:
“With POLARIS, Sindh Police officers can get information within seconds. Just ask
naturally, and get answers – anytime, anywhere.” We see Officer Ali under the
flashing red-blue lights of his police mobile van, getting answers on his phone –
reinforcing that this works in the field under real conditions (night time, etc.).
 Conclusion of Video: The final scene could show Officer Ali and Zahra back at
headquarters, and they share how POLARIS helped them crack the case. The camera
then focuses on the phone showing the POLARIS logo and tagline “Empowering
Sindh Police with AI.” The video might end with a motto on screen: “Fast. Intelligent.
On-Demand – POLARIS, your AI partner in the field.”

This concept video script covers multiple features: person lookup, law reference, link analysis
through calls, multi-language queries, voice and text input. It demonstrates the value
proposition in an emotional and practical way – officers solving crimes faster and more
safely.
From a project perspective, such a video (even if initially conceptual) can be used to train
officers and get buy-in from leadership. They can literally see how the app fits into daily
police work. It also helps our development team ensure the features we implement truly align
with the on-ground usage.

Visual Style of Video: We would shoot or animate it to look realistic. Possibly using actual
police actors or real officers, with permission, to add authenticity. Key screens of the app
would be superimposed clearly so viewers see what the officer sees. We’d highlight key text
on the phone screen with graphics if needed so the audience doesn’t miss the critical info.

By demonstrating a Pakistani police officer using the app in context – speaking in local
language, dealing with a suspect, referencing Pakistani law – the concept becomes tangible. It
highlights how technology and AI (which might seem abstract) directly contribute to
effective policing. This also serves as a promotional piece internally to encourage adoption
(officers seeing their peers use it successfully) and to justify the project’s value to higher
officials.

Overall, this report has outlined a comprehensive plan for POLARIS – from its vision and
scope down to technical details and user experience, backed by research and aligned with the
practical demands of Sindh Police. With a clear timeline, skilled team, and the right use of AI
technology, POLARIS is poised to become a game-changer in how police officers access
information and intelligence, making law enforcement more efficient and informed in Sindh.

Here are my own recommendations and suggestions to further enhance

your POLARIS framework report:

1. Clear Success Metrics (KPIs)

 Clearly define Key Performance Indicators (KPIs) for evaluating the success of the
system:
o Response Time: Target average query response within 3-5 seconds.
o Accuracy: Aim for at least 95% accurate responses based on user feedback.
o Adoption Rate: Target at least 90% active usage by trained police officers
within 3 months post-launch.

2. Future Scalability & Expansion

 Discuss briefly the potential for future scalability, such as:

o Integrating additional provinces or regions beyond Sindh.
o Expansion to integrate other governmental databases or federal law
enforcement agencies.
o Possibilities for integration with biometric or facial recognition systems in
future iterations.

3. Risk Management

 Explicitly outline major risks and mitigation strategies, such as:

 o AI Model Performance Issues:
Suggest having a smaller model ready as a backup if the 40B parameter model
underperforms.
o User Acceptance:
Plan to pilot the system with a smaller, controlled group to gather early
feedback.
o Technical Integration Delays:
Set up incremental milestone reviews to identify and resolve issues early.

4. User Feedback Loop

 Implement a continuous feedback loop where officers regularly report usability

issues, inaccuracies, or additional feature requests. This ensures POLARIS
continuously evolves to meet real field needs.

5. Enhanced Documentation and Training

 Alongside videos and printed manuals, consider integrating interactive walkthroughs

within the app itself for first-time users.
 Schedule periodic refresher training sessions or webinars to maintain proficiency.

6. Continuous AI Training

 Suggest periodic retraining and fine-tuning of the AI model using new data gathered
from actual user queries, thus continuously improving response accuracy and
relevance.

7. Compliance and Data Privacy

 Clearly document how the system complies with Pakistan’s data privacy laws and
regulations, particularly related to sensitive police data.

By addressing these areas, your framework will be even stronger, more practical, and ready
for effective deployment and future growth.