Explore Projects

I work on Gitcord, a tool that connects a GitHub organization with a Discord server to help track and manage open-source contributions. The system will collect GitHub events such as issues, pull requests, reviews, and merges, store them locally, and calculate contributor scores based on configurable rules. The automation will follow a simple pipeline (Read → Plan → Report → Apply) so that every action can be reviewed before it is applied. To keep the system safe, it will run in dry-run mode by default and generate audit reports for maintainers. The project will also include a Discord bot that allows contributors to interact with the system directly from Discord. Contributors will link their GitHub and Discord accounts using a verification step instead of OAuth. Through bot commands, users will be able to check contribution summaries, view pull request information, request issues, and receive notifications about reviews, assignments, and merged pull requests. Gitcord will follow a local-first approach, storing data in a SQLite database rather than relying on external services. It will maintain records such as contribution history, identity mappings, audit logs, and notification history. The project will also include documentation, YAML-based configuration, Docker support, and automated tests so that organizations can deploy and maintain the system more easily.

<p>Open Event Organizer is an Android Application for Event Organizers and Entry Managers. It is a client side application for another project under FOSSASIA named Open Event Organizer Server.</p> <p>The core features implemented in the app are:</p> <ul> <li>Scan a QR code to validate an attendee's check-in</li> <li>Overview of Sales</li> <li>Ticket Management</li> <li>Edit Basic Event Details</li> <li>Offline Support to the above-mentioned features</li> </ul> <p>The app is designed on the Model View Presenter Architecture which enables robust unit testing. Each feature implemented in the app has a complete coverage of unit tests. The app uses most of the modern open source technologies like ReactiveX API for multithreading, Dagger for dependency injection, OkHttp+Retrofit for handling network requests, Evernote's android-job for handling jobs in the background, JSON API-converter to handle JSON API schema responses, Google Vision API for scanning QR code, Glide for image loading/caching, Jackson to parse JSON data, Leakcanary to detect memory leaks, Lombok for logs, Mockito Framework for unit tests, DbFlow ORM database library, Data Binding etc. Material Design Guideline is followed for the UI in the app.</p>

OpenYurt is an open-source edge cloud-native platform designed to streamline application management in edge computing scenarios. However, the current installation process can be complex for newcomers, creating a barrier to adoption. This project aims to significantly improve the user experience by creating a Docker Extension for OpenYurt. The extension will enable users to install and configure a complete OpenYurt environment, including the yurt-dashboard, with a single click directly from the Docker Desktop interface. This will dramatically lower the entry barrier, allowing developers and edge computing enthusiasts to quickly set up a local development and testing environment, thereby fostering greater community engagement and accelerating innovation on the platform. Expected Outcome: 1. Docker Extension Development: Develop a functional Docker Extension using the Docker Extension SDK that can be installed in Docker Desktop. 2. One-Click Deployment: Package OpenYurt's core components (yurt-manager, yurt-hub, etc.) and dependencies into the extension to automate the setup of a single-node OpenYurt cluster. 3. Dashboard Integration: Provide seamless access to the Yurt Dashboard directly from the extension's UI within Docker Desktop, for example, through an "Open Dashboard" button. 4. User Guide and Documentation: Create comprehensive documentation detailing how to install, use, and troubleshoot the OpenYurt Docker Extension.

<p>Graph representation is very promising because it represents a philosophical model of a metalanguage knowledge. Knowing several languages, I know that it could be hard to recall some rare word and it is easier to translate from French to English and only then to Russian - because I forgot the word-pair between Russian and French. This graph representation works just like my memory: we cannot recall what is this word from L1 in L2. Hmm, we know L1-L3 and L3-L2. Oh, that's the link we need. Now we know L1-L3 word-pair. So, as we work on <strong><em> natural</em></strong> language processing, let's use <strong><em>natural</em></strong> instruments and systems as well.</p> <p>The main benefit of this project is reducing human labor and automatization of part of the dictionary development.</p> <ol> <li>Finding lacunae in created dictionary</li> <li>Dictionary enrichment based on algorithm that offer variants and evaluation of these variants.</li> <li>A potential base for creating new pairs.</li> </ol> <p>List of main ideas:</p> <ol> <li>Classes to create the most appropriate type of information</li> <li>Work with subraphs (connectivity components) to reduce the complexity of calculations</li> <li>Filtration algorithms</li> <li>Vectorization to increase efficiency</li> <li>Develope different metrics to reach quality of translation</li> </ol>

