What is Zoth? IGA, JIT, and the problem your project actually solves

You cannot be bulletproof on a project you can't explain at three altitudes: the elevator pitch, the domain vocabulary, and the architecture. Today is altitude one and two.

The problem in one paragraph

Companies give employees long-lived (standing) access to tools — GitHub orgs, Azure subscriptions, Notion workspaces. Standing access violates the Principle of Least Privilege (PoLP): if an account is compromised, or an employee changes roles, the old access lingers for months. Enterprises fix this with Just-In-Time (JIT) access: you request access when you need it, someone (or something) approves it, it's granted for a bounded window, and it's automatically revoked when time expires. Zoth is the platform that manages that whole lifecycle across multiple SaaS/cloud tools.

The vocabulary (say each aloud once)

Your cyber resume is fluent in this vocabulary ("Zero Trust JIT access governance platform… PoLP… 5+ ephemeral access states… zero lingering entitlement drift"). Your SDE resume frames the same system as an engineering achievement ("6-state workflow… event-driven provisioning… hybrid authorization engine"). Both are true; you need both scripts ready.

The shape of the system (preview)

Three Go binaries, one Postgres, one RabbitMQ — that's the entire fleet:

             ┌─────────────┐
  user ────► │  zoth-api   │──── POST /access-requests ──► policies, approvals
             │  (Chi, JWT) │
             └──────┬──────┘
                    │ writes outbox_events (same DB tx)
                    ▼  relay (5s tick)
             ┌─────────────┐        ┌──────────────┐
             │  RabbitMQ   │───────►│  zoth-emitter │──► GitHub / Azure / Notion
             │ (zoth.access)│       └──────────────┘    (zlink connectors)
             └──────▲──────┘        ┌──────────────┐
                    │               │ zoth-alerting │── drift reconciliation (5 min)
                    └───────────────┴──────────────┘
                    all three read/write the same PostgreSQL (+pgvector)

• cmd/api — the HTTP service (Chi router, JWT + API-key auth, all REST routes), runs the 30-second expiry loop and the outbox relay.
• cmd/emitter — consumes access.granted/revoked/expired from RabbitMQ and calls real platform APIs via zlink connectors.
• cmd/alerting — the drift scheduler: compares expected state (zoth DB) vs actual state (platform APIs) every 5 minutes.

Resume mapping, so nothing on paper is unexplained:

• "6-state JIT workflow" = PENDING → APPROVED → ACTIVE → EXPIRED/REVOKED/DENIED (exactly six states in internal/models/access_request.go).
• "event-driven provisioning so access changes could be processed asynchronously without blocking user-facing API" = the outbox → RabbitMQ → emitter chain above.
• "hybrid authorization engine layering RBAC and policy evaluation with an advisory RAG pipeline" = structured JSONB policies decide; Gemini/pgvector advises (risk score, approval likelihood); auto-approve only for LOW-sensitivity resources when the tenant opted in via approval_config.auto_approve_enabled.
• "guaranteeing 100% policy-enforced access with zero advisory-layer bypass" = the RAG path is only reachable through a matched policy object (RouteApproval guards if s.ragService != nil && p != nil), so it's structurally impossible for the LLM to grant anything a policy didn't sanction.
• "liveness, readiness, and startup probes" = K8s deployment yaml in deployments/k8s/base/.

One honest correction you should internalize now: the "3 integrations" are GitHub (fully functional), Notion (SCIM group add/remove — functional), Azure (Discover-only in the current default factory: NewFromConfig leaves RBAC/Graph clients nil, so Grant/Revoke return ErrUnsupported). If an interviewer pushes on Azure, say exactly that — and that the fix is wiring rbacAPI/graphAPI implementations into the factory.