DeployAlign

Compile deployment promises into evidence-linked decisions before they become field risk.

Comment

The problem

Deployment projects often fail before anyone reaches the field. A customer request becomes a sales promise, the promise becomes a statement of work, and engineering constraints arrive later in a separate review. Phrases such as “all materials,” “every area,” and “fully autonomous” sound decisive, but they are not finite acceptance criteria. A reviewer then has to reconcile several documents manually, under deadline pressure, and prove which evidence supports each commitment.

DeployAlign explores a narrower question: can we compile deployment intent the way engineers compile code—preserving source provenance, emitting deterministic diagnostics, and rebuilding only the downstream sections affected by an approved decision?

What the prototype does

The bundled scenario is explicitly synthetic. It contains three fictional artifacts: a customer discovery email, a draft commercial proposal, and an application-engineering review for a Raman inspection pilot. The customer and sales text asks for all-material, facility-wide autonomous inspection. The engineering text supports only five named analytes under controlled conditions, 12 mapped areas of interest, and supervised Phase 1 operation.

DeployAlign turns those statements into typed nodes for objectives, preferences, commitments, constraints, site claims, assumptions, evidence, tests, and deployment gates. A deterministic policy layer emits six source-linked diagnostics, including unbounded scope, a commitment without evidence, a preference cast as a constraint, a site claim treated as fact, a missing acceptance criterion, and an open critical test.

The prototype then proposes the smallest three-field semantic patch: five named analytes instead of all materials, 12 mapped AOIs instead of every area, and supervised Phase 1 instead of full autonomy. A local review action advances the demo baseline from HOLD to CONDITIONAL PILOT; it never produces an unconditional pass because the blind test and physical survey remain open.

The same decision ID is carried into a customer decision memo, sales SOW, and engineering test manifest. Within the approved compile, six Decision-ID-linked sections are rebuilt while three unrelated canonical baseline sections are reused without reconstruction. Their stable FNV-1a32 values are non-cryptographic change fingerprints, not integrity hashes. Execution receipts show which stages were attributed to extraction, deterministic rules, human review, and the build engine.

How AI and humans are separated

The deployed application uses gemini-2.5-flash through Vertex AI as a constrained extraction front end. Gemini must return exactly three structured classified statements with exact source quotes and a concise patch rationale. The server rejects ungrounded quotes, disallowed types, malformed output, or invalid rationale. The canonical graph, diagnostic rules, deployment gate, impact calculation, and target compilation remain deterministic TypeScript.

Live model calls are disabled by default in the code, and the application has a deterministic fallback for demonstration reliability. For the public synthetic demo, live execution was explicitly enabled on Cloud Run in asia-northeast3 with a dedicated runtime service account and a stable HMAC secret from Secret Manager. A deployed compile showed provider gemini-vertex, exactly three quote-grounded AI_DRAFT candidates, and a successful gemini-2.5-flash receipt. The signed provenance survived the review transition from HOLD to CONDITIONAL PILOT; redacted logs recorded the version-1 compile and version-2 approval. Official Vertex AI Model Garden Monitoring also showed model-request and token-count activity for gemini-2.5-flash. This verifies one deployed Google Cloud/Gemini path, not customer production or AI ownership of the deterministic decisions.

Humans own the consequential boundaries: deciding whether a proposed patch is acceptable, supplying missing evidence and acceptance criteria, authorizing any real deployment, and approving external publication. The current review button is a local demo of that boundary, not authenticated organizational approval.

What we learned

The central insight is that the valuable output is not more generated prose. It is a traceable decision: the exact claim that conflicts, the source evidence, the minimum bounded change, the open verification work, and the downstream impact. We also learned that a safe-looking fallback can hide whether AI actually ran, so provider and synthetic-state disclosure must be part of the product, not a footnote.

Potential impact and next work

If validated with real deployment teams, DeployAlign could help smaller integrators and engineering-service groups apply consistent review discipline without building a large internal tooling organization. The entrant confirms 1 actual user and 0 paying users, but no customer, testimonial, job, measured outcome, or time saving. May, June, July, August, total, and related-party revenue are each $0; COGS, marketing, other, and total expenses are each $0. These exact values describe an early experiment, not traction or category impact. Actual jobs or economic opportunities beyond the founder are currently none; any future opportunity is only a potential outcome of validated pilots, not an achieved impact.

Next, we would test the synthetic workflow with deployment practitioners, collect consented redacted examples, benchmark classification and diagnostic accuracy, and determine whether reviewers act faster or catch more material conflicts. Only then would we add identity, tenant isolation, durable audit events, configurable policies, and production cloud operations.

Built With

Share this project:

Updates