Latest drawing revision?
The register says Rev 4, a shared folder contains Rev 3, and an email attaches Rev 5.
AI readiness
Move from a broad AI ambition to one defined use case with usable evidence, controlled access, accountable people, reliable systems, measurable acceptance, and sustainable operating cost.
AI readiness map
The ten areas are connected but not strictly linear. Start with the use case, then open the evidence, control, and viability guides that expose the largest gaps for that workflow.
Define
Start with one measurable business outcome, its owner, operating pressure, risk, and approval boundary.
Prepare
Establish the records, document controls, quality rules, and retrieval path needed by the selected workflow.
Business Data Readiness
Define identities, relationships, source authority, lineage, ownership, and permissions.
Open guideDocument Readiness
Prepare OCR, classification, layout, extraction, revisions, permissions, and citations.
Open guideData Quality
Measure completeness, accuracy, consistency, uniqueness, timeliness, validity, and ownership.
Open guideRetrieval Readiness
Control metadata, search, ranking, versions, permissions, citations, and uncertainty.
Open guideControl
Make access, accountability, infrastructure, state, monitoring, recovery, and maintenance explicit.
Permissions and Security
Map identities, record scope, tool rights, credentials, approval, audit, and incidents.
Open guideTeam and Tool Readiness
Assess sponsorship, operating roles, approved tools, training, change, support, and handover.
Open guideSystem Readiness
Assess integrations, identities, state, queues, observability, scale, versions, and fallback.
Open guideProve
Define acceptance evidence and understand complete workflow economics before production expansion.
Evaluation Readiness
Prepare representative cases, rubrics, thresholds, failures, regression tests, and monitoring.
Open guideUnstructured Data Cost
Measure search, preparation, verification, failures, AI, retrieval, infrastructure, and review.
Open guideProvider-neutral by design
StructuredLayer does not begin with an agent, chatbot, or model subscription. It establishes client-owned operating context, controls, evidence, acceptance, and ownership that can support suitable approved tools.
Complete AI context path
The operating path connects business records to an approved model while preserving permission filters, citations, human review, and controlled write-back.
Connected records
Permission filters
Current evidence
Focused retrieval
Approved model
Cited answer
Human review
Controlled write-back
Context cost
Costs grow when a system cannot isolate the small amount of information required for a task and repeatedly sends large, duplicated, or outdated context to the model.
Entire contract
Drawing revisions
Long email thread
Multiple spreadsheets
Duplicate proposals
Outdated notes
Potential cost chain
Model processing + repeated context + tool calls + employee verification + mistakes and rework
Retrieval before reasoning
The goal is not to promise a fixed token reduction. It is to retrieve a smaller, more relevant, permission-appropriate evidence set and measure the effect in the client’s actual workflow.
Keep one authoritative record or clearly identify current and historical versions.
Store project number, client, value, owner, status, dates, and relationships as usable fields.
Tag documents by project, company, type, revision, date, status, owner, and permission.
Connect documents, emails, contacts, estimates, change orders, and projects with reliable identifiers.
Identify which record or version controls the value, status, document, or decision.
Filter by project, date, type, status, owner, and access permission before involving the model.
Send only the current fields and document sections needed for the specific question.
Broad context
Hundreds of mixed documents
Duplicates, historical versions, unrelated files, and unclear authority passed into retrieval.
Focused evidence set
Current records and relevant sections
The approved contract section, latest change record, relevant messages, current project fields, and links to each source.
Operational evidence
The task record preserves what the system was asked to do, what evidence it used, which permissions applied, what it returned, and what an authorised person decided.
A model may select one number, combine values incorrectly, or present an assumption as an answer when documents conflict and their relationships are undefined.
Current contract value?
Signed contract
$2.1m
Project spreadsheet
$2.3m
Approved email change
+$200k
Until the change, status, and authority rules are defined, the model has context but not operational truth.
Latest drawing revision?
The register says Rev 4, a shared folder contains Rev 3, and an email attaches Rev 5.
Practical completion date?
The signed programme says 30 September, the planner says 15 October, and the weekly report shows a 22 September target.
Change order status?
A draft shows $80k, the approval register shows $45k, and the email thread still says pending review.
Supplier invoice paid?
The inbox shows received, the accounting ledger shows unpaid, and the bank export shows cleared.
Access and evidence
Both improve the operating conditions around an answer. Neither guarantees correctness, so validation and professional judgement remain necessary.
Restrict retrieval by company, project, department, role, client, document classification, record-level access, and approved workspace.
A smaller approved search space can improve relevance while reducing the chance of exposing pricing, contracts, payroll, employee, or cross-client information.
A useful answer can include the source record or document, version, relevant date, page or section, direct link, and a warning when approved sources conflict.
Citations allow a person to inspect the evidence, challenge the interpretation, and preserve a more useful review history.
Provider data boundary
Before production use, the engagement separates each provider behaviour and confirms the approved account, settings, data categories, location, contractual terms, and deletion controls.
Which approved data is sent for a specific request, through which model and provider, and for what documented purpose.
Whether prompts, files, embeddings, outputs, or cached context are stored and in which approved account or region.
Which prompts, tool calls, outputs, errors, user identities, and review decisions remain available for operations or audit.
How long provider and application copies remain, what deletion controls exist, and how backups or legal holds affect removal.
A separate use that is not approved by default. It requires explicit review of purpose, terms, data, authority, and provider settings.
Client information is not approved for model training by default. A permitted request for summarisation or extraction does not itself authorise any broader provider use.
Review data controlsEvaluation before production
We create an evaluation set from approved examples and test whether the system retrieves the correct records, respects permissions, cites the correct evidence, identifies conflicts, refuses unsupported answers, and routes consequential actions for review.
Evaluation covers retrieval, evidence, permissions, uncertainty, human correction, response time, and operating cost against approved cases.
Correct source retrieved
Current version selected
Citation accuracy
Answer completeness
Permission leakage
Unsupported-claim rate
Conflict detection
Human correction rate
Response time
Cost per completed task
Different tasks may use deterministic code, local models, lower-cost hosted models, or frontier models. Selection depends on sensitivity, complexity, measured accuracy, latency, and cost. Business records remain independent of the selected model provider.
Action authority
The approval boundary follows the consequence of the action, the authority required, and the reliability of the available evidence.
Assessment output
The assessment turns a general AI ambition into a documented readiness decision, measured evaluation path, and sequenced operating plan.