Harbor is a widely adopted container registry. As one of the most widely adopted container registries, it is a critical component in modern software supply chains. This project aims to enhance its security capabilities by extending Harbor's Pluggable Scanner specification to support Runtime Behavior Profiles (also known as a Behavior of Bill, or "BoB"). While Software Bill of Materials (SBOMs) describe what an artifact contains, a BoB describes how it behaves at runtime. By integrating kubescape-node-agent as a scanner, Harbor will be able to retrieve, store, and display these runtime profiles for OCI artifacts. This allows software producers to ship secure-by-default configurations and provides consumers with a way to verify runtime behavior, detect anomalies, and report unexpected activity. This feature will create greater trust in artifacts and help users meet emerging compliance requirements, such as the EU's CyberResilience Act, by enabling active breach identification through anomaly detection. Expected Outcome: Propose and document the minimally necessary modifications to the Harbor Pluggable Scanner Spec to support the retrieval of runtime profiles. Implement a scanner adapter that integrates kubescape-node-agent with Harbor. The adapter must be able to retrieve and process SPDX-compliant Runtime Profiles (SBOBs). Extend Harbor's UI to allow users to view runtime profiles and see potential mismatches between expected and observed behavior.

Fragmented cultural heritage artifacts — such as Mayan stelae displaced from their original sites — exist today as scattered, incomplete pieces that are nearly impossible to physically reassemble. This project builds an AI-driven virtual reconstruction pipeline for Stela #43 from the Naranjo archaeological site, operating on 3D-scanned .PLY fragment data. The system combines a Point Transformer V2 backbone for geometric feature learning, a Siamese network for fracture surface matching, a Graph Transformer for globally consistent assembly reasoning, and a Trimmed ICP alignment module with pose graph optimization. A synthetic fracture dataset with realistic surface degradation simulation addresses the limited availability of real labeled data. Every learned component has a geometric fallback, and uncertainty quantification ensures low-confidence matches are flagged for human expert review rather than committed automatically. Deliverables include: a modular PyTorch reconstruction pipeline, a reusable synthetic fracture data generation tool, trained model checkpoints, a robust coarse-to-fine alignment module, a global pose optimization module, a full quantitative evaluation report comparing results against the existing geometric baseline, and complete technical documentation. The system is designed to augment archaeologist judgment — not replace it — by pre-screening thousands of potential fragment matches and providing interpretable, auditable match explanations.

With the increase in use of technology and the internet, the risks associated with the internet are also increasing at a very high rate. Hence, it is necessary to have a system in place to protect our systems from such risks. The risk of malicious attacks is especially higher when browsing the internet. Thus, there is a need for an external system to intervene and block any unauthorized requests to the web server. A web application firewall(WAF) does just that. Modsecurity follows the OWASP Core Rule Set(CRS) rules to detect any vulnerabilities. This helps make web browsing more secure. The CRS has different Paranoia Levels which represent different security levels. At higher paranoia levels, the system has a stricter set of rules to block malicious activities. However, at such high paranoia levels, many genuine requests also get blocked as they resemble malicious activities. These are known as false positives. Such a large number of false positive detections hinders the user experience and as a result, they may stop using CRS and compromise security. Hence, it is important to reduce the number of false positive detections. As the data isn’t labeled, using an appropriate unsupervised learning algorithm is the best possible way to achieve this. With the existing proposal by Floriane Gilliéron as a basis, I would work on an unsupervised learning algorithm for the machine learning plugin and aim to get it integrated as an official plugin. I will also add additional features to the plugin.

Scenic is a probabilistic programming language for generating and verifying environments of autonomous cyber-physical systems. Its driving domain- the primary interface for autonomous vehicle (AV) testing- is a Python library that parses OpenDRIVE road-network files and exposes lanes, roads, intersections, traffic signals, and agents as first-class Scenic objects. While the driving domain is powerful, it has several concrete limitations that hinder real-world usage: assertion failures and geometry artifacts on certain OpenDRIVE maps; a coarse-grained centerline-following model that accumulates error on curved roads; incomplete extraction of semantic road metadata; and absent lane-signal linkage that makes it impossible to write autopilot behaviors that respect traffic laws. This proposal addresses all of these gaps across two major tracks and five subtasks, matching the project outline provided by the mentors: - Track 1 (~4 weeks): Robustness - fix known bugs, expand the test suite. - Track 2 (~5 weeks): Features - Frenet-frame geometry, lane-following distance, semantic tags, signal-lane linkage, and modular scenario components. Each subtask explained in the proposal will produce independently reviewable pull requests, letting mentors integrate work incrementally. The result is a driving domain that is meaningfully more robust, more expressive, and better validated than today.

