Gekta is the evidence layer of deal execution
Gekta understands the permitted deal state, links events to documents and official grounds, explains risk, and prepares the next allowed action. A person remains in control.
One contour — different conclusions for each role
Gekta receives role and organisation context from the server. A participant sees only conclusions within authorised scope.
- Deal card
- Acceptance act
- Document registry
A document is checked as a ground, not just an attachment
The contour reconciles type, version, details, signatures, Deal linkage, and freshness. Unknown data never becomes a positive result.
Completeness
Whether the current stage has every mandatory document
1 document needs confirmationDetails
Whether lot, weight, parties, and dates match
Reconciliation preparedSignature and version
Which version is valid and who confirmed it
Automatic signing prohibitedProtection
Malware checks, isolation, provenance, and prompt-injection defence
Unknown files enter quarantineThe deal is reconciled with official grounds
The platform connects product origin, fields, seeds, inputs, phytosanitary documents, laboratories, and transport grounds in one evidence history.
Source availability depends on the organisation’s official connection and current integration status.Risk becomes a deadline, money, and intervention point
Gekta shows the concrete execution impact: what is blocked, how much time remains, and who must act.
Gekta prepares — a person confirms — an adapter executes
The model has no signing or submission authority. Consequential actions follow a separate controlled chain.
- 1Detect the problem
- 2Show cause and ground
- 3Prepare data draft
- 4Check role and organisation
- 5Open preview
- 6Receive user confirmation
- 7Call signing service if required
- 8Submit through official adapter
- 9Store receipt
- 10Update Deal and audit
Idempotency prevents duplicate submission. No repeat occurs without a new authorised command.
Every conclusion resolves to a source and check time
Gekta answers only within available evidence. Missing confirmation is displayed as “not checked”.
DEAL-DEMO-240721Public scenario · 14:32ACT-DEMO-V3Public scenario · 14:28DOC-REG-DEMOReport not confirmed—Not checked: official connection unconfirmedThe public example does not access real organisation data or imitate a live government-system response.
Gekta operates inside platform controls
Identity, role, organisation, allowed tools, and audit are determined server-side before the model is used.
Organisation isolation
Gekta receives no other tenant data and does not accept tenant selection from the client.
Secrets and signing
ESIA passwords, access tokens, and private signing keys are never sent to the model.
Action control
Privileged writes require role, confirmation, idempotency, and audit.
Verifiability
Answers include sources, freshness, limitations, and abstention when evidence is insufficient.
Capability boundaries are explicit
Gekta must not appear more mature than the operational evidence supports.
- Overall status remains NOT_ATTESTED until separate industrial acceptance.
- A disconnected government system is never shown as connected.
- Unavailable or stale data cannot produce a positive confirmation.
- Public Gekta has no workspace access.
- Gekta cannot sign, submit, or release money without a person.
- Screen scraping of government accounts is prohibited.
Connection is built around organisation rights and official interfaces
An organisation connects staff, roles, allowed sources, and adapters. Actual connection status remains server-authoritative.
Workspaces
Role-aware Gekta inside the Deal and authorised processes
Public Gekta
General land, crop, agribusiness and platform knowledge without organisation access
Corporate API
Controlled reads, prepared actions, confirmation, and receipts
Government adapters
Official API, public registry, verified import, or accredited operator only
Production remains in the platform’s own VPS contour. No migration to Netlify or Vercel.