Veriprompt Docs

Appearance

Project Architect ​

Last verified against the implementation on 2026-03-16.

Project Architect turns a requirements brief into a provisionable VeriPrompt project. It captures requirements, asks follow-up questions when needed, generates a proposal, and can provision the resulting project assets directly into VeriPrompt.

Access ​

  • Main UI: /architect
  • Transfer UI: /architect/transfer
  • Legacy redirects: /studio/architect, /ranger/architect
  • Requires a signed-in VeriPrompt session
  • Feature-gated to plans that include Architect

What It Does ​

The current product supports these end-to-end functions:

  1. Create an Architect session from typed requirements or uploaded source text.
  2. Run AI analysis through VeriPrompt's internal gateway.
  3. Ask clarification questions when the brief is underspecified.
  4. Generate a proposal with prompts, routing policy, MCP design, skills design, reference-library metadata, and an implementation guide.
  5. Reject or accept a proposal once it is ready.
  6. Transfer an accepted or proposal-ready design into Studio.

Workflow ​

1. Input ​

Architect accepts:

  • typed requirements
  • one uploaded source document
  • optional industry and use case
  • security level
  • preferred providers
  • optional target framework and framework details

Supported upload formats in the current UI:

  • .txt
  • .md
  • .pdf
  • .doc
  • .docx

2. Analysis ​

Architect performs a provider-health preflight, then sends the brief through VeriPrompt's internal gateway.

Stored analysis output includes:

  • summary
  • detected capabilities
  • suggested prompts
  • suggested policy
  • clarification questions

If the model response is malformed, Architect falls back to a minimal analysis payload instead of hard failing.

3. Dialogue ​

If clarification is required, the UI renders structured dialogue cards. Submitting answers can lead to two outcomes:

  • more questions, with the session staying in DIALOGUE
  • readiness to generate, with the session moving to GENERATING

The UI now respects that distinction instead of always forcing generation after the first answer submission.

4. Proposal Generation ​

Architect generates a proposal and validates it for completeness.

The proposal can include:

  • prompts
  • MCP tool metadata
  • skill metadata
  • routing policy
  • reference-library metadata
  • implementation guide
  • monthly cost estimate

If the generated scaffold is incomplete, Architect returns the session to DIALOGUE and records quality issues for follow-up.

5. Review Outcomes ​

When a session reaches PROPOSAL_READY, you have two durable outcomes:

  • Accept: provisions VeriPrompt resources
  • Reject: persists REJECTED and records the rejection in audit logs

6. Transfer To Studio ​

The transfer page now lists:

  • ACCEPTED sessions
  • PROPOSAL_READY sessions

For PROPOSAL_READY, the UI offers Accept & Transfer. Architect will provision the resources first, then open the linked Studio project.

Provisioned Resources ​

Accepting a proposal creates real VeriPrompt objects:

  • Project
  • RoutingPolicy
  • StoredPrompt records
  • initial prompt versions
  • PromptVariable records
  • project-bound ReferenceLibrary
  • generated scaffold documents
  • prompt-library bindings

The current accept flow always creates a reference library.

State Model ​

text
INPUT -> ANALYZING -> DIALOGUE -> GENERATING -> PROPOSAL_READY -> ACCEPTED
                                                        |
                                                        -> REJECTED

Important behavior:

  • analyze only runs from INPUT
  • dialogue only runs from DIALOGUE
  • generate only runs from DIALOGUE or GENERATING
  • provider preflight failures return a configuration-style error instead of weak downstream generation

Current Limitations ​

  • Full generate, accept, and transfer success paths still depend on at least one healthy provider configuration.
  • In the current local verification environment, proposal generation can still fail with scaffold-quality issues when provider output is weak.
  • The detail route still exposes raw user metadata from the session query shape; that should be normalized separately.

Verification Notes ​

Verified live on 2026-03-16:

  • /architect renders
  • legacy Architect routes redirect correctly
  • create, retrieve, update, delete, analyze, dialogue, and reject work
  • /architect/transfer shows proposal-ready sessions and offers auto-transfer

Not fully verified to successful completion in the current local environment:

  • natural generate success
  • natural accept success
  • natural transfer success

Reason:

  • the local provider/routing setup still returned incomplete generation output before a proposal could pass validation.