Inspiration
Cross-cloud outages are rarely caused by one dramatic command. They happen when identity, DNS, certificates, gateways, applications, and evidence drift across systems while a team keeps moving on an assumption that is no longer true. CCTF began as a cross-cloud trust framework. For Build Week, I used Codex and GPT-5.6 to turn that foundation into one focused developer tool: see the trust ripple before a change continues.
What it does
Describe a planned cross-cloud change or load one of the included synthetic scenarios. CCTF Change Sentinel maps the dependencies, identifies the governing evidence, waits when propagation or freshness cannot yet be proven, blocks unsafe continuation with HTTP 409, and generates a verified change kit for Codex.
The kit tells Codex what changed, what evidence is fresh, what remains uncertain, which tests are allowed, and what must not happen. A separate Python process reproduces the fingerprint and tamper check. The mandatory path makes zero provider calls and authorizes zero cloud changes.
An optional already-installed local Ollama model can turn a human description into a proposed rehearsal. Its output is schema-validated, editable, approval-gated, and never treated as the trust verdict. Codex can explain and propose tests; deterministic evidence remains the authority.
How it works
- Capture the intended change and affected cloud boundaries.
- Build a dependency and provenance map.
- Check evidence freshness, propagation, and policy gates.
- Deny continuation when required truth is missing or stale.
- Produce the smallest sufficient Codex change kit.
- Reproduce the result and detect tampering in a separate process.
How I used Codex and GPT-5.6
GPT-5.6 through Codex helped recover and challenge the older framework, define the focused Build Week extension, implement the deterministic gate, build the independent-process verifier, harden input and local-server boundaries, create the UI and CLI, expand adversarial tests, and simplify the product around one understandable payoff. I made the architectural, security, claims, identity, and release decisions.
Challenges
The hardest problem was keeping AI useful without making it a security authority. CCTF therefore treats prompts, retrieved content, local-model output, and stored artifacts as untrusted input. There is no credential path, unsafe loader, memory store, MCP server, or live cloud mutation in the required runtime. Another challenge was making propagation understandable: sometimes the safest and fastest action is to wait for truth, not force the system forward.
Accomplishments
- A standard-library Python judge path with no rebuild or package installation.
- 48 deterministic tests passing.
- Explicit HTTP 409 denial and zero cloud changes.
- Independent-process fingerprint reproduction and tamper detection.
- UI, CLI, synthetic change scenarios, secret/path scan, dependency guard, and integrity receipts.
- Optional localhost-only AI proposal lane with human approval and deterministic authority.
What I learned
A trustworthy developer tool should teach while it protects. The best change gate does not only say no; it shows which source governs, why the evidence is not ready, which systems are affected, and the exact safe test that can happen next.
What's next
Provider-specific read-only adapters, signed evidence sources, team policy packs, richer propagation models, and future specialized simulation lanes—including classical quantum-workflow simulators where their assumptions genuinely fit—without turning a narrow accelerator into a universal claim.
Log in or sign up for Devpost to join the conversation.