jordotech

ENG-1131: Encryption Key Management UI — Implementation Plan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Add a self-service Encryption Key Management page to Organization Settings, gated by a new is_infra_admin flag, with DDB+SSM CRUD for Azure Key Vault credentials.

Architecture: Orthogonal is_infra_admin boolean on organization_x_members table (clj-pg-wrapper), exposed via JWT claim. platform-api gets 4 new /api/v1/admin/encryption/* endpoints using DDB+SSM hybrid storage (mirrors client_api_keys). Frontend adds /settings/encryption page with Configuration + Status tabs, plus a checkbox in the existing admin edit-member modal.

Tech Stack: Python/FastAPI (clj-pg-wrapper, platform-api), TypeScript/React (platform-frontend), Terraform/HCL, Azure SDK (azure-identity, azure-keyvault-keys), DynamoD

jordotech

Incident Report: ey-eu-west-1 Workflow Queue Pile-Up

Date: 2026-04-14 Duration: ~05:00 - 07:00 CST (11:00 - 13:00 UTC) Environment: ey-eu-west-1 Severity: S2 — User-facing workflow delays, incomplete executions Status: Investigating

---

Timeline

jordotech

Discovery Institute — Data Scope Status Report

Date: 2026-04-03 Prepared for: Customer Success Collection: org_42caca5c-da0e-4c91-9bf3-d546266fd2e6_discovery-v1 Collection ID: c85d4618-b581-4413-a855-a4739125e705 Total chunks in Qdrant: 131,896

---

jordotech

Application-Level S3 Encryption: Technical Overview

Prepared for: EY Information Security Team Date: March 2026 Status: Proposed (LOE Review)

---

Executive Summary

jordotech

Design: Application-Level S3 Encryption for EY Environments

Generated by /office-hours on 2026-03-26 Branch: feature/ENG-857-no-celery Repo: Faction-V/gofigure_terraform Status: APPROVED Mode: Intrapreneurship

Problem Statement

jordotech

Capitol AI — Data Access Controls for Customer Organizations

Overview

Capitol AI has implemented platform-level access control that restricts who can view and download an organization's files. Access is determined by the user's verified email domain — only users with authorized email addresses (e.g., @ey.com) can access the organization's data, even if other users have platform administrator privileges.

This control works alongside the existing External Key Management (EKM) encryption to provide multiple independent layers of data protection.

---

jordotech

ENG-893: Per-Org S3 Access Isolation via Email Domain Verification

Problem

Capitol.ai is a multi-tenant platform where organizations share the same AWS infrastructure. A Capitol.ai admin can add themselves to any organization (e.g., EY) and gain full access to that org's S3 files — uploads, workflow files, and generated outputs. Client orgs need assurance that only users with verified email domains can access their data.

Strategy

We implement email-domain-scoped IAM role assumption — a belt-and-suspenders approach combining STS AssumeRole with explicit IAM Deny policies.

jordotech

ENG-857: Replacing Celery with Async Workers — Internal Briefing

Replacing Celery with Async Workers (ENG-857)

Branch: feature/ENG-857-no-celery (agentic-backend + terraform) Status: Deployed to HMG, ready for load testing

Pull Requests

• App: https://github.com/Faction-V/agentic-backend/pull/410

jordotech

Should skills/ Live in a Separate Repo?

TL;DR: The skills/ directory is 3.6MB / 282 files — smaller than a single retina screenshot. Splitting it into a separate repo adds real operational complexity to solve a non-problem, and partially reintroduces the version-coupling failures that caused the outages we're trying to fix.

---

Actual Size of skills/

Total: 3.6 MB, 282 files

jordotech

RFC: Git-Tracked Claude Skill Management

Team: Agentic Backend Author: Engineering Date: 2026-03-07 Status: Implementation planned — [plan at docs/plans/2026-03-07-cli-skill-management.md]

---

Problem