PolicyKit
Overview
PolicyKit is an AI-agent specializing in compliance to review job postings for policy violations. Using OpenAI's language models and vector search, PolicyKit acts as your intelligent compliance officer, ensuring job postings on your platform meet all of your platform's policies while learning from previous reviews to improve efficiency.
Features
- AI Compliance Agent: Understands and enforces complex policy requirements, detecting violations with high accuracy.
- Retrieval-Augmented Generation (RAG): Uses vector embeddings to find and reuse results from similar job postings for efficiency and consistency. Successful classifications are embedded and added to the database for quicker classification in subsequent requests.
- Vector Database: Uses ChromaDB for efficient similarity search and storage of job posting embeddings.
- Flexible Policy Schema: Supports both
StandardViolation
andSafetyViolation
types for nuanced violation reporting. - Async FastAPI Backend: High-performance, async API for real-time job posting checks.
- Seeding & Testing: Includes scripts to seed the database with example job postings and policies.
System Architecture
AI Agent Design
The PolicyKit AI agent follows a multi-stage design with input validation, semantic caching, and orchestrator-worker fallback for new or uncached inputs.
View the full architecture diagram using draw.io
Design Choices Explanation
1. Input Validation and Safety Checks
Input is validated to ensure it is a job posting and safe to process, including prompt injection checks. A gating mechanism enforces this safety, inspired by Anthropic’s agent design patterns (Building Effective Agents).
2. Using a Vector Database as a Semantic Cache
ChromaDB is used as a semantic cache, storing classified job postings and edge cases. This enables fast short-circuiting for similar postings and improves efficiency as the system learns.
Key points:
- Edge cases and classified job postings are embedded and stored for future reference.
- The semantic cache allows instant retrieval for similar postings, bypassing the full pipeline.
- Two concerns:
- Immediate storage of agent responses can propagate misclassifications. Ideally, queue for human review before adding to the DB.
- Policy changes require timestamp/version tags for embeddings to allow reclassification.
3. Fallback: Orchestrator-Worker Model for New or Uncached Inputs
If vector search doesn't return a confident classification, the system falls back to a multi-agent orchestrator-worker pattern:
- Orchestrator summarizes policy categories and spawns workers for each.
- Workers receive full policy lists and run concurrent compliance checks.
- Results are aggregated and returned to the client.
API Usage
Send a POST request to /api/v1/check-posting
:
curl -X POST http://localhost:8000/api/v1/check-posting \
-H "Content-Type: application/json" \
-d '{"job_description": "Looking for a young, energetic female candidate to join our team. Must be under 30 years old."}'
Example response:
{
"has_violations": true,
"violations": [
{
"category": "Discrimination",
"policy": ["No Gender Discrimination", "No Age Discrimination"],
"reasoning": "Job posting specifies gender and age requirements",
"content": "Looking for a young, energetic female candidate to join our team. Must be under 30 years old."
}
],
"metadata": null
}
Violation Types:
StandardViolation
: Most policy violations (discrimination, legal, privacy, academic, etc.)SafetyViolation
: Prompt injection or safety-related issues
RAG & Vector Search:
- New job posting embeddings are compared to existing ones in ChromaDB.
- Similar postings reuse results; otherwise, full policy check and result stored for future RAG.