Technical product reference

How Orion turns a PDF into a reviewable evidence system.

A detailed reference to Orion’s ingestion, multimodal retrieval, specialist analysis, calculation, governance, and recovery design-written for technical buyers, estimators, engineering reviewers, and implementation teams.

Request a walkthrough Explore Orion

Resumable page ingestion Text + native visual evidence Typed specialist stages Deterministic calculation trace

System map

Six layers, each with a distinct responsibility.

Orion is best understood as a chain of addressable artifacts and validated handoffs-not as one model reading one enormous prompt. Each layer narrows the work while preserving a route back to the source.

01 · Intake
Authorized source record
A project PDF is registered with project, tenant, document category, content hash, and processing state before deeper work begins.
02 · Ingestion
Addressable page artifacts
Pages become text chunks, rendered images, single-page PDF assets, structured visual summaries, and localized component records where available.
03 · Retrieval
Scoped multimodal index
Text and image representations share document, page, category, tenant, and source-provenance metadata for filtered retrieval.
04 · Analysis
Typed specialist workflow
Project needs, measurements, engineering context, product context, evidence, and review questions are produced in separate validated stages.
05 · Report
Reviewable output contract
The report keeps findings, sources, quantities, formulas, warnings, methodology, and follow-up actions in one structured record.
06 · Decision
Human-owned next action
A reviewer decides whether to investigate, revise, export, hand off, or stop. Confidence stays separate from approval authority.

Full-ingestion pipeline

A page-aware, multimodal process with explicit recovery behavior.

The full path works from source admission down to individual pages. Open any stage to see the system work, the artifact it leaves behind, and what happens when that stage cannot complete normally.

Validate and admit the sourceSanitize, inspect, deduplicate, and create a durable document identity.

System work: The upload path accepts one or more project PDFs, sanitizes filenames, validates file type, reads page count, calculates a SHA-256 content hash, checks for duplicate content, and links the document to a new or existing project.
Persisted result: Document ID, filename, project relationship, tenant/category context, page count, content hash, and pending processing state.
Failure behavior: Non-PDF input, duplicate content, invalid project scope, missing permissions, or unmet credit/approval requirements are rejected before full processing.

Reserve the processing pathChoose fast screening or full analysis and record the active attempt.

System work: Full ingestion estimates and reserves Analysis Credits before processing; fast screening uses its separate lightweight lane. Attempt IDs and ownership prevent an older worker from overwriting a newer run.
Persisted result: Ingestion mode, credit reservation where applicable, attempt identity, queue/status metadata, and promotion state.
Failure behavior: Insufficient balance, missing confirmation, or required administrative approval keeps the document from entering full processing.

Persist the original sourceKeep the document required for citations, resume, and verification packets.

System work: The worker resolves or restores the original PDF, records storage metadata, and carries the source hash into embedding provenance before parsing. The original is retained after temporary chunks are removed.
Persisted result: Original PDF reference, storage metadata, source hash, and resumable provenance.
Failure behavior: A missing source stops the run. A required durable-source upload failure stops parsing rather than leaving an unrecoverable index.

Split work into bounded page unitsControl concurrency without losing original page numbering.

System work: Large PDFs are divided into bounded temporary page ranges. Chunk jobs run concurrently under a semaphore, and each range retains an offset to the original document.
Persisted result: Temporary page-range files and an exact mapping back to original page numbers.
Failure behavior: A failed range becomes a recorded partial-ingestion event while successfully processed ranges remain usable.

Extract text and native page assetsRepresent each page as both a readable fragment and a visual construction sheet.

System work: The parser extracts embedded text, generates Markdown when available, falls back to native page text when necessary, renders a plan-resolution PNG, and creates a single-page PDF.
Persisted result: Markdown or text, rendered page image, one-page PDF, source page number, and page dimensions.
Failure behavior: Extraction failures are isolated to the affected page and added to the partial-coverage record.

