DRISTI
  • 👋Welcome to DRISTI
    • Why DRISTI?
  • ⚖️About DRISTI
    • Overview
    • Design Principles
    • Value Proposition
    • Architecture Overview
    • System Users
    • Key Modules
      • Async Applications & Submissions
        • Key Features
        • Process & Workflows
        • Specifications
      • Case Management
        • Key Features
        • Process & Workflows
        • Specifications
      • E-Filling, Scrutiny and Admission
        • Key Features
        • Process & Workflows
        • Specifications
        • Sequence Diagrams
      • Evidence
        • Key Features
        • Process & Workflows
        • Specifications
      • Listing & Scheduling
        • Key Features
        • Process & Workflows
        • Specifications
      • Hearings
        • Key Features
        • Process & Workflows
        • Specifications
      • Orders & Tasks
        • Key Features
        • Process & Workflows
        • Specifications
      • Summons, Bails, Warrants
        • Key Features
        • Process & Workflows
        • Specifications
      • User Benefits
      • User Registration
        • Key Features
        • Process & Workflows
        • Specifications
        • Sequence Diagrams
      • Roles per Module
    • API Specifications
    • Security
    • Privacy
  • 🧰DRISTI Platform
    • Architecture
      • Overview
      • Principles
      • High Level Design
        • Technology Stack
        • Access Control & Roles
        • Data & Analytics
        • Non Functional Requirements
          • Performance
          • Security
          • Data Retention
        • Logging Guidelines
      • Low Level Design
        • Advocate
          • Advocate - API Specifications
          • Sequence Diagram
        • Application
          • Application - API Specifications
          • Sequence Diagram
        • Case
          • Case - API Specifications
          • Sequence Diagram
        • Case Management
          • Case Management - API Specifications
          • Sequence Diagram
        • Evidence
          • Evidence - API Specifications
          • Sequence Diagram
        • Hearing
          • Hearing - API Specifications
          • Sequence Diagram
        • Order
          • Order - API Specifications
          • Sequence Diagram
        • Task
          • Task - API Specifications
          • Sequence Diagram
          • Summons
          • Warrant
      • Architectural and Design Decisions
        • Data Visibility
        • Detailed Case Access
        • Case Numbering
          • Filing Number
          • Court Case Number
          • CNR Number
          • Case Stages, Numbers & Dates
    • Interoperability
    • Release Notes
      • Release 1.1.0
      • Release 1.2.0
      • Release 1.3.0
      • Release 1.4.0
      • Release 1.5.0
      • Release 1.6.0
    • Hotfixes
      • Hotfix Release 17.3
      • Hotfix Release 18.1
      • Hotfix Release 18.2
      • Hotfix Release 18.3
      • Hotfix Release 18.4
      • Hotfix Release 19.1
  • 🪝Setup
    • Planning DRISTI Implementation
    • Establish Project & Team
    • Gather Requirements
    • Installation
      • Infrastructure Setup
        • Azure Setup
        • SDC - OpenShift Setup
      • Code Deployment
      • Configuration
        • Functional Configuration
        • Service Configuration
          • Court
            • Court UI
          • Case
            • Case UI
          • Advocate
            • Advocate UI
          • Application
            • Application UI
          • Task
            • Task UI
          • Order
            • Order UI
          • Hearing
            • Hearing UI
          • Evidence
            • Evidence UI
    • Quality Assurance Testing
    • Go Live
    • Operational Support
    • Monitoring
  • 🛣️Roadmap & Updates
    • Roadmap
  • 🌾Resources
    • Source Code
    • Technology Stack
    • Licensing
    • Legal Taxonomy
  • 🌐COMMUNITY
    • Interested in Contributing?
    • Github Discussion
    • Code of Conduct
  • 🪝Setup
    • Coming soon...
    • 🟢ABOUT US
Powered by GitBook
On this page
  • Motivation
  • Design Principles
  1. DRISTI Platform
  2. Architecture

Principles

Architectural principles of the platform

PreviousOverviewNextHigh Level Design

Last updated 6 months ago

Motivation

  • There are variations in how judicial systems function at the national, state and local levels. The design aims to capture these variations as configuration to enable scalability. For example, workflows, master data, roles etc.. are modeled as configuration. These can be customized per implementation.

  • Integrations with third-party systems are variable. These components need to be swappable according to implementation needs.

  • The lack of a unified, single source of truth for data across the case lifecycle is a barrier to delivering effective and timely justice. By reducing data duplication and ensuring data integrity in registries, the design aims to improve access to quality data that can be used to monitor and improve downstream processes.

  • The design aims to enable interoperability with other systems by easing access to registry data via APIs while ensuring security/privacy. Freeing up data can catalyze ecosystem players to innovate on top of the platform.

Design Principles

The DRISTI platform adheres to and builds on top of it. It is built on core principles designed to enhance usability, security and interoperability:

  1. Single Source of Truth - Utilises shared data registries to ensure reuse of data without redundancy. Offers standard for multiple service providers, eliminating data duplication.

  2. Interoperable - Ensures seamless data exchange and system compatibility with an API-first approach to design and adherence to Open Standards.

  3. Security and Privacy - Built with security as a priority with configurable role-based access. It guarantees the encryption of Personally Identifiable Information (PII), which remains off-limits to analytical systems.

  4. Scalability - Employs an event-driven, asynchronous, microservices architecture capable of handling millions of service requests efficiently.

  5. Flexible - Offers high configurability to meet various judiciary needs. Courts can tailor their master data and workflow processes, while integrators can develop and deploy custom service versions.

  6. Modular - Designed with modular microservices and interoperable APIs, the platform allows for independent scaling, updating and deployment of services.

  7. Open - The platform is cloud-agnostic and can be implemented across private data centres or cloud providers. It is MIT-licensed and built with open-source tools and technology to prevent vendor lock-in.

🧰
DIGIT's platform principles
API access