Skip to content

RapidDraft Drawing Analysis

Status: Active product workflow Public deployments: app.rapiddraft.ai and app.rapiddraft.io Last verified: 2026-07-16

Source And Runtime Identity

Product Responsibility

RapidDraft Drawing Analysis is the user-facing experience: upload or select a drawing, choose a detector and threshold, run analysis, inspect findings/overlays, and use the result inside RapidDraft's broader review workflow.

The deployed product currently owns a direct detector-gateway path. It does not need to send every drawing through the full standalone Railway Validator.

Current Direct Workflow

Step What happens Boundary
1 User uploads/selects a drawing in RapidDraft Browser to Railway app
2 RapidDraft authenticates and applies product rate limits Railway app
3 RapidDraft requests detector registry/default Railway app to IONOS gateway
4 RapidDraft sends the drawing and threshold to the selected detector Railway app to IONOS gateway
5 Gateway invokes the current Nuclio function IONOS
6 RapidDraft converts predictions into its drawing-review result shape Railway app
7 UI renders overlays and findings in the review workspace Browser

This path is narrower than the DraftLint Railway Validator: it does not automatically imply FCF parsing, OCR, LLM validation, standards-rule assembly, or DraftLint report generation.

Railway Environment Comparison

The Railway CLI is the authority for this snapshot. GUI cards can lag behind CLI deployments.

Property app.rapiddraft.ai app.rapiddraft.io
Railway project Deployed Service Testing Service
Environment production production
App service rapiddraft_utumpitch rapiddraft_utumpitch
App source adeelyj/rapiddraft_utumpitch adeelyj/rapiddraft_utumpitch
Observed deployment message codex/collaboration-utility-tray 45af414 codex/collaboration-utility-tray 45af414
Custom domain app.rapiddraft.ai and pilots.rapiddraft.ai app.rapiddraft.io
App volume /data, separate .ai volume /data, separate .io volume
Postgres one rapiddraft-postgres service rapiddraft-postgres plus a second Postgres service
DraftLint standalone service Not present DraftLint Fork with Local AI present
Detector registry 12 models, default 26 12 models, default 26

Database Boundary

The .ai and .io projects do not share a Railway Postgres service or volume. Each deployment must use the database URL and storage references belonging to its own project.

The .io project has two Postgres services. That is not automatically an error, but it creates ambiguity. Before a migration or cleanup:

  1. identify which service supplies the active app's DATABASE_URL,
  2. confirm whether the other database is unused, legacy, or used by another component,
  3. take a backup,
  4. test migrations against the intended database,
  5. remove nothing based only on the Railway canvas name.

Authorization Boundary

Both app services have configuration names for:

  • Stytch project identity and secrets,
  • secure cookies and existing-user policy,
  • allowed origins and auth redirect bases,
  • share-link signing,
  • detector-gateway token,
  • authenticated vision usage limits.

The existence of the same variable names does not mean the values or tenants should be shared. Treat .ai and .io as separate security boundaries. Verify callback domains, cookie security, Stytch environment, origin lists, and signing secrets per deployment.

No secret values belong in this wiki.

Detector Configuration Contract

The relevant names are:

  • DRAFTLINT_PIPELINE_MODE
  • DRAFTLINT_DETECTOR_GATEWAY_URL
  • DRAFTLINT_DETECTOR_GATEWAY_TOKEN
  • DRAFTLINT_DEFAULT_DETECTOR_ID
  • DRAFTLINT_DETECTOR_THRESHOLD
  • DRAFTLINT_DETECTOR_GATEWAY_TIMEOUT_SECONDS

Both deployments were configured to prefer detector 26. Code fallback should still prefer the specialist ensemble when available rather than trusting registry ordering.

When To Use The Full Railway Validator

Use the full validator when the product needs the complete staged result:

  • preprocessing artifacts,
  • grouped YOLO detections,
  • FCF parsing,
  • dimension/view linking,
  • OCR previews,
  • optional LLM analysis,
  • standards issues,
  • generated inspection/report artifacts,
  • and a workflow trace.

If RapidDraft adopts this path, add an explicit internal service URL and authentication contract. Do not silently replace the direct detector call because response shapes, latency, persistence, and failure semantics differ.

Deployment Verification Checklist

  1. Use Railway CLI to confirm project, environment, service, domain, source repo, and deployment message.
  2. Confirm the app is attached to the intended project-local database and volume.
  3. Confirm authentication callback/origin settings match the public domain.
  4. Call /api/draftlint/detectors and confirm default 26 is present.
  5. Run a real detector request, not only the registry endpoint.
  6. Verify rate-limit and authentication behavior with an authenticated and unauthenticated request.
  7. Record the deployed commit in a handover.

Open Questions

  1. Is .io strictly the testing environment and .ai the production environment, or will both remain customer-facing?
  2. Which .io Postgres service is authoritative, and can the unused one be retired after backup?
  3. Should RapidDraft integrate the full Railway Validator, or continue composing its own post-detection review pipeline?
  4. Should deployment become GitHub-driven instead of primarily CLI-driven so branch identity is visible in Railway?

Sources

  • RapidDraft repository
  • Railway CLI project/service/deployment/domain/volume metadata verified 2026-07-16
  • Railway variable names verified without recording values 2026-07-16
  • Live .ai and .io detector registry endpoints verified 2026-07-16
  • DraftLint System Family