The project aims to develop an intelligent code review agent that integrates with GitHub and other version control systems (VCS). This tool will provide automated, insightful feedback on code quality by combining traditional static analysis with AI-powered insights. Problem Being Solved Code reviews are often time-consuming and inconsistent, especially when identifying complex issues such as security vulnerabilities, performance bottlenecks, and maintainability concerns. This project addresses these challenges by automating the review process while providing actionable, contextual feedback. Proposed Solution The solution employs a modular webhook-based architecture with the following components: 1. A webhook receiver to capture GitHub events (e.g., pull request creations/updates). 2. A code fetcher to retrieve and parse changed files. 3. An orchestrator to coordinate multiple analysis tools. 4. A result aggregator to combine findings and remove duplicates. 5. A response handler to post intelligent comments directly on pull requests. Key Deliverables 1. A system that provides actionable, contextual feedback rather than merely flagging issues. 2. Support for multiple programming languages (initially Go, JavaScript, and Python). 3. Implementation of dependency vulnerability detection. 4. An AI-powered layer to enhance basic linter outputs. 5. Extensibility for future language support and additional features.

Scientific discovery fundamentally relies on integrating and reasoning over multimodal information—text, diagrams, plots, spectra, microscopy images, and experimental observations. While multimodal Language Models like Gemini show promise as potential AI research assistants, their capabilities in nuanced scientific reasoning remain largely unevaluated, particularly across diverse scientific domains. Existing benchmarks often focus on general knowledge, single modalities, or lack the depth needed to probe scientific reasoning. This project proposes the creation of SciResearchBench, a novel, open-source multimodal benchmark specifically designed to evaluate the scientific reasoning and discovery capabilities of multimodal across key research domains like Chemistry, Materials Science, Biology, and Physics. SciResearchBench will mirror real-world research workflows, encompassing tasks in multimodal data integration, experimental understanding, results interpretation, and hypothesis generation. A core focus will be extensive ablation studies to systematically analyze model sensitivities (prompting, cross-modal integration, grounding, reasoning complexity, context length), providing crucial insights into model failure modes and avenues for improvement. The project deliverables include the curated/generated dataset, robust evaluation code, comprehensive evaluation results for Gemini models, detailed analysis, and the full open-source release of all components to the research community.

<p>Search_API_Location module provides the geospatial search experience to Drupal. Geo-spatial search mainly refers to searching data that is associated with a particular location. Queries such as give me all the restaurants that serves meat within 20 miles from me, or create a distance heat map of them are example of spatial search. Here, some live websites like <a href="https://www.airbnb.co.in" target="_blank">Airbnb</a>, <a href="https://www.tripadvisor.in" target="_blank">TripAdvisor</a> , <a href="https://www.yelp.com" target="_blank">yelp</a>, <a href="https://www.olx.in/" target="_blank">olx</a> etc use Geospatial searching functionality with different type of features which are still missing in Drupal domain.</p> <p>As we know location based search is slowly becoming popular and a must have for any content website in the recent era, Drupal 8 needs to have a drop-in solution for geospatial search. Right now there are some alpha modules existing but these modules need some serious investment for it to become production ready. As well as it should support both Apache solr and MySql server as backend for indexing location data.</p> <p>Search_API_Location module is an extension for Search_API module and it mainly does two things</p> <ul> <li>Adds support for indexing location values</li> <li>Helps in filtering and sorting location values</li> </ul>

<p>New Camel website is a major migration of <a href="http://camel.apache.org/" target="_blank">http://camel.apache.org/</a> website. This work is focused on Camel 3 final release in September.</p> <p>Tools used to generate the website:</p> <ol> <li>Git :- a source code management tool used to fetch document sources from different GitHub repositories.</li> <li>Node.js :- a JavaScript runtime used to build the website. You will need to use Node.js version 10.</li> <li>yarn :- a blazing fast dependency and package manager tool used to download and manage required libraries.</li> <li>Gulp :- a task automation tool. Used to build the Camel Antora UI theme.</li> <li>Hugo :- a static site generator. Simplified, it takes the documentation from the content folder and applies templates from the layouts folder and together with any resources in static folder generates output in the public folder.</li> <li>Antora :- a documentation site generator. It uses Asciidoc documents from different sources in the Camel and Camel K repositories where user manual and component reference documentation resides and renders them for inclusion in this website.</li> <li>Maven (optional) :- a build tool used to run the complete website generating process</li> </ol>

