Primary users
CEA project developers, project sponsors, owner’s representatives, and technical or commercial review teams.
CEA PROJECT DECISION SUPPORT
Structure the evidence behind a CEA project decision.
The Crop Urbanis Platform is a controlled-environment agriculture project decision-support system in development for vertical farms and hydroponic greenhouses. It links project requirements, supplier claims, assumptions, calculations and professional reviews so that alternatives can be compared before configuration, procurement and delivery commitments are made.
Current stage: internal MVP · selected organisational validation and private-beta scopes by agreement
The internal MVP is being developed around project definition, supplier comparison, scenario review and decision recording. Public self-service is not available.
INITIAL USE
Built for decisions that are difficult to review in disconnected files.
CEA project decisions draw on crop targets, facility and utility constraints, supplier proposals, operating assumptions, budgets and delivery dependencies. The Platform brings that reasoning into one project record without treating every source or number as equally reliable.
Decision stages
Project definition, concept and feasibility review, configuration comparison, supplier selection, and review of material changes.
Core result
A source-linked record of what is known, declared, calculated, assumed, unresolved and approved.
CORE WORKFLOW
From source material to a reviewed decision.
The Platform organises the reasoning behind a project decision. Each step preserves the source, status, assumptions, review history and downstream use of material information.
-
01. Establish the project baseline
Record the project objective, site, intended market, crop and production targets, facility and utility constraints, budget, schedule, decision owners and unresolved questions.
-
02. Capture source claims
Bring permitted project and supplier material into the workspace while retaining the original document, source location, wording, version and access conditions.
-
03. Map requirements and alternatives
Connect claims to project requirements; normalise units and terminology; identify missing operating conditions; and make alternative configurations comparable.
-
04. Build design cases
Apply versioned physical, production, utility and financial calculations to explicit assumptions and ranges. Each design case records its model version and validity conditions.
-
05. Review uncertainty and dependencies
Show which inputs are verified, estimated, disputed or unknown; identify sensitivity drivers; and record which conclusions depend on them.
-
06. Record and carry forward the decision
Store the selected alternative, rationale, reviewers, unresolved conditions and affected downstream requirements for procurement, delivery, commissioning or handover.
PLATFORM CAPABILITIES
Four capabilities in one decision workflow.
The internal MVP is organised around four connected capability groups. Availability in any organisational beta depends on the project objective, permitted data and named review roles.
01. Project baseline and requirements
Structure project context, requirements, constraints, responsibilities, evidence gaps and validation questions.
Output: project baseline and requirement register.
02. Supplier evidence and configuration comparison
Retain supplier claims with their sources and operating conditions; normalise comparable values; and identify omissions, exclusions and requirement conflicts.
Output: comparison matrix and clarification log.
03. Scenario and decision analysis
Compare physical, production, utility and financial design cases through explicit assumptions, ranges, model versions and sensitivity analysis.
Output: scenario summary and decision-readiness record.
04. Decision continuity
Record reviews, approvals, rationale, dependencies and changes; identify affected work when an input changes; and carry accepted information into downstream project requirements.
Output: decision record and implementation or handover inputs.
EVIDENCE AND UNCERTAINTY
A precise value is not automatically a verified fact.
The project record is being designed to preserve the origin, status and review history of material values. Correct extraction does not turn a supplier statement, literature value or expert estimate into a measured project fact.
- Measured or verified
- Established through an accepted measurement or verification route.
- Client-provided
- Supplied by the project organisation but not independently verified by the Platform.
- Supplier-declared
- Stated by a supplier together with the applicable source and operating conditions.
- Literature-derived
- Taken from a cited technical, scientific or regulatory source.
- Calculated
- Produced by a named and versioned calculation model.
- Expert-estimated
- Entered by a reviewer as professional judgement for a stated scope.
- Assumed
- Introduced for a design case and awaiting confirmation.
- Unknown
- Required information is absent, contradictory or not usable.
Evidence status and review status remain separate. A value may be extracted with high confidence and still require supplier confirmation or professional validation.
CHANGE IMPACT
When a material input changes, affected work becomes visible.
CEA decisions are interdependent. A change in crop mix, target daily light integral, utility availability, supplier capacity, schedule or energy price may affect equipment requirements, heat and moisture loads, production assumptions, CAPEX/OPEX and earlier approvals.
The project model is being developed to record these dependencies and identify the comparisons, calculations, decisions and downstream requirements that may need review.
- Changed project input
- affected requirements
- design cases requiring recalculation
- decisions requiring review
- updated downstream outputs
Illustrative dependency
- Changed crop mix
- different lighting and environmental requirements
- revised utility and equipment assumptions
- affected operating-cost scenario
- supplier decision returned for review
The Platform identifies work that may require review; it does not decide whether the changed configuration is technically or commercially acceptable.
ILLUSTRATIVE WORKFLOW
Three supplier proposals. One reviewable decision.
A project team receives three proposals for lighting, HVAC and irrigation packages. The documents use different units, scope boundaries and operating conditions. Some values are directly comparable; others are incomplete, conditional or based on different project assumptions.
A project team receives three proposals for lighting, HVAC and irrigation packages. The documents use different units, scope boundaries and operating conditions. Some values are directly comparable; others are incomplete, conditional or based on different project assumptions.
The Platform keeps each source claim, maps it to the same project requirements, flags missing conditions and candidate conflicts, and compares agreed design cases under one explicit set of assumptions.
Proposal A
Proposal B
Proposal C
Normalised project comparison
- Requirements
- Operating conditions
- Assumptions
- Clarifications
- Design cases
Reviewed decision
Reviewers can then see:
- Which values are directly comparable
- Which claims require clarification or supplier confirmation
- Which assumptions drive the result
- Which earlier conclusions change when an input changes
- Why an alternative was selected or rejected
Illustrative workflow only; not a customer case study or performance claim.
DIVISION OF RESPONSIBILITY
AI assists. Calculations reproduce. Uncertainty remains visible. People decide.
The Platform separates document assistance, reproducible computation, uncertainty handling and professional responsibility.
AI assistance
Extracts candidate claims from permitted documents, maps terminology, retrieves approved references and flags possible omissions, inconsistencies or requirement conflicts. AI outputs remain linked to sources and subject to review.
Rules and calculations
Apply unit conversions, completeness and compatibility checks, capacity calculations and versioned scenario models. The same approved inputs and model version produce the same result.
Uncertainty handling
Distinguishes fixed values, estimates, ranges, disputed inputs and unknowns; shows sensitivity; and avoids presenting uncertain biological or commercial inputs as confirmed facts.
Professional responsibility
Agronomists, engineers, suppliers, project owners and commercial reviewers confirm inputs and approve consequential decisions within their own scope.
CURRENT PRODUCT BOUNDARY
Project decision support—not live greenhouse control.
The current product focus is project definition, evidence comparison, design-case review and decision recording. It is not presented as an operating greenhouse platform.
Current focus
- Project baseline and requirements
- Permitted-document extraction and source linking
- Supplier and configuration comparison
- Explicit assumptions and versioned design cases
- Sensitivity and unresolved-information review
- Professional review and decision records
- Selected procurement, commissioning and handover inputs
Not claimed
- Control of climate, irrigation or greenhouse equipment
- Autonomous agronomy or engineering approval
- Promises concerning yield, cost, return or delivery performance
- Investment advice
- Public self-service
- An always-connected or operational digital twin
A later operating-data layer may compare approved project assumptions with measured performance under separately governed data, integration and review conditions.
Selected organisations may be considered for an agreed scope covering project purpose, permitted data, authorised users, capability groups, review roles, evaluation criteria, support, export and retention. Public forms accept high-level context only.
PRODUCT STATUS
Review current status and technical boundaries.
The following resources separate product scope, technical implementation and data responsibilities.
MVP & Private Beta
Current development stage, organisational beta conditions, capability status and roadmap.
Technology
Project data flow, AI role, calculation services, model governance, review controls and evaluation approach.
Security & Data
Public-form boundary, private-beta access, permitted data, organisational roles and data-handling principles.
Product Overview
A concise downloadable summary of the problem, workflow, product status and intended use.
Discuss a suitable project or validation scope.
Share high-level organisational context, the project stage, the decision to be supported, relevant data categories and the responsible reviewers. Confidential project or supplier files should not be submitted through the public form.