Architecture boundary
Vendor-neutral boundary
The database and workflow contracts belong to the client. Model providers can change without rebuilding the source-of-truth layer.
Vendor-neutral AI workflow
Give teams one governed research and drafting workspace that can route tasks across approved cloud or local models without moving the source of truth into any model vendor.
Illustrative implementation pattern. These are real examples of working operating-layer patterns. What can be implemented in practice depends on authorized access, platform terms, data quality, security requirements, client participation, and agreed human-approval controls. Tools named in these patterns are possible components, not required products. Property, planning, tax, valuation, safety, biometric, engineering, and legal outputs require appropriate qualified review.
Why this workflow matters
A workflow built around one model's chat history, proprietary file store, or prompt format creates lock-in and weakens comparison across quality, cost, latency, privacy, and future providers. Records, documents, permissions, tool contracts, and decisions should remain in client-controlled systems.
Architecture boundary
The database and workflow contracts belong to the client. Model providers can change without rebuilding the source-of-truth layer.
Reference layer
These sources and tools are selected according to authority, permission, technical fit, security, and client ownership.
PostgreSQL or Teable for projects, tasks, records, decisions, approvals, and model runs.
SharePoint, Autodesk Docs, Procore, or object storage for source documents.
pgvector, OpenSearch, Azure AI Search, Pinecone, or Qdrant with permission filters.
An internal AI gateway, LiteLLM, or provider-specific adapters for approved models, budgets, and fallbacks.
n8n, Temporal, or application services for controlled tool execution.
Langfuse, OpenTelemetry, or internal tables for traces, cost, latency, and quality results.
| Task | Possible method | Required control |
|---|---|---|
| Extract a schedule from a drawing | An approved, tested vision model | Schema validation and drawing-coordinate review |
| Summarize a long contract | An approved language model suited to long documents | Page citations and legal review |
| Research a current property issue | An approved model with permitted web tools | Source allowlist, retrieval dates, and analyst approval |
| Classify routine records | A lower-cost tested cloud or local model | Evaluation sample, confidence threshold, and exception queue |
| Calculate tax, quantities, or financial totals | SQL, spreadsheet formulas, or Python | Reproducible formula and reviewer sign-off |
| Draft an email, proposal, or report | Any approved language model | Approved facts, templates, tone rules, and human approval before sending |
Ten-stage operating path
Each stage establishes a distinct decision, record, handoff, or approval boundary. Exceptions remain visible instead of being silently forced through the process.
Classify the requested task and its risk level.
Authorize the user, project, records, documents, and permitted actions.
Retrieve only relevant, current, permissioned context.
Route the task to an approved model based on capability, cost, latency, and data policy.
Execute deterministic tools outside the model for calculations and system updates.
Validate the response against schemas, source citations, and business rules.
Use another model or deterministic check when the task warrants it.
Review consequential recommendations or external outputs with a person.
Record inputs, sources, model version, cost, result, decision, and feedback.
Improve routing and prompts from evaluations without silently changing authoritative records.
Required data layer
The implementation boundary should name each required record, relationship, source, status, permission, and owner before automation is introduced.
AI Provider
Model Version
Task Type
Prompt Version
Tool Definition
Retrieval Query
Context Item
Source Citation
Model Run
Token Usage
Cost Record
Evaluation
Decision
Approval
Failure
Fallback Event
Authority, source quality, permissions, uncertainty, and consequential external actions remain explicit throughout the workflow.
Acceptance measures
Acceptance measures test the reliability and governance of the workflow. They are evaluation criteria, not promised performance results.
Typical starting engagement
This is planning guidance for a bounded first implementation, not a quote. The Blueprint confirms systems, access, data condition, responsibilities, exclusions, acceptance, timing, and fixed price.
Workflow assessment
Confirm the current records, sources, permissions, owners, exceptions, approval points, and acceptance measures before selecting automation or AI tools.