Build multimodal representationsIndex language, page layout, and drawing appearance without collapsing them into one format.

System work: Text is split into overlapping chunks. The complete PDF/image/text page receives a native page representation, and the rendered sheet receives a native image representation in the same search space.
Persisted result: Text-chunk records, full-page analysis record, full-page image record, asset IDs, and embedding model/schema metadata.
Failure behavior: If page analysis fails, Orion can retain the extracted text and raw page assets as a marked stub rather than calling the page fully analyzed.

Read visual structure and localize componentsTurn drawing-heavy content into searchable technical regions.

System work: A structured visual pass classifies the page and can recover document context, OCR-like text, specifications, measurements, retrieval keywords, and components/materials. Valid normalized bounding boxes are cropped into component assets.
Persisted result: Structured page summary, component text, normalized bounding boxes, cropped images, and component-level text/image embeddings.
Failure behavior: Invalid bounding boxes are skipped. Missing visual analysis never erases the source page or its text representation.

Index, complete, and expose coverageFinish with provenance and failure detail-not one opaque success flag.

System work: Records are batch-upserted with tenant, category, document, page, type, source hash, embedding model, and schema. Matching pages can be reused on resume; completion records partial failures and promotion state.
Persisted result: Mixed text/image retrieval collection, companion asset collection, completion state, indexed-page coverage, and partial-failure details.
Failure behavior: A catastrophic failure marks the document failed. Page/chunk failures remain visible while successfully indexed evidence can still be reviewed with warnings.

Page artifact model

One construction page becomes several searchable addresses.

A clause, a drawing detail, and a material callout do not behave the same way in search. Orion preserves several representations so retrieval can use the evidence form that best matches the question.

Single-page PDF

Preserves the page as a citation-addressable source fragment.

document · page · source hash

Rendered page image

Preserves drawings, tables, callouts, and layout that extracted text may not express.

document · page · image asset

Text chunks

Makes clauses, notes, schedules, and written requirements retrievable at smaller semantic units.

document · page · chunk index

Full-page structured summary

Organizes page type, context, specifications, measurements, keywords, and commercial signals.

document · page · processing status

Component records and crops

Makes a detected material, detail, or component searchable independently when a valid location exists.

document · page · component · bounding box

Embedding provenance

Distinguishes artifacts created from a different source, model, or schema during resume and maintenance.

source hash · model · schema · timestamp

Multimodal retrieval

Find evidence by scope, meaning, and representation.

Retrieval filters to the approved record, fans out across relevant knowledge categories, removes duplicates, reranks text, retains strong visual matches, and carries source addresses into analysis.

01
Scope
Resolve active, processed project document IDs and the approved library categories available to the workflow.
02
Expand
Combine the user question with configured vector queries and tenant product/application language.
03
Retrieve
Search relevant project, product, and engineering-manual collections concurrently.
04
Unify
Merge duplicate nodes by stable ID so fan-out does not shift the evidence ledger.
05
Rerank
Rerank text against the primary question while retaining a bounded set of strong native-image matches.
06
Address
Carry document, page, category, asset, and score metadata into the analysis context and report sources.

RETRIEVAL RESULT CONTRACT

node_id · record type · tenant/category · document_id · filename · page_number · asset_reference · relevance score

A locator can only be as exact as the indexed source supports. Document and page references are universal to the page record; sheet, section, detail, and bounding-box locators appear when they are available.

Project Analysis V2

A staged evidence workflow-not a single free-form answer.

The deeper workflow resolves one project snapshot, produces typed needs, examines measurement support, retrieves evidence per need, runs specialist analyses, reconciles outputs, and only then assembles the Qualified Opportunity Report.

Resolve an authorized project snapshotSelect active, processed project documents and start a new evidence snapshot. Direct attachments must be ingested before they can influence a citation-addressable report.

Stage record: Authorized document IDs, snapshot identity, processing eligibility, and any rejected attachment or scope condition.

