A source claim is not automatically a project fact
A supplier statement, client-provided value or literature reference remains a source claim until its applicability, operating conditions, evidence status and review state are recorded.
CEA PROJECT TECHNOLOGY
A technical path from source document to reviewed CEA decision.
The Crop Urbanis Platform is organised around a versioned project model rather than a general-purpose AI assistant. Source material, extracted claims, requirements, assumptions, calculation models, reviews and decisions remain distinct but connected. AI assists bounded information tasks; rules and calculation services apply explicit transformations; responsible people approve consequential use.
Internal MVP · organisational deployment hardening in progress · selected private-beta scopes by agreement
The current technical focus is project evidence, supplier comparison, design-case review and decision continuity—not live greenhouse control.
TECHNICAL PRINCIPLES
The architecture preserves distinctions that affect trust.
The Platform does not treat every extracted value, generated sentence or calculated result as the same kind of information. Three distinctions govern the technical design.
A reproducible calculation is not a guaranteed outcome
The same approved inputs and calculation-model version should produce the same result. Biological, commercial and operating uncertainty remains explicit rather than disappearing inside the calculation.
AI assistance is not professional approval
AI may extract, map, retrieve, compare and draft. Named agronomic, engineering, supplier, commercial and project authorities remain responsible for confirmation and approval within their scope.
LOGICAL ARCHITECTURE
Six layers from permitted source to structured export.
The diagram describes functional responsibilities. It does not imply that every responsibility is deployed as a separate service or that every later integration is already available.
01. Intake and permission boundary
Create the project and organisation context; identify authorised users and review roles; register permitted source files, versions, ownership, access conditions and intended use.
02. Provenance-preserving extraction
Classify documents and extract candidate values, statements and tables while retaining the original source, source location, wording, raw value, document version and extraction state.
03. CEA project model
Connect source claims to project objects, requirements, constraints, assumptions, alternatives, risks, owners and dependencies.
04. Rules and design-case services
Apply unit conversions, completeness checks, compatibility rules, physical and production calculations, utility models, financial models, sensitivity analysis and explicit project gates.
05. Review, change and approval
Record corrections, clarification requests, unresolved issues, professional reviews, approval states, decision rationale and the work affected by a changed input.
06. Output and integration boundary
Produce source-linked comparisons, assumption registers, design-case summaries, decision records and downstream project requirements; expose structured exports or integrations only where supported.
- Permitted sources
- Candidate claims
- CEA project model
- Rules and design cases
- Professional review
- Decision and structured output
Version · source · owner · status · dependency · audit event
PROJECT DATA MODEL
The data model links evidence, CEA objects and decisions.
The project model is not only a file index. It represents the objects and relationships needed to explain where a material value came from, how it is used, what depends on it and who reviewed the resulting decision.
Decision records
- Project
- Source document and source version
- Source claim
- Requirement
- Constraint
- Assumption
- Alternative
- Design case
- Issue or risk
- Review
- Decision
- Output
CEA domain objects
- Site and facility zone
- Crop, cultivar and marketable product
- Production target and crop cycle
- Environmental requirement
- Lighting, HVAC, irrigation and other equipment
- Utility source, limit and tariff
- Supplier and proposal
- Capacity, cost and schedule basis
Control records
- Organisation, user and role
- Owner and responsible reviewer
- Permission and permitted purpose
- Model version and validity scope
- Dependency
- Approval state
- Effective version
- Audit event
- Source document
- Source claim
- Requirement or constraint
- Assumption
- Model input
- Design case
- Professional review
- Decision
- Downstream requirement or output
Side relationships
Illustrative conceptual model; not a public database schema.
MATERIAL PROJECT VALUES
A technical value travels with its source and operating conditions.
A number without its measurement basis, operating conditions and project scope can create false comparability. The Platform therefore treats a material value as a record rather than an isolated cell.
- Original source statement
- The wording, table entry or image context from which the value was obtained.
- Source reference
- Document, document version and page, section, table or other source location.
- Raw value
- The value and unit exactly as supplied or extracted.
- Normalised value
- A comparable representation created through an explicit unit or terminology transformation.
- Operating conditions
- The environmental, equipment, measurement, duty or commercial conditions under which the value is stated to apply.
- Evidence status
- Measured, client-provided, supplier-declared, literature-derived, calculated, expert-estimated, assumed or unknown.
- Extraction confidence
- How confidently the extraction process identified the source content—not whether the content itself is correct.
- Review status
- Unreviewed, accepted, corrected, rejected or unresolved.
- Validity scope
- The crop, facility, configuration, geography, time period or design conditions for which the value may be used.
- Version and dependencies
- The effective version and the requirements, calculations, comparisons or decisions that depend on the value.
CONFIDENCE AND STATUS
“Confidence” is not one field.
Extraction reliability, evidence type, professional acceptance and real-world uncertainty answer different questions and must remain separate.
Did the system read the source correctly?
Extraction confidence describes the reliability of document recognition and field extraction.
What kind of evidence supports the value?
Evidence status distinguishes measurements, supplier declarations, literature, calculations, expert estimates and assumptions.
Has a responsible person accepted it?
Review status records whether the value remains unreviewed, has been corrected, has been accepted for a defined scope or remains unresolved.
How uncertain is the real-world quantity?
Uncertainty describes ranges, variability, disputed inputs and limits on prediction even where the source was read correctly and professionally reviewed.
A value can have high extraction confidence, remain a supplier declaration, be accepted for comparison and still carry substantial real-world uncertainty.
AI TASKS AND RELIABILITY
AI works on bounded information tasks.
Language models are used where project information is unstructured or terminology varies. Each task should have a defined input scope, expected structure, validation route and review condition.
AI may assist with
- Document classification
- Candidate field and claim extraction
- Technical terminology mapping
- Retrieval from permitted project or reference material
- Draft comparison notes
- Draft clarification questions
- Multilingual transformation where separately validated
Each task is bounded by
- A named task type
- Permitted input sources
- Expected output schema
- Required source references
- Model and task version
- Validation rules
- Retry or exception limit
- Required review state
AI does not own
- Source authority
- Final unit or calculation semantics
- Confirmation of supplier warranties or compliance
- Agronomic or engineering approval
- Commercial selection
- Project acceptance
- Live greenhouse control
When a required input is missing or an output fails validation, the workflow records an exception or returns the item for review instead of fabricating completion.
The system may flag candidate inconsistencies, missing conditions and requirement conflicts. A reviewer determines whether a flagged difference is technically material.
MODEL GOVERNANCE
Calculations are versioned; design cases remain conditional.
Rule-based checks, engineering calculations, production models, financial models, expert assumptions and AI outputs are different classes of technical object. They should not be presented under one generic “scenario engine.”
A calculation-model record should contain
- Model identifier and type
- Owner
- Version
- Equation, method or reference basis
- Required inputs and units
- Validity conditions and expected ranges
- Test or benchmark cases
- Validation status
- Known limitations
- Affected outputs
Model classes
Rules and completeness checks
Required fields, unit compatibility, threshold checks, schema conditions and project gates.
Engineering and capacity calculations
Equipment capacity, utility demand, environmental loads and compatibility relationships.
Production and resource models
Crop cycles, production assumptions, growing-area use, water, energy and labour assumptions.
Techno-economic models
CAPEX, OPEX, revenue assumptions, sensitivity and design-case comparison.
Expert assumptions
Project-specific values entered for unresolved conditions and retained with an owner, rationale and uncertainty status.
AI outputs
Extracted candidates, classifications, retrieved context or drafts that remain subject to validation and review.
Validation status
Exploratory
The method is under definition or has not completed an internal benchmark.
Internally tested
Defined test or benchmark cases have been run internally for a stated scope.
Externally validated
A documented independent, partner or field evaluation has been completed for a stated scope.
- Internal testing does not imply external validation.
- A design case is a conditional comparison, not a forecast or guarantee.
- Reproducibility describes the calculation process. It does not remove uncertainty from biological, commercial or operating inputs.
REVIEW AND CHANGE CONTROL
Review states and change impact are part of the project data.
Material claims, assumptions and design cases can remain unreviewed, be accepted, corrected, rejected or left unresolved. A review record identifies the reviewer, professional scope, comments, effective version and any remaining conditions.
A decision record identifies the owner, alternatives considered, evidence used, selected option, rationale, rejected options, unresolved conditions, required approvals and effective version.
The project model is being extended to identify the requirements, comparisons, design cases, decisions and downstream outputs that may require review when a material input changes.
- Changed input
- Affected dependency
- Recalculation or renewed comparison
- Professional review
- Updated decision or unresolved issue
Change-impact logic identifies potentially stale work. It does not automatically approve the revised technical or commercial conclusion.
EVALUATION
Evaluate the components separately before expanding the workflow.
An end-to-end result can hide whether an error came from extraction, terminology, source selection, calculation, project context or professional interpretation. Evaluation is therefore divided by component and deployment condition.
Document extraction and normalisation
- Critical-field precision and recall
- Source-location accuracy
- Table and unit-normalisation error
- Missing-field recall
- Reviewer correction rate
- Reviewer time per document
Retrieval and AI assistance
- Source and citation accuracy
- Relevant-context coverage
- Unsupported-output rate
- Appropriate exception or abstention rate
- Reviewer acceptance, correction and rejection
- Performance by document and equipment class
Data and calculation services
- Required-field and schema coverage
- Dimensional and unit consistency
- Reproducibility
- Benchmark-case deviation
- Sensitivity-ranking stability
- Affected-record detection after a changed input
End-to-end workflow
- Time to a reviewable comparison
- Number of unresolved critical inputs
- Professional review time
- Decision-record completeness
- Clarification-cycle count
- Critical error escape rate
These are evaluation classes, not published performance results. Any reported result should identify the dataset or project class, baseline, metric definition, model and workflow version, review conditions and known limitations.
Each metric family should be labelled with one current measurement state:
- Protocol in definition
- Internal baseline in progress
- Internally measured
- Externally evaluated
INTEROPERABILITY
Structured for integration without claiming standards compliance.
The project model is designed around stable identifiers, explicit units, source references, versions and structured records. This preserves future mapping and export options without claiming that the current internal MVP is certified against, or natively compatible with, an external standard.
Domain-specific mappings will be evaluated only where a real built-asset, supplier, agricultural or sensor-data integration requires them.
DEPLOYMENT BOUNDARY
Internal workflow first; organisational hardening next.
The logical architecture and organisational deployment stage are not the same thing. The core workflow can operate internally while identity, isolation, monitoring, recovery and support controls continue to be hardened for selected organisations.
Current internal workflow
- Versioned project records
- Permissioned source files
- Document-processing workflow
- Retrieval and AI task services
- Rules and calculation services
- Review and decision records
- Structured output generation
Organisational hardening
- Authentication and organisation controls
- Role and permission configuration
- Tenant and workload separation
- Monitoring and audit visibility
- Data-lifecycle controls
- Backups and recovery
- Deployment automation
- Cost and operational controls
Later integration work
- Standard project-system integrations
- Operating-data feedback
- Image and sensor workflows
- Advanced analytics
- Cross-project learning under governed data conditions
Deployment planning prioritises explicit organisation, user, purpose, data, provider, region, retention, export, deletion, support and incident conditions. Detailed controls are described on the Security & Data page and agreed separately for any private-beta scope.
TECHNICAL RESOURCES
Review implementation status, data boundaries and evaluation work.
MVP & Private Beta
Current capability status, access conditions, known limitations and roadmap.
Security & Data
Public-form separation, authorised access, permitted data, providers, retention and professional responsibility.
Research
Research questions, evaluation protocols, datasets, limitations and future validation.
Technical Brief
A concise partner-facing summary of logical architecture, deployment status, workloads and controls.
Discuss a technical or validation scope.
Share high-level context about the project stage, source-document classes, decision to be supported, expected outputs, responsible reviewers and relevant data conditions. Confidential project or supplier files should not be submitted through the public website.