Knative provides a powerful event-driven platform, but learning its concepts, especially brokers and EDA patterns, can be challenging for beginners. The Knative Educational Game aims to simplify this learning curve through interactive gameplay that visually and conceptually demonstrates Knative components and event-driven patterns. An overview of the project was presented at the KubeCon NA 2024 (https://www.youtube.com/watch?v=TTBKh6F4v-g), and several technical sketches, gameplay patterns, and level designs were created and implemented during the LFX Mentorship of Spring 2025 (https://github.com/knative-extensions/educational-game/blob/). This project serves as the continuation of that work and is divided into two main parts: 1. The first part focuses on expanding and enhancing the game by implementing existing level designs, introducing advanced EDA patterns (like Outbox and DataRef patterns), designing assets as needed, and improving interactivity. 2. The second part focuses on deploying the game to the web, making it easily accessible for learners to try and share. Expected Outcome: 1. A fully implemented and web-deployed Knative Educational Game by completing previously designed levels, and newly added EDA patterns (DataRef and Outbox). 2. Improved learning experience through interactive animations, sounds, and clear visualizations that make Knative Eventing concepts and real-world patterns easier to understand....

Many Metasploit modules include documentation describing how to manually build vulnerable test environments. However, these setup steps are performed outside the framework and often vary between users, making exploit verification slower and less consistent. This project proposes a new Metasploit command, build_vuln, that automates the provisioning of vulnerable environments directly from within msfconsole. The command will resolve a module’s associated environment definition and launch the environment using OCI compliant container configurations. The system will support both Docker and Podman runtimes, including rootless execution, through a runtime abstraction layer that avoids tight coupling to a specific container engine. A health management component will ensure environments are ready before exploitation, while an in memory registry will track environments created during the active session and allow users to list, manage, and tear them down. The project will also introduce standardized reusable environment definitions that can be referenced by multiple modules. Selected modules that currently rely on manual Docker instructions will be refactored to use the new mechanism, and a CI integration prototype will demonstrate how these definitions can be reused for automated module verification. The final deliverables include the build_vuln command implementation, container runtime integration, standardized environment definitions, reference module refactoring, CI integration prototype, and comprehensive developer and user documentation.

The current KubeEdge platform represents device states using three statuses: Desired, ObservedDesired, and Reported. The device states displayed on the platform are entirely reliant on the Mapper, which collects and reports data from the device side. However, due to limitations in the Mapper implementation, physical device malfunctions, network delays, and potential network attacks, the device states shown on the platform may not accurately reflect the actual state of the devices. In the KubeEdge platform, if applications depend on device states for decision-making, such inconsistencies in state representation may lead to undesirable outcomes. Therefore, this project aims to design a device state anomaly detection framework for KubeEdge. By exploring the causal relationships among device states, the framework will establish lightweight anomaly detection capabilities and provide a comprehensive toolchain encompassing data collection, model training, real-time anomaly detection, and results visualization. Expected Outcome: 1. A general-purpose device anomaly detection framework that supports user-defined detection algorithms 2. A complete technical design document including model selection, training procedures, and detailed architecture diagrams for both training and online detection components 3. A machine learning model and corresponding anomaly detection algorithm capable of capturing causal relationships among device states, trained and tested using standard frameworks...

Current Frontier LLMs are really bad at assisting with writing JAX code due to the sparse resources spread across multiple different forums and platforms which are often inacessible/unscrapeable (such as discord) by conventional search engine indexers or web scrapers. Thus they usually do not make it into the final pretraining datasets, hurting frontier models' performance on those frameworks. I want to fine-tune OSS models on JAX code, where the data is manually scraped/collected by hand from diverse sources like YT talks, GitHub discussions, Books & Papers and even XLA HLO dumps to enhance the models' understanding of the compiler internals and improve debugging capabilities as well as better guide the developers when dealing with the internals. Another key focus would be incorporating commonly-used popular libraries like Equinox, Optax and Scalax as well because current SOTA LLMs are not familiar with these (relatively) niche but handy libraries and thus prove to be less helpful and prone to hallucinating components of the ecosystem that don't exist. This pretrained model will be available externally through an API or a CLI interface like Aider/Claude Code styled wherein it'd be accessible to everyone regardless of their development environment or IDE/Editor. I would also experiment with new ideas such as integrating type-annotations, Array and PyTree shape annotations and packaging other auxiliary information embedded in the AST to provide further context to the model apart from the raw code itself.

circt-bmc can already prove when an assertion is falsifiable, but it does not yet produce the counterexample trace format hardware developers rely on for debugging. Today, users get a SAT/UNSAT result without a practical cycle-by-cycle waveform showing how the design reached failure. This project adds that missing debugging path. I will preserve meaningful signal identities before lowering, track the corresponding solver expressions across BMC timesteps, and evaluate those expressions against the first satisfying Z3 model. The implementation is intentionally staged: first a readable text counterexample for the failing prefix, then VCD waveform generation from the same trace data. The focus is the first-failure prefix (cycle 0 to the violating step), which delivers high user value with low integration risk and clean upstreamability. Deliverables: 1. Signal tracking and naming pipeline for user-relevant values (ports, externalized registers, selected internals where remapping is reliable). 2. A BMC trace runtime component that records per-step solver ASTs and supports model-driven trace emission. 3. Midterm milestone: first-failure text counterexample dump. 4. Final milestone: VCD waveform output for the same counterexample path, exposed through circt-bmc CLI flags. 5. Upstream-quality tests and documentation (IR-level + end-to-end regressions, including failing and no-violation cases).

The istSOS backend already provides strong support for time-travel queries and versioned data through parameters like as_of and from_to. However, these capabilities are currently only accessible through manual API usage, which makes them difficult to use for most users. This project focuses on bringing these features into the web administration UI by building an intuitive and accessible interface for exploring historical data. Users will be able to select a specific timestamp or time range, view the exact past state of entities such as Things, Sensors, and Datastreams, and understand how data evolved over time without writing API queries. The approach is to design lightweight frontend components that map user input to existing backend parameters, keeping the backend unchanged while making the feature usable. In addition, a Commit History Viewer will be implemented to allow users to browse changes, view metadata like author and timestamp, and load past snapshots directly into the UI. By the end of the project, istSOS will have: - Time selection controls integrated into the UI (instant and range) - Historical views for all major entities - A commit history explorer for tracking data changes - A clean query mapping layer between UI and API - Proper testing and documentation for long-term maintainability Overall, the goal is to make time-travel functionality a first-class feature in istSOS, improving transparency, usability, and accessibility for both technical and non-technical users.

Haskell Language Server (HLS) currently supports Goto Definition only for symbols defined within a user’s project, making it difficult to inspect implementations of functions imported from external dependencies. This project extends that functionality to third-party libraries by enabling developers to navigate directly to dependency source code from within their IDE. The solution leverages .hie files generated by GHC and indexed via HieDb. During HLS startup, dependency HIE files will be discovered and indexed, allowing symbol lookups to resolve to external modules. When a user triggers goto definition on a dependency symbol, the corresponding source code will be extracted from the HIE file, written to a deterministic location, and opened in the editor. To ensure correctness, a type-level rule system will be introduced to prevent invalid rule execution on dependency files, replacing the current fragile runtime whitelist approach. The project deliverables include: rebasing and stabilizing the existing prototype (PR #3749), implementing a type-safe rule constraint system, ensuring complete rule coverage across file types, improving user experience through automated HIE file generation and indexing, enforcing read-only handling for dependency files, and exploring solutions for supporting boot libraries via prebuilt HIE artifacts. These improvements aim to deliver a robust, maintainable, and seamless dependency navigation experience in HLS.

<p>This project is sort of a hybrid project and it consists of implementation of atleast two out of three IETF RFCs/Drafts. The three features in question are "<a href="https://tools.ietf.org/html/draft-yeung-g-ikev2-13" title="Group Key Managment using IKEv2" target="_blank"><strong>Group Key Managment using IKEv2</strong></a>", "<a href="https://tools.ietf.org/html/rfc5685" title="Redirection Mechanism for IKEv2" target="_blank"><strong>Redirection Mechanism for IKEv2</strong></a>" and "<a href="https://tools.ietf.org/html/rfc5723" title="IKEv2 Session Resumption" target="_blank"><strong>IKEv2 Session Resumption</strong></a>". The "<em>Redirection Mechanism for IKEv2</em>" will be implemented before the first evaluation period, and after that it will be dynamically decided (with the libreswan mentors) whether to continue with implementing "<em>Group Key Managment using IKEv2</em>" or "<em>IKEv2 Session Resumption</em>". The reasons for that approach are described in project proposal.</p> <p>"<em>Redirection Mechanism for IKEv2</em>" and "<em>IKEv2 Session Resumption</em>" are features that will improve the performance of VPN servers, especially the ones that serve a lot of VPN clients. "<em>Group Key Managment using IKEv2</em>" will enable key exchanging for secure Multicast communication.</p>

This project continues the work initiated in the etcd - technical scope of the assessment (https://docs.google.com/document/d/1RTXffyDJ8hLoHl_Mo-frQheRQ-8QIVQJ6mqAw69zcP4/edit?pli=1&tab=t.0#heading=h.o524zy9jn6nn). The goal is to dive deep into etcd's architecture in depth by completing and publishing the self-assessment for SIG-Security review. The project has two key components: (1) collaborating with mentors, project maintainers, and Special Interest Groups (SIGs) to investigate etcd and kube-apiserver internals, particularly the lifecycle of requests and consensus mechanisms, and (2) updating and enhancing the etcd.io website (https://etcd.io/) documentation by creating new pages, refining existing content, and publishing blog posts to ensure the documentation reflects current architecture and best practices. Whether you're a new contributor, already active in the community, or simply curious about etcd, we welcome you to join this project! Expected Outcome: 1. Complete the etcd self-assessment draft currently in progress in this document (https://docs.google.com/document/d/1RTXffyDJ8hLoHl_Mo-frQheRQ-8QIVQJ6mqAw69) and prepare it for review by SIG-Security and etcd maintainers. 2. Publish the finalized self-assessment in the SIG-Security repository (see example format - https://github.com/kubernetes/sig-security/blob/main/sig-security-assessments/cluster-api/self-assessment.md)............

This project aims to enhance the monitoring capabilities of OneBusAway (OBA), an open-source platform that provides real-time transit information to riders across multiple cities. The focus is on improving Watchdog, a Go-based backend service that tracks the health and data integrity of OBA servers by reporting detailed metrics to Prometheus. In the past, a Python script was used to monitor the system by checking real-time API data and identifying issues such as expired transit bundles or data mismatches. However, this legacy solution lacked flexibility and scalability. The current Watchdog framework, built in Go, addresses these shortcomings but still requires the addition of several key metrics. The proposed solution builds on the existing Go codebase, expanding and refining the metrics to ensure accurate, real-time tracking of issues such as unmatched trips, stale data, and anomalies in transit information. The project also prioritizes maintainability by refactoring code, implementing robust error reporting through Sentry, and ensuring comprehensive test coverage to maintain reliability. Key deliverables include: Implementation of multiple high-priority metrics Complete test coverage and improved modularity of the codebase Clear, user-friendly documentation A production-ready, extensible monitoring service for OBA This work will provide transit agencies with better insights into data health and system performance, ultimately enhancing the experience for thousands of daily riders.

Problem to Solve : Build a system which performs the following: Enables full-text search of documents; filtered by agency, date, views Recommends similar documents based on semantic similarity of document contents Extracts significant document features such as topics, persons, locations, etc. Clusters and sorts documents by artifact topic (i.e. aerospace, environmental, nuclear, civil rights, etc.) Including: Natural language summaries for each artifact in the collection. Solution: To build the requested system, we will need several components and technologies. Here are the basic steps to achieve the functionality we require: Data ingestion: Loading the documents from a data source and extract the relevant information such as the document ID, title, content, agency, date, and views. Full-text search: Indexing the documents in a search engine such as Elasticsearch and enable full-text search with filters on agency, date, and views. Semantic similarity: Using a natural language processing model such as Doc2Vec to calculate the semantic similarity between documents and recommend similar documents. Document feature extraction: Using a named entity recognition model such as Spacy to extract significant document features such as topics, persons, locations, etc. Clustering and sorting: Using a clustering algorithm such as KMeans to group the documents into clusters based on artifact topic and sort them accordingly. Natural language summaries: we can use a summarization algorithm such as Gensim to generate natural language summaries for each document in the collection.