in a single ledger
before release
an incident
of records
01Executive summary
FloraCore is a platform for operations and audit-ready record-keeping by design in protected cultivation. The core of the product is neither the sensor nor the dashboard: it is an append-only ledger, chained with SHA-256 hashes, whose tampering is mathematically detectable — and whose proof can be carried out by third parties, outside the product, without asking us for anything.
Around that ledger orbit the layers operations need: lot-by-lot traceability, quality gates, electronic signature with live re-authentication, zone telemetry, crop management, and an assistant that cites the source of every answer. None of those layers writes to the ledger without passing a human gate.
What sets the product apart
- Proof outside the product. The chaining algorithm is published. Whoever receives a lot recomputes the chain with standard libraries and reaches the same result — or discovers that they do not.
- A legal mandate, not a convenience. The record the platform keeps is the one the rules already require. The sale does not depend on convincing anyone of the value of "traceability".
- Fails closed where it matters. Entitlement and capability fail closed: no report, no release; no readable plan, no history. Observability fails open: a mute sensor never invents a reading.
- Honest omission. Where no reliable source exists, the product declares the absence instead of filling in. A sample is labelled a sample; a template is labelled a template.
- The AI proposes, the human with a role decides. No agent writes to a system of record without attributable human approval.
How to read this document
This is a public document: it describes design invariants and regulatory obligations, not the internal state of any installation. State figures — how many lots, how many movements, how many devices — age between writing and reading, and for that reason do not appear here. What appears is what stays true afterwards: the rule, the legal limit and the method of verification. Demonstration environments run on DEMO lots; nothing in this document describes a real sale of a controlled substance.
02The problem — a record that proves nothing
Protected cultivation and regulated production live under demanding record-keeping regimes. In medicinal Cannabis in Brazil, the authorised grower keeps a Specific Register Book and follows the official cultivation guide. In floriculture and horticulture, the producer of seedlings and propagation material keeps production, plant-protection and sales records for years, with electronic issuance and fixed filing deadlines.
In practice that record-keeping is done in spreadsheets and mutable systems, where a line can be "corrected" without leaving a trace. A ledger in which any line can be rewritten does not prove integrity — it only proves the present state.
The real regulatory risk is not losing the data. It is being unable to demonstrate that it was never altered.
Correctable without a trace
A spreadsheet accepts any retroactive edit. An audit does not ask for the data; it asks you to demonstrate that the data is the same as it was then.
The buyer cannot verify anything
A PDF certificate proves that someone wrote a PDF. Whoever receives the lot has no way of confirming anything without trusting the sender.
Obligations on a clock
Incident reporting within 48 hours, quarterly consolidation, half-yearly filings on fixed dates. Missed deadlines are the most common cost.
The technical officer answers personally
The technical officer signs under their own professional liability. It is they, not the purchasing department, who carry the risk of the record.
03Two environments, one ledger
The platform runs two lines of business with distinct requirements, on the same record-keeping core. The line is a field of the growing unit's registration, constrained in the database — not a condition scattered through the code.
| Dimension | FloraCore Hub AI | FloraCore Regulated |
|---|---|---|
| Audience | Nurseries, floriculture and greenhouse horticulture | Cultivation and production under a controlled sanitary regime |
| Regime | MAPA · ICA · EU | ANVISA + MAPA |
| Core | Operations, zone telemetry, 3D twin, assistant with source citation | Ledger, release gates, incidents, periodic consolidation |
| THC assay | Does not apply | Mandatory per lot before release |
| Genealogy | Seed → seedling → plant → shipment | Seed → seedling → plant → plant material → plant drug |
| Public verification | Lot page by QR, NFC or pasted hash | Lot page + public audit anchor |
| Retention | As per the plan contracted | 7 contractual years |
An architectural caveat we do not hide
The ledger, today, does not know a lot's line of cultivation. The separation between the two regimes lives in the registration and in the process, not in a gate that enforces it inside the record itself. The consequence is visible in the product: a lot's public label returns the applicability of the THC assay as null — neither true nor false — and states in writing that in floriculture, under the MAPA regime, that assay does not apply. Declaring that we do not know costs less than letting the reader assume a pending item where there is none. Closing this requires bringing the lot → line path inside the ledger, and it is an open architectural decision.
04High-level architecture
The premise is inverted: the record is immutable by construction, not by discipline. The ledger is the source of regulatory truth; everything else orbits around it and never writes to it without a human gate. The supporting layers, the market intelligence and the knowledge retrieval are deliberately outside the core — they carry less availability weight and no write privilege.
Invariants enforced, not aspired to
A corollary written into the culture of the project
“200 is not evidence of publication.” A server that returns the home page for any non-existent path answers 200 to everything — including to what does not exist. Real verification is looking at the content, not at the status code. The same rule applies to this document: what is asserted here should be verified, not accepted.
05The chained ledger
Each event of a lot is serialised into a canonical form — the same field order, the same representation of numbers and dates, always — and its hash is computed over that text concatenated with the hash of the previous event of the same lot. The first event chains from a fixed origin value.
The chaining is per lot, with its own sequence and previous hash. This is not an implementation detail: it means that proving one lot does not require publishing every other lot's events. A buyer sees the chain of what they bought, and nothing more.
h(n) = SHA‑256( canonical(event n) ‖ h(n−1) )
Only appending exists. There is no update and no delete operation, neither in the application nor in the database.
Sequence and previous hash belong to the lot. Proving one lot does not require publishing the events of the others.
A root covering the whole set of lots is published outside the database — that is what catches an entire lot being removed.
Live verification
The widget below runs a demonstration chain in your browser. Alter an event and watch the link break — and every link after it.
What the chain detects — and what it does not
| Attack | Detected by | Status |
|---|---|---|
| Editing an event in the middle of the chain | Recomputing the chaining: the next link stops matching | covered |
| Inserting an event in the middle | The lot's sequence and previous hash | covered |
| Deleting the end of a lot's chain | The anchor published with that day's chain head | covered |
| Deleting the whole lot | The daily root covering the set of lots: the published root stops reproducing | covered |
| Writing a false event today, with the correct hash | Nothing, in the chain. The chain proves integrity, not truthfulness. | out of scope |
The last row is the most important one, and the one that most rarely appears in a sales document. A hash chain proves that the record was not altered after it was written. It does not prove that whoever wrote it told the truth. What attacks that second problem is something else: an attributable role, re-authentication at the moment of signing, and the professional liability of the signer.
06Public verification
Proof is only worth something if an outsider can carry it out. Every lot has a public page reachable by three routes — scanning the QR on the label, tapping the NFC tag, or pasting the hash into a search field. The page is read-only, without a session and without enumeration: whoever lacks the identifier does not discover lots by browsing.
Enough to verify
Lot identifier, species and cultivar, stage, lot status, the event chain with date, type and hash, assay status where applicable, and the verdict of the chain verification.
What is not the public's
People's names, exact property coordinates, prices, customers, contacts, and the commercial map of destinations. A field in doubt stays out — the rule precedes any product request.
The inverse question — where did this lot go —, the one a recall asks, exists but requires a session: it is the company's commercial map, not label data. And it answers for the descendants too, because material split and sold by the children left the same lot. Destinations the record does not name appear separately from the identified ones, instead of being added into a single total — hiding that part would be the most expensive way to get this wrong.
Why this matters commercially
A PDF certificate proves that someone wrote a PDF. A lot page the buyer verifies on their own transfers trust from the seller to mathematics — and turns a compliance cost into a sales argument that a competitor with a spreadsheet cannot match.
07Release gates
In the regulated line, releasing plant drug material — sale, transfer, export, manufacture of inputs — requires an approved THC report. A report above 0.3 % puts the lot under CONTAINMENT: no movement passes, except disposal, destruction and sample collection, and the response already carries the obligations with their 48-hour deadline.
Recording is not deciding
Wiring the assays to the gate came before the criterion on purpose: so that the limit, when it arrives from the official text, does not require touching the ledger's critical path under regulatory pressure. A system that marks APPROVED because no criterion is registered is worse than a system that does not evaluate at all — because it looks as though it evaluated.
08Compliance — requirement, origin, control
Every control exists because a rule requires it, and the rule is cited. This table is what an assessor asks for first: not what the system does, but which obligation each function answers to.
| Requirement | Where it comes from | Control in the platform |
|---|---|---|
| Immutable and contemporaneous record-keeping | Annex XVIII Ordinance SVS/MS 344/98 | Append-only ledger, SHA-256 chaining and immutability triggers in the database |
| Tamper detection | ALCOA+ / GxP | Per-lot chain verification + daily public anchor |
| THC assay per lot before release | RDC 1.012 / 1.013 + official cultivation guide | The gate blocks release without a report ≤ 0.3 % |
| Containment, corrective action and disposal | idem | Lot under CONTAINMENT; only containment movements pass; exceptional release exclusive to the technical officer |
| Reporting to the authority within 48 h | idem | A 48 h clock per incident type; a failed report opens the incident by itself |
| Periodic consolidation of production and stock | idem | Consolidation by category, material and unit, with a deadline |
| Lot-by-lot traceability | item 7.3 of the guide | Chained genealogy, cycle-free, correctable by annulment — the wrong link stays visible to the audit |
| Attributable and signed record | Part 11 style | Role + live re-authentication at the act + immutable manifest with the hash of the signed content |
| Five-year record retention | MAPA NI 24/2005 item 5.2 XII | Contractual retention of 7 years, as a commitment and not as a setting |
| Electronic issuance and QR identification | Joint MAPA/SDA NI 02/2018 arts. 6 and 9 | Public lot page by QR, NFC or pasted hash |
| Record of plant-protection application | MAPA NI 33/2016 art. 24 X | Dose, date and pre-harvest interval recorded in the event |
| Plant passport | Reg. (EU) 2016/2031 | In preparation — the label format and the field mapping are not implemented yet |
A note on regulatory honesty
The catalogue of incident types contains the items verified against the available sources and is extensible by design; the declared intention is to complete it item by item against the full official text, without a refactor. And there are requirements today catalogued as blocking that do not yet block anything. The system publishes that list under exactly that name, with the warning that catalogued is not enforced, rather than displaying a compliance the gate does not impose.
09What the product does not fake
Integrity is not only the chaining; it is a product stance. Where no reliable source exists, the system declares the absence instead of filling in — and the same applies to what the system itself is missing.
State, not last value
A zone with no reading shows "no reading", with the age of the last data point. Repeating the old value as if it were current is the easiest lie a dashboard can tell.
With location and proof
The gaps measured against our own code are published with name and location, and closed by a checker that runs in continuous integration — not by assertion.
Who decides — not engineering
Decisions that depend on the owner, on legal, on accounting or on a laboratory sit in a list of their own, so they are not confused with technical debt.
A DEMO lot is a DEMO lot
What appears as real is real and traceable to its public source; what is a sample comes stamped. A sample is never relabelled as an operation.
The announced algorithm must be the algorithm that runs
A section describing what will change reads, at a glance, as a description of what is — and the hurried reader implements the table of new types. That is why, in this document and in the format documentation, what runs today carries an explicit mark, and what is in preparation carries it in the body of the text and not only in the heading. Publishing a format the product does not use is the same defect as publishing an algorithm different from the one that runs: whoever verifies in good faith reaches a wrong result and concludes that our record is broken.
10Security and privacy
Backups, and what they do not protect against
A local copy protects against volume removal and logical corruption. It does not protect against loss of the server, nor against a compromised credential that deletes the copies with the same hand that writes them. That is why the off-host copy, made immutable by mandatory retention and out of reach of the credential that runs the backup, is a hard prerequisite for production — not a continuous-improvement item. For the same reason, the daily root is published somewhere independent of the system that generates it: an anchor stored only where the data lives is not an anchor.
11Products and plans
Two products on the same core. The first covers nursery and greenhouse operations and record-keeping; the second adds the gates, the incidents with deadlines and the contractual retention the sanitary regime demands.
| Plan | Sites | Devices | Retention | Monthly |
|---|---|---|---|---|
| Free trial without a card | 1 | 3 | 30 days | €0 |
| Grower individual grower | 1 | 25 | 12 months | €29 |
| Hub Starter | 1 | 60 | 3 years | €49 |
| Hub Growth most chosen | 3 | 200 | 5 years | €149 |
| Hub Scale | 10 | 750 | unlimited | €299 |
| Regulated sanitary regime | 1 · +€199/site | 300 | 7 contractual years | €399 |
Prices in euros, excluding VAT, as of September 2026; in Brazil and Colombia billing is in local currency. The annual plan equals ten monthly payments. AI credits count per act — alert or text answer, image analysis, reasoning run — and a failed generation is never charged. The prices in force are those on the website; these are reproduced here for reading, not for contractual citation.
12Roadmap and contact
Proof outside the product
Daily root published with two independent providers, with cross-checking between destinations; canonical event format versioned and with frozen test vectors; public lot page in production.
Criteria and plant passport
Dictionary of acceptance limits taken from official text; lot → line path inside the ledger; EU plant passport with label format and field mapping.
Hardening
One secret per system; an operations manual covering start-up, migration, disaster recovery, rotation and incident; immutable off-host backup as an entry prerequisite.
Qualified signature
Qualified signature with a recognised certificate, and expansion of the market monitor over public commercial data, within the legal scope written into the code.
Contact
- Sales and partnerships — through the form at floracore.plimlab.ch
- Verifying a lot — scan the QR on the label, tap the NFC tag, or paste the hash into the public lot page
- Security — report integrity or verification failures through the same channel, with the lot identifier and the hash observed
Regulatory basis cited in this document: RDC 1.012 and 1.013 and the official Cannabis cultivation guide (ANVISA/MAPA); Annex XVIII of Ordinance SVS/MS 344/98; MAPA Normative Instruction 24/2005; Joint MAPA/SDA Normative Instruction 02/2018; MAPA Normative Instruction 33/2016; Regulation (EU) 2016/2031. The citations identify the obligation; the interpretation applicable to each operation belongs to your technical officer and your legal counsel.