Sources
We select the permitted sources and access: relevant documents, channels and conversations.
Products Cronberry
Information and coordination Development & demonstrations
From scattered information, working context.
Cronberry brings together authorised sources, conversations and relationships in a research and coordination space. Semantic search and agents help the team find what matters and prepare the next step.
Cronberry
From information to work done.
Context
We organise the information by topics, relationships and projects, with the possibility of returning to the source.
Coordonare
We prepare summaries and actions for review, connected to the team’s workflow.
Where it becomes useful.
Research and thematic radar
Tracking topics of interest and retrieving relevant information.
Relationships and opportunities
The context of authorised interactions, in a place accessible to the team.
Connection with FlowMind
We explore the bridge between textual information, tracked topics and geospatial context.
We present the direction and developed functions. Implementation, connected sources and availability are determined during a demonstration. Access to data is controlled.
Cronberry in detail
What you can do with this project.
Cronberry is a relationship intelligence engine, not a document search tool. It starts from an archive of Telegram conversations and builds from it a knowledge graph in Neo4j: contacts, companies, groups, channels, opportunities, campaigns, products, places, events and topics — ten types of entities — linked through eight types of relationships, including “knows”, “works on”, “promised” and “objected to”.
Above the graph sit three things that make the difference compared with a CRM: digital twins, meaning profiles generated from a person’s message history, with which you can talk in order to anticipate a reaction; an optimiser that tests two message variants on those profiles before you send anything to a real person; and a Monte Carlo simulator that runs a work plan hundreds of times and returns a distribution of outcomes, not a single figure.
It must be stated clearly what kind of figures it produces: predictions, not measurements. When the engine returns a response probability or a confidence interval, those are simulation outputs. In the code there is the structure that would compare the prediction with what actually happened — `AccuracyStats`, with accuracy rate and confidence calibration — but I found no real measurement series in the repo to fill it. Until there is one, the figures are read as working hypotheses.
Knowledge graph based on real relationships
Neo4j 5, with a fixed ontology of ten types of entities and eight types of edges, plus a mode in which the ontology can be generated by a model for point analyses. Enrichment runs in four passes: PageRank-style influence scores, community detection through label propagation, edge weights from message frequency and “mentioned” edges extracted from `@user` patterns in the message text.
Digital twins with memory on three levels
A profile generated from a contact history, with short-term memory, long-term memory and relationship memory. Three ways to use it: free conversation, negotiation preparation and response prediction.
Testing a message before it is sent
The optimiser rewrites a message towards a stated objective and can compare two variants. The stress test takes the idea further: it runs parameters such as price increase or deadline pressure at multiple intensities and returns the areas where the contact reacts well and those to avoid.
Monte Carlo simulation on a written plan
The plan is entered as text, together with the list of contacts, the number of iterations and the horizon in days. The outputs are a probability of success with a confidence interval, the points where the plan gets stuck and the reason for each blockage. The simulations have checkpoints, so a long run can be resumed.
The person’s rights, implemented as endpoints
The GDPR module is not a policy page: it has full export of a contact’s data (art. 15 and 20), deletion that runs simultaneously in SQLite, in Neo4j, in predictions and in the consent record, with a deletion log (art. 17), rectification (art. 16), consent status and withdrawal, the record of processing activities (art. 30) and an endpoint for explaining a prediction, for the transparency requirement in the European regulation on AI.
Model cost, metered
The model client keeps a cost counter per call and an in-memory cache with expiry at 3600 seconds and a maximum of 512 entries, plus its own requests-per-minute rate limiter towards the provider. The main model is Azure OpenAI, with Groq as a fast fallback option.
Data and operation
What enters the system. What needs to be checked.
- The current corpus is private and personal
- The path in the startup configuration points to a SQLite database with a personal Telegram history. This is suitable for development and completely unsuitable for a service: a client implementation starts with its sources, with the stated purpose and with the processing basis, not with this corpus.
- Two repositories, one deletion
- The data is stored in SQLite (the source) and in Neo4j (the graph), while predictions are in a third place. Deletion on request touches all three, plus the consent record, and writes a log — because a deletion that leaves the copy in the graph is not a deletion.
- What protects the service at the entrance
- Token bucket request limiting: 100 requests per 60 seconds per IP address, globally, plus tighter limits on expensive endpoints. Strict security headers, with a content policy that blocks scripts and frames, HSTS for one year with subdomains and a permissions policy that closes the camera, microphone, location and payments. Allowed origins are configured through an environment variable.
- What is missing at the entrance, and it matters
- Authentication. In its own security plan, the authentication and authorisation chapter is entirely unchecked: no token validation on the engine endpoints, no roles, no API keys stored as hashes, no lockout after repeated attempts. Until this is fixed, the engine runs behind a controlled network, not on the internet.
From exploration to implementation
How we prepare a project with Cronberry.
First the source and legal basis, then the code
The first step is not technical: what data the organisation has the right to process, for what purpose and for how long. The development corpus is not reused.
We build the graph on the client’s data
Import into Neo4j, then the four enrichment passes. The fixed ontology covers the Telegram CRM pattern; for another type of material, a specific one can be generated.
We close the gate before any exposure
Authentication, roles and stored hash keys are a launch condition, not a later improvement. Rate limiting and security headers are already in place and remain active.
We calibrate predictions against real results
The accuracy measurement structure exists in the code. A useful pilot means recording what the engine predicted and what happened, until the figures have a history behind them.
Questions worth clarifying.
Can I go to cronberry.ai to see it?
No, and this is not a temporary server issue. The domain does not resolve at all: the DNS query returns NXDOMAIN, and the .ai registry responds with `Domain not found` — checked on 6 September 2026. The server indicated in the project documentation, `74.248.16.185`, also does not respond on the engine port. What exists and can be shown is the code, which runs locally, and a demonstration prepared on an agreed dataset.
The site describes it as a workspace for documents and semantic search. Is that so?
No, and that is an error we are correcting. The project is not a search engine over documents. It is a relationship intelligence engine, built from an archive of conversations: Neo4j graph, contact profiles generated from history, message testing on those profiles and Monte Carlo simulation on a plan. The text on the site describes a product different from the code that exists.
What does "response probability 0.67" mean?
It means a simulation output, not a measurement. The engine runs the plan hundreds of times on profiles generated from history and reports the distribution. The code contains the structure that would compare prediction with reality — accuracy rate and confidence calibration — but we did not find any measurement series to fill it. So the figure is used to rank options against one another, not as a promise of result.
Can it run on our clients’ data, not on a personal archive?
Yes, but that is the first step of any implementation, not a final-stage adaptation. The current development corpus is a personal Telegram archive, indicated directly in the start configuration, and it is not reused. The import starts from the organisation’s sources, with purpose and legal basis for processing established beforehand.
What happens when a person requests deletion of the data?
There is a dedicated endpoint, and the deletion is not partial: it affects SQLite, Neo4j, the predictions generated about that person and the consent record, and writes a deletion log. Full export, rectification, consent status, processing record and explanation of a prediction are also implemented.
Is it ready to be exposed on the internet?
No, and the reason is precise: authentication. The authentication and authorisation chapter in your own security plan is entirely unticked — there is no token validation on the engine endpoints, roles, API keys stored as hashes, or locking after repeated attempts. What already exists: limiting to 100 requests per 60 seconds per IP, tighter limits on the costly endpoints, strict security headers and configurable origins. With the front gate shut, the discussion about launch becomes real.
The internal documentation ticks many things as done. Can it be verified?
Partially, and it is worth saying. The security list points to files that do not exist in the repo (`swarm_api.py`, `security_middleware.py`, `gdpr_routes.py`). The corresponding code does exist, though, just elsewhere: `cronberry_swarm/security/rate_limiter.py`, `headers.py` and `gdpr.py`. So the ticks describe real functionality, but the references are wrong — I traced them in the code, not in the list.
Illustrative example
A work plan run through simulation before it is started
A use case, without client data or attributed commercial results.
Initial situation
A team writes a plan in text — whom it contacts, in what order, through which channel — and chooses the contact list, the number of iterations and the horizon in days.
How it works
The engine runs the plan hundreds of times over the profiles generated from each contact's history, on the Telegram platform model. The run has a checkpoint, so it can be resumed if it is interrupted.
Rezultatul
A success probability with a confidence interval, the list of steps where the plan gets stuck and the reason for each blockage, plus the suggested order of contacts. These are all simulation outputs, to be used to compare variants with one another.
What is required:The organisation's own data source, with a defined purpose and basis for processing; Neo4j started and the graph imported; model key configured. There is no public instance today on which to run this.
Collaboration possibilities
Cronberry, in the context of your organisation.
Internal flows and information
Connecting authorised sources, organising information and reviewing actions by the team, with separate access by role.
Private companies
We define a pilot around a real process: users, data, integrations, costs and acceptance criteria. Expansion follows after evaluating the result.
State institutions and companies
We establish the requirements for accessibility, hosting, data protection and interoperability. Any connection to AGE or STISC services requires validation of eligibility, access and approvals.
These are adaptation scenarios, not statements about existing contracts or partnerships. The proposed functions are confirmed within the project scope.
Discuss a pilotPart of an ecosystem.
Geospatial intelligence
FlowMind
FlowMind organises maps, public sources and Copernicus products into a single analysis workspace.
Specialised deploymentAPI for AI models
LongDay
API access to AI models through one common interface.
PlatformWork organisation
Taskin
Taskin explores turning discussions and project context into commitments, priorities and next steps.
Development & demonstrationsWhat would you want to work better?
Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.