A question precedes a capability claim
Each research activity begins with a defined problem and a testable hypothesis. A list of implemented features is not a research result.
APPLIED CEA RESEARCH
Test how CEA project evidence becomes more comparable, reviewable and reusable.
Crop Urbanis conducts applied research alongside Platform development. The programme studies whether CEA-specific project structures, source-linked supplier-document processing and uncertainty-aware design-case review can reduce unresolved information and professional review effort before material project commitments are made.
Current public status: programme framework defined · research status reported by track · no external performance result claimed unless separately published
The programme does not assume that adding more AI improves a project decision. It tests whether better structure, provenance, domain context, calculation governance and professional review produce measurable improvements over existing document and spreadsheet workflows.
RESEARCH QUESTION
Can a CEA-specific evidence, requirements and assumption model reduce unresolved project information and professional review effort before project commitments—without concealing uncertainty or transferring responsibility to AI?
This question connects the three primary research tracks: how CEA project information should be represented, how heterogeneous supplier evidence should be normalised, and how conditional design cases should be calculated and reviewed.
The programme does not treat software completion, internal use or a successful demonstration as sufficient evidence of improvement. Improvement requires a defined comparator, evaluation material, metrics, acceptance conditions and stated limitations.
RESEARCH PRINCIPLES
Research claims follow evidence, not product language.
A baseline precedes an improvement claim
The proposed method is compared with a defined existing workflow, generic method or earlier version. Numerical thresholds are fixed before results are interpreted.
Context precedes transfer
A result is reported with its crop, facility, equipment, document, language, project stage and operating context. Performance in one context is not silently generalised to another.
Implementation and validation remain separate
A capability may be implemented without being validated. Internal testing, external evaluation and published evidence are reported as different states.
Limitations remain part of the result
Negative findings, null results, exceptions and conditions of failure are retained rather than removed from the public interpretation.
STUDY RECORD
Every reported study states what was tested and what would count as progress.
Research records use a common structure so that a protocol, an internal result and an externally evaluated result cannot be confused.
- Research question and hypothesis
- The problem being investigated and the expected difference between the proposed method and its comparator.
- Evaluation scope
- The relevant project stage, facility class, crop or equipment class, document type, language and intended use.
- Evaluation material
- The permissioned, anonymised or synthetic records, documents, design cases or reviewer tasks used in the study.
- Comparator or baseline
- The manual workflow, generic extraction method, existing spreadsheet process or earlier system version used for comparison.
- Metrics and acceptance conditions
- The quantitative and qualitative measures fixed before evaluation, including any condition that would prevent advancement.
- Versions and conditions
- The schema, model, workflow, prompt, calculation and dataset versions together with material operating conditions.
- Review roles
- The professional roles involved in accepting, correcting, rejecting or escalating outputs.
- Result and evidence status
- Whether the work remains at question definition, protocol, baseline, internal evaluation, external evaluation or publication stage.
- Limitations and transfer boundary
- Known failure modes, excluded contexts and the conditions under which the result should not be generalised.
EVIDENCE STATUS
Research status is not product status.
The MVP & Private Beta page reports whether a capability is designed, implemented, internally usable or available within an agreed beta. The Research page reports the maturity of the evidence supporting a method.
Question defined
The problem, intended context and hypothesis have been stated.
Protocol fixed
Evaluation material, comparator, metrics, thresholds and review conditions have been defined before testing.
Baseline measured
The existing workflow or comparator has been evaluated using the same study conditions.
Internal evaluation completed
The proposed method has been tested internally and its limitations recorded.
External evaluation completed
A documented partner, independent reviewer or external study has evaluated the method for a stated scope.
Result published
The protocol, result, scope, versions and limitations are available in a public research record.
“Operational,” “implemented” and “internally usable” are product-status terms. They are not research-evidence terms.
ACTIVE RESEARCH PROGRAMME
Three research tracks support the current Platform direction.
The tracks are defined around project decisions rather than software modules. Agronomic retrieval, AI assistance, professional review and change-impact testing operate across the programme.
CEA project information and decision model
- Research question
- What minimum CEA-specific structure is required to keep project evidence, requirements, constraints, assumptions, alternatives, calculations, reviews, decisions and downstream requirements connected?
- Hypothesis
- A CEA-specific project model will represent a larger share of decision-critical information with fewer ad hoc fields and fewer unlinked records than a generic file-and-spreadsheet workflow.
- Evaluation design
- Evaluate the model using permissioned, anonymised or synthetic project records from defined decision stages. Each study should state the facility type, crop or production context, project stage and categories of information included.
- Comparator
- A generic project schema, existing spreadsheet-and-document workflow or earlier internal schema version.
- Primary measures
- Decision-critical information coverage
- Custom-field rate
- Ambiguous-mapping rate
- Unlinked or orphaned claim rate
- Completeness of source and ownership records
- Inter-reviewer agreement
- Affected-record detection after a seeded change
- Professional review time
- Advance condition
- The schema should advance only where it improves coverage without creating unacceptable ambiguous mappings, custom-field growth or reviewer disagreement. Thresholds must be fixed before each evaluation.
- Current public status
- Question defined. The conceptual model and internal workflow are under development; no public coverage baseline or external validation result is claimed.
- Known limitation
- Coverage in one facility, crop, region or project stage does not establish adequate coverage in another.
- Product relationship
- This track informs the Platform’s project-baseline, requirement, decision-continuity and change-impact functions, and the Technology page’s CEA project model.
- Next study
- Run a schema-coverage and reviewer-agreement study across at least two clearly defined CEA decision contexts using synthetic or permissioned records.
Supplier evidence normalisation and comparison
- Research question
- Can equipment-class-specific schemas convert heterogeneous supplier documents into comparable source-linked claims without hiding missing operating conditions or reviewer corrections?
- Hypothesis
- A CEA-specific extraction and normalisation workflow will reduce critical comparison errors and professional review time compared with generic extraction or ad hoc manual comparison.
- Evaluation design
- Evaluate one equipment or document class at a time using permissioned or synthetic proposals. Preserve original wording, source location, raw value, normalised value, unit, operating conditions, evidence status and review outcome.
- Comparator
- Manual document comparison and, where suitable, a generic document-extraction baseline.
- Primary measures
- Critical-field precision and recall
- Source-location accuracy
- Unit-normalisation error
- Operating-condition completeness
- Missing-field recall
- Candidate-conflict precision
- Reviewer correction rate
- Reviewer time per document
- Performance by equipment, document and language class
- Advance condition
- A workflow should not be promoted to another equipment class, language or document type until the relevant baseline, critical-field requirements, exception behaviour and professional-review conditions have been evaluated for that new context.
- Current public status
- Question defined. The evaluation protocol and permissioned or synthetic material are being prepared; no public benchmark result is claimed.
- Known limitation
- Correct extraction does not verify that a supplier claim is accurate, guaranteed or applicable to the proposed project.
- Product relationship
- This track informs supplier evidence, configuration comparison, clarification workflows and provenance-preserving extraction.
- Next study
- Run a small blind professional review on one defined equipment class, comparing the source-linked workflow with manual or generic extraction.
Design-case validity, uncertainty and professional review
- Research question
- Can physical, production, utility and financial design cases remain reproducible while exposing uncertainty and identifying conclusions that become stale after a material input changes?
- Hypothesis
- Versioned models, explicit validity conditions, evidence statuses, input ranges, sensitivity analysis and review gates will reduce false precision and stale outputs compared with unversioned static scenarios.
- Evaluation design
- Use defined scenario sets, benchmark calculations and seeded changes or errors. Each evaluation should identify the model class, inputs, units, validity conditions, assumed ranges, model version and professional review scope.
- Comparator
- An unversioned spreadsheet, static scenario or earlier calculation workflow without explicit dependency and review records.
- Primary measures
- Calculation reproducibility
- Dimensional and unit consistency
- Benchmark-case deviation
- Sensitivity-ranking stability
- Detection of affected records after a changed input
- Decision-record completeness
- Reviewer overrides and escalations
- Professional review time
- Unresolved critical-input count
- Advance condition
- A model class should not move beyond exploratory status until its method, input requirements, benchmark cases, validity scope, known limitations and responsible reviewer are documented.
- Current public status
- Question defined. Model-governance and seeded-change evaluation protocols are being prepared; no external validation or project-performance claim is made.
- Known limitation
- A reproducible design case remains conditional on its inputs. It is not a prediction or guarantee of realised yield, cost, return, equipment performance or delivery outcome.
- Product relationship
- This track informs design-case comparison, uncertainty handling, change impact, review states and decision records.
- Next study
- Run benchmark and seeded-change tests on a limited calculation set, followed by professional review of affected assumptions, outputs and decision records.
CROSS-CUTTING EVALUATION
Four evaluation problems apply across the programme.
Agronomic evidence transferability
Retrieval quality is not assessed only by whether the system found a relevant sentence. A retrieved claim should retain the context required to judge whether it is transferable to the project.
Relevant context
- Crop and cultivar
- Production system
- Facility type
- Development stage
- Environmental conditions
- Geography or climate
- Experimental or commercial scale
- Measurement method
- Evidence class
- Publication or observation date
Measures
- Source and citation accuracy
- Context completeness
- Unsupported-output rate
- Contradiction or disagreement recall
- Appropriate exception or abstention rate
- Professional correction rate
A peer-reviewed result can be accurately retrieved and still be unsuitable as a project assumption.
Human-AI review
Human review is evaluated as part of the system rather than described only as a safeguard. A study should identify who reviews what, what information the reviewer sees, and what happens after acceptance, correction, rejection or escalation.
Measures
- Acceptance rate
- Correction rate
- Rejection rate
- Escalation rate
- Override frequency
- Critical-error escape rate
- Review minutes
- Inter-reviewer agreement
The presence of a human reviewer does not establish that the review process is effective. Review reliability must also be evaluated.
Change and dependency testing
Seeded changes are used to test whether the project model identifies the requirements, calculations, comparisons, decisions and downstream outputs that may have become stale.
Measures
- Affected-record recall
- False affected-record rate
- Recalculation completeness
- Review-state correctness
- Time to identify stale work
- Unresolved dependency count
Detecting a potentially affected record is different from determining the revised technical conclusion.
Operational fit and decision value
A technically accurate method can still fail if it increases professional effort, does not fit existing project work or produces outputs that are difficult to use.
Measures
- Time to a reviewable comparison
- Onboarding and configuration effort
- Reviewer time
- Clarification-cycle count
- Decision-record completeness
- Workflow compatibility
- User-reported usefulness
- Cost per accepted output where measurable
Technology novelty is not treated as a sufficient adoption result.
LONG-HORIZON RESEARCH
Operating evidence is a later model-calibration track.
Research question
Can approved project assumptions be compared with measured operating performance to identify where calculation models, protocols or earlier decisions require recalibration?
Required conditions
- Permissioned operating data
- Sensor identity, units and calibration information
- Time alignment and missing-data rules
- Crop, cultivar and protocol version
- Facility and equipment context
- Defined ground truth or professional annotation
- Baseline and evaluation criteria
- Named review roles
- Data-retention and publication conditions
Potential study outputs
- Assumption-versus-measured comparison
- Model-calibration record
- Protocol-version comparison
- Reviewed operating-issue taxonomy
- Evaluation of whether project assumptions remained valid
Current public status: Long-horizon research only. This track does not imply production deployment, live greenhouse control, autonomous diagnostics or an operational digital twin.
Advance condition: The track should not become active until the data rights, measurement quality, evaluation purpose, baseline and professional-review conditions are defined.
PUBLIC RESEARCH RECORD
Protocols, results and limitations are reported as different artefacts.
Crop Urbanis may publish research questions, evaluation protocols, simplified schemas, synthetic or anonymised evaluation material, aggregate results, limitations, negative findings, model comparisons and revision notes.
A public result should identify:
- The research question and hypothesis
- The evaluation scope and material
- The comparator or baseline
- The metric definitions and thresholds
- The relevant schema, model and workflow versions
- The professional review conditions
- The result date
- The validation type
- Known limitations and excluded contexts
A result is described as externally evaluated only where a documented partner, independent reviewer or external study has evaluated it for a stated scope. Internal testing is not renamed external validation.
Client and supplier data, private-beta identities, proprietary code, security-sensitive implementation details, model-routing controls and commercially sensitive project outputs remain private unless publication is specifically authorised.
Current public material
- Research programme and evaluation framework This page
- Conceptual CEA project model Technology
- Illustrative supplier workflow Platform
- Current product and validation status MVP & Private Beta
SELECTED RESEARCH FOUNDATIONS
The programme builds on established CEA and evaluation problems.
Primary publication
Controlled Environment Agriculture Design Standards
The CEADS programme informs the cross-domain treatment of energy, water, materials, pests, labour, finances and facility-lifecycle considerations.
Research publication
A Collaborative Decision Support System Framework for Vertical Farming Business Developments
This work informs the treatment of partial information, financial risk and collaborative decision support in an emerging sector with scarce validated data.
Peer-reviewed research
Vertical Farming Economics: Crop Performance Targets for Cost-Competitive Vertical Farming
This research informs the distinction between conditional performance targets and predictions of realised commercial outcomes.
Official framework
NIST AI Risk Management Framework
The framework informs context-specific evaluation, documented test sets, uncertainty measurement, human oversight and separation of internal testing from independent review.
Peer-reviewed research
Technology Adoption in the Vertical Farming Industry
This study informs the programme’s attention to operational fit, capital discipline, professional effort and measurable value rather than technological sophistication alone.
These publications are research foundations, not evidence of affiliation or partnership with their authors or organisations.
RESEARCH COLLABORATION
A collaboration begins with a research question and evaluation scope.
Crop Urbanis may work with universities, research groups, CEA developers, operators, equipment suppliers and technical partners where the collaboration can test a defined question without misrepresenting confidential project work as public evidence.
A proposed scope should define
- Research question and hypothesis
- Project, document or model class
- Available and permitted data
- Comparator or baseline
- Metrics and acceptance conditions
- Professional and research review roles
- Intellectual-property and publication conditions
- Security, retention and deletion requirements
- Expected research artefact
- Stop, revise or advance conditions
Possible outputs
- Evaluation protocol
- Synthetic or permissioned evaluation set
- Baseline report
- Aggregate results
- Limitations note
- Simplified schema or taxonomy
- Co-authored technical note where appropriate
A research discussion does not create automatic access to the Platform, private-beta participation, data sharing, publication rights or a public partnership claim.
RELATED RESOURCES
Review the product, technical and data context.
Platform
The intended project workflow, capability groups, evidence statuses, design cases and decision outputs.
Technology
The logical architecture, CEA project model, AI task boundaries, model governance and evaluation approach.
MVP & Private Beta
Current implementation status, organisational access conditions, limitations and roadmap.
Security & Data
Permitted data, authorised access, provider conditions, retention, export and deletion boundaries.
Discuss a defined CEA research or validation problem.
Share high-level information about the research question, project or document class, available data, proposed comparator, responsible reviewers and publication constraints. Confidential project, supplier or operating data should not be submitted through the public website.
Research programme version 1.0 · last reviewed August 2026