Create a stable evidence orderRetrieve, deduplicate, and select project context before prompts, context PDFs, and final source objects are assembled.

Stage record: An ordered source ledger and bounded context package whose source positions remain stable through later stages.

Extract typed project needsValidate project metadata, contacts, need IDs, locations, dimensions, specifications, incumbent material, candidate context, and preliminary quantity fields.

Stage record: Validated need groups with stable IDs, source locators, populated fields, and explicit missing or invalid inputs.

Assess scale and measurementsDetermine whether a quantity is source-based, independently measured, estimated with stated assumptions, conflicted, or needs more input.

Stage record: Measurement audits containing scale, geometry, formula, named inputs, units, assumptions, cross-checks, conflicts, and status.

Retrieve evidence per needFan out targeted project, product, and engineering evidence retrieval for each validated need group.

Stage record: Need-linked evidence bundles with category, document, page, asset, relevance, and visible no-evidence outcomes.

Run engineering and product analysesApply separate specialist roles and only the tenant-enabled civil analysis skills assigned to those roles.

Stage record: Typed engineering rationale, rules, calculations, candidate products, product evidence, warnings, and reviewer questions.

Verify and reconcile material rowsNormalize references, exclude rows disconnected from authorized needs, and retain product, pursuit, and quantity confidence separately.

Stage record: Normalized BOM rows linked to authorized need IDs, plus exclusions, reconciliation warnings, and separate confidence fields.

Assemble the core reportCreate project, BOM, summary, opportunity, strategy, needs-review, calculation, evidence, and appendix sections from validated artifacts.

Stage record: A versioned report contract with sections, sources, methodology, warnings, calculations, review states, and coverage metadata.

Prepare selective follow-upAfter the required report exists, generate bounded actions, material-gap drill-downs, and optional managed evidence/engineering QA review.

Stage record: Zero to three evidence-backed actions, targeted gap questions, optional QA findings, and the responsible review path.

Specialist roles in the current analysis workflow
Role	Primary responsibility	Inspectible contribution
Project Analyst	Project metadata and typed need extraction	Need groups and project context
Plan Measurement Analyst	Scale, geometry, and measurement assessment	Measurement audits, status, assumptions, and questions
Engineering Agent	Rules, constraints, calculations, and technical fit	Engineering rationale and calculated quantities
Products Agent	Approved catalog and application matching	Candidate products and product evidence
Report Writer	Structured synthesis of validated artifacts	Report narrative and methodology
Action Strategist	Selective technical-commercial follow-up	Zero to three evidence-backed actions
Report Reviewer	Material gaps and unresolved decisions	Targeted drill-down prompts
Managed QA reviewers	Optional evidence and engineering QA supplements	Additional warnings or review findings

Foundations

Civil takeoff audit · scale calibration · civil quantity calculation · order-quantity estimation · takeoff QA

Horizontal construction

Roadway materials · earthwork · utilities · linear features · concrete structures

Geosynthetics and stabilization

Biaxial geogrid · erosion control · channel linings · fabric-formed concrete

Structures and temporary works

MSE walls · sheet piling · shoring

Confidence and review semantics

Several scores answer several different questions.

Orion separates screening fit, pursuit readiness, evidence support, product matching, and quantity/measurement confidence so a strong commercial signal cannot hide a weak takeoff-or vice versa.

Confidence signal dictionary
Signal	What it helps answer	Interpretation boundary
Screening rank score	Orders candidate document sets for attention.	Pursue/review/reject recommendation-not probability of winning.
Technical fit	Combines direct product, application, incumbent, semantic, and design signals.	Profile-relative screening component-not final engineering fit.
Pursuit readiness	Reflects commercial, quantity, evidence, and project metadata signals.	Commercial prioritization-not a bid decision.
Evidence confidence	Describes screening evidence diversity, text/page coverage, and semantic completion.	How inspectable the basis is-not proof that every conclusion is correct.
Pursuit confidence	Represents the strength of the deeper opportunity case.	Kept separate from product and quantity confidence.
Product-match confidence	Represents the support for a candidate product relationship.	Does not independently approve equivalency or suitability.
Quantity / measurement confidence	Represents source, scale, method, assumptions, cross-checks, and conflict support.	A separate estimating signal with its own verification state.

