Northstar Logistics
Reads inventory, retrieves reorder policy, drafts recommendations, and creates approval requests before purchase-order actions.
- Inventory tools
- Policy citations
- Manager approval
Selected project · AI integration
Kipa
Enterprise AI Integration Gateway
Kipa connects an AI model to existing software through controlled permissions, scoped knowledge, approved tools, and human oversight. One shared backend adapts to three simulated client environments without giving the model unrestricted system access.
KIPA / SYSTEM MAPIMPLEMENTED
KShared AI coreRAG · RBAC · AUDIT · APPROVALS
01LogisticsSIMULATED
02BankingSIMULATED
03HealthcareSIMULATED
- Client integrations
- 3 simulated
- Automated tests
- 33
- Python coverage
- 82% measured
- Live evaluations
- 12/12 passed
01 / PROBLEM AND OVERVIEW
The integration is the product.
Adding an AI model to company software is not only a prompting problem. The system must decide who is asking, which records and documents they may access, which tools they may use, and when a person must approve an action.
Kipa places those boundaries around the model. I built one FastAPI gateway and adapted it to synthetic logistics, banking, and healthcare backends. Each environment supplies its own tools, privacy rules, knowledge scope, and approval policy while reusing the same orchestration core.
02 / MY ROLE AND CONTRIBUTION
Designed and built end to end.
I designed and built the shared gateway, three client adapters and simulators, authorization boundaries, privacy transformations, approval workflow, automated tests, live evaluations, technical documentation, and interactive walkthrough.
- Shared FastAPI orchestration and OpenAI Responses API integration
- Client-specific tools, policies, data minimization, and retrieval scopes
- JWT roles, approval-gated side effects, idempotency, and audit events
- Docker delivery, CI checks, test coverage, and evaluation reports
03 / SYSTEM ARCHITECTURE
Control before model access.
User identity, retrieval scope, and tool permissions are established by the application. The model receives only the context and capabilities allowed for that request.
01ENTRYUser request
→
FastAPI gateway
02CONTROLIdentity and policy
→
Deployment, role, allowlist
03CONTEXTKnowledge and tools
→
Scoped RAG, minimized data
04REASONINGAI response
→
OpenAI Responses API
05BOUNDARYHuman approval
Required for side effects
04 / CLIENT ADAPTATION
Same core. Different constraints.
The demonstrations use synthetic data and simulated client systems. Their purpose is to show how the same product core can adapt at the client boundary.
Summit Bank
Scopes account access, masks sensitive customer information, retrieves lost-card policy, and leaves card-freeze proposals pending.
- PII minimization
- Role-scoped accounts
- Supervisor approval
Harborview Hospital
Minimizes patient context, enforces time-bounded EHR access, cites clinical procedures, and gates follow-up coordination.
- PHI minimization
- EHR access window
- Clinical restraint
05 / ENGINEERING DECISIONS
Boundaries the model cannot choose.
The most important controls live in application code and deployment configuration, outside the model's discretion.
Server-derived identity
Deployment and role come from authenticated JWT claims, not from user prompts or model output.
Pre-model minimization
Unnecessary PII and PHI are removed before client records become visible to the model.
Scoped retrieval
Deployment and role filters are applied before similarity ranking across the knowledge store.
Restricted tools
Each adapter exposes an allowlist based on the authenticated deployment and employee role.
Approval-gated actions
The model may propose a high-impact action, but a separately authorized person must approve it.
Structured audit events
Request IDs, tool calls, proposals, and approvals create an inspectable activity trail.
06 / ENGINEERING EVIDENCE
Built to be inspected.
Verification covers normal workflows and the boundaries most likely to fail, including unauthorized roles, cross-client requests, sensitive-data exposure, approval bypass attempts, and provider errors.
Ruff formatting and lintingCHECKED
Strict mypy type checkingCHECKED
GitHub Actions CICONFIGURED
- 33
- Automated tests covering authentication, RAG, tools, approvals, workflows, and provider failures.
- 82%
- Measured Python coverage across the implemented service paths.
- 12/12
- Recorded live OpenAI evaluation scenarios passed across three deployments.
- 3
- Simulated client integrations configured from one shared gateway.
07 / SCOPE AND TRADEOFFS
Clear about what this proves.
Kipa demonstrates enterprise-shaped engineering decisions at a portfolio scale. It does not claim access to real companies, customer records, or regulated production environments.
IMPLEMENTED
- Shared FastAPI gateway and OpenAI provider
- Three client adapters and simulator APIs
- Role-scoped tools and knowledge retrieval
- Privacy transformations, approvals, and audit events
- Automated tests and recorded live evaluations
CURRENT LIMITS
- Client systems and data are simulated
- The public site replays implemented workflows
- The API is not publicly hosted
- Approval and audit stores are currently in memory
- Kipa is not a certified banking or healthcare product
EXPLORE THE PROJECT