Evidence connected

A relevant source region is attached and addressable.

Reviewer responseInspect the cited page and surrounding context.

Needs review

A conflict, assumption, weak opportunity, or decision requires a person.

Reviewer responseAssign the question to the responsible reviewer.

UNKNOWN / needs input

The approved record does not support a required value or conclusion.

Reviewer responseAdd valid evidence or leave it unresolved.

Completed with warnings

The core analysis completed, but material warnings remain.

Reviewer responseRead the warning list before using the report.

Partial ingestion

Some pages or chunks failed or were stubbed while others were indexed.

Reviewer responseInspect coverage and reprocess if the missing content matters.

Valid no opportunities

The scoped evidence was analyzed but produced no qualifying need groups.

Reviewer responseTreat it as a bounded result for this scope and question.

Failure and recovery behavior

Coverage problems become data instead of disappearing.

Long-running document analysis requires more than retries. Orion records attempt ownership, resumable provenance, page-level failures, marked fallbacks, retained source material, and warnings that survive into the customer-visible report.

Attempt ownership

A stale background attempt cannot replace the state written by a newer worker.

Resume by provenance

Indexed pages can be reused only when source hash, embedding model/schema, and required assets still match.

Page-level isolation

One failed page does not automatically discard successful pages from the same document.

Marked fallback

Available text and raw assets can remain as an explicitly stubbed page when visual analysis fails.

Retained original

The source PDF remains available for citations, resume, and verification-packet assembly.

Report-level trace

Warnings, audit entries, methodology, measurements, questions, context coverage, and sources travel with the report.

Production and contractual posture

Security, continuity, and integration commitments around the application.

These controls complement the repository-level workflow described above. They define the documented production environment and customer commitments for deployed Orion workspaces.

Tenant data isolation

JWT-authenticated and role-aware requests, tenant-scoped relational data, tenant-dedicated vector collections, namespaced object paths, and project-level scope checks.

AI data boundary

Enterprise zero-training commitments, real-time inference, ephemeral processing, and no cross-customer aggregation of plans, takeoffs, pricing, or custom rules.

Encryption and transport

TLS 1.3 in transit and AES-256 encryption at rest across the documented production data path.

Execution isolation

Network-disabled, ephemeral Linux sandboxes for managed deep-review tasks, with curated evidence inputs and bounded lifetime.

Human-in-the-loop

Generated findings, takeoffs, BOMs, and inquiries remain reviewable; external writes and submissions require an authorized user.

Interoperability

REST APIs, webhooks, MCP-compatible integrations, and JSON, CSV, and PDF output formats for approved downstream workflows.

Documented recovery objectives
System tier	Target RTO	Target RPO	Recovery design
API and compute	< 15 minutes	0 minutes	Stateless multi-zone services and revision rollback
Relational database	< 1 hour	< 5 minutes	WAL, snapshots, and point-in-time recovery
File and artifact storage	< 30 minutes	< 1 hour	Redundant object storage and source-hash verification
Vector search store	< 2 hours	< 4 hours	Re-indexing from primary document metadata and source files

Most recent recovery exerciseAugust 4, 2026 · production-mirror environmentPassed

Measured recovery exercise results
Recovery path	Measured	Target	Outcome
Application compute	3 min 45 sec	< 15 min	Passed
Database failover	18 min 20 sec	< 60 min	Passed · zero records lost
Storage linkage	4 min 10 sec	< 30 min	Passed
Vector re-ingestion	42 min 15 sec	< 120 min	Passed

Open security and governance Request architecture review

Plain-language glossary

Technical terms used throughout this reference.

These definitions describe how the terms are used in Orion so product, engineering, estimating, security, and procurement teams can review the same system without translating between disciplines.

Orion technical glossary
Term	Meaning in Orion
Addressable artifact	A stored text, page, image, or component record with enough identity and locator metadata to retrieve and cite it again.
Bounding box	Normalized page coordinates that identify a visual region such as a material callout or detail and can support highlighting or cropping.
Embedding	A numerical representation used to compare the meaning or visual similarity of project evidence and a retrieval question.
Fan-out / fan-in	Running bounded evidence searches or specialist tasks in parallel, then joining their validated results into one stable record.
MCP	Model Context Protocol: an integration standard for exposing approved tools and context to compatible AI applications over controlled transports.
Multimodal	Using more than extracted text-for Orion, this includes rendered sheets, single-page PDFs, native page/image representations, and localized components.
Native representation	A search representation created from a complete source form, such as the full page PDF or rendered drawing, instead of only a text transcription.
Provenance	The source hash, model/schema version, document, page, and processing identity that explain where an artifact came from and whether it can be reused.
Reranking	A second relevance pass that reorders retrieved evidence against the primary question after the initial search.
RTO / RPO	Recovery Time Objective is the targeted maximum service-recovery time; Recovery Point Objective is the targeted maximum recoverable data-loss window.
Typed schema	A validated output shape with required fields and allowed value types, used to keep needs, measurements, BOM rows, and report sections structurally consistent.
WAL	Write-Ahead Logging: the database recovery log used with snapshots and point-in-time recovery to restore relational state.

Technical FAQ

Questions about representation, measurement, analysis, and adoption.

The useful question is not only whether Orion can produce an answer, but what evidence, state, calculation, and approval path travel with it.

Is Orion only OCR plus semantic search?

No. Text extraction is one representation. Full ingestion also retains single-page PDFs, rendered images, native page and image embeddings, structured visual summaries, and component crops where available. Retrieval combines scoped semantic search, text reranking, native-image matches, and stable source addressing before typed analysis begins.

Does every page produce every artifact?

No. Artifact availability depends on page content and processing status. Text-heavy pages may produce many text chunks; drawing-heavy pages may contribute stronger image or component records. A failed visual pass can leave a marked text/raw-asset stub, while extraction failures remain visible in partial coverage.

How are calculations kept inspectable?

Orion separates evidence identification from local arithmetic and confidence calculation. A measurement can retain geometry type, scale basis, formula, named inputs, units, assumptions, source references, cross-checks, conflict flags, and verification status. Missing scale or dimensions become needs-input questions rather than silent values.

What are BALLPARK, TAKEOFF, and QUOTE_READY?

They are configurable estimating-accuracy profiles. BALLPARK prioritizes rapid qualification from documented sources and bounded heuristics. TAKEOFF adds broader independent scale and geometry analysis. QUOTE_READY applies strict per-opportunity verification, BOM reconciliation, and engineering review. The selected profile and any remaining reviewer approvals stay visible.

Are the analysis agents free to return any answer shape?

Core stages request and validate typed schemas for needs, engineering analysis, BOM rows, report narrative, drill-downs, and actions. Schema validation protects structure; source citations, calculation traces, QA stages, and human review protect meaning.

How does a customer verify Orion before adoption?

Use representative documents and agreed acceptance criteria. Inspect intake validation, page artifacts, retrieval scope, citation behavior, measurement states, warning handling, output accuracy, tenant controls, deletion behavior, integrations, and the human approval path with the people who own those decisions.

Evaluate the real workflow

Bring representative sources and the questions your reviewers actually ask.

A useful technical review inspects page artifacts, retrieval scope, measurement support, report warnings, output accuracy, security controls, and the human decision path against agreed acceptance criteria.

Request a walkthrough Open the feature reference