Surse
We select the sources and the access permitted: documents, channels and the relevant conversations.
Produse Cronberry
Informație și coordonare Dezvoltare & demonstrații
From scattered information, a working context.
Cronberry brings authorised sources, conversations and relationships together into one space for research and coordination. 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 topic, by relationship and by project, with the option of going back to the source.
Coordonare
We prepare summaries and actions for review, connected to the team's workflow.
Where it earns its place.
Research and a topic radar
Tracking the topics of interest and retrieving the information that is relevant.
Relationships and opportunities
The context of authorised interactions, in one place the team can reach.
The link with FlowMind
We are exploring the bridge between textual information, the topics being tracked, and geospatial context.
We present the direction and the functions built so far. The deployment, the connected sources and availability are settled within 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 a knowledge graph out of it in Neo4j: contacts, companies, groups, channels, opportunities, campaigns, products, places, events and topics — ten entity types — linked by eight relationship types, among them "knows", "works on", "promised" and "objected to".
Three things sit on top of the graph and set it apart from a CRM: digital twins, meaning profiles generated from a person's message history, which you can talk to in order to anticipate a reaction; an optimiser that tests two variants of a message against 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 rather than a single figure.
It has to be said plainly what kind of figures it produces: predictions, not measurements. When the engine returns a response probability or a confidence interval, those are outputs of the simulation. The code holds the structure that would compare the prediction against what actually happened — `AccuracyStats`, with an accuracy rate and confidence calibration — but we found no series of real measurements in the repository to fill it. Until there is one, the figures read as working hypotheses.
A knowledge graph built on real relationships
Neo4j 5, with a fixed ontology of ten entity types and eight edge types, plus a mode in which the ontology can be generated by a model for one-off 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 the `@utilizator` mention patterns in the text of the messages.
Digital twins with memory on three levels
A profile generated from a contact's history, with short-term memory, long-term memory and relationship memory. Three ways of using it: open 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 a price increase or deadline pressure at several intensities and returns the zones in which the contact reacts well, and the ones to avoid.
Monte Carlo simulation over a written plan
The plan goes in as text, together with the contact list, the number of iterations and the horizon in days. Out come a probability of success with a confidence interval, the points at which the plan gets stuck, and the reason for each blockage. Simulations are checkpointed, so a long run can be resumed.
A person's rights, implemented as endpoints
The GDPR module is not a policy page: it has full export of a contact's data (Articles 15 and 20), erasure that reaches SQLite, Neo4j, the predictions and the consent record all at once, with an erasure log (Article 17), rectification (Article 16), consent status and withdrawal, the record of processing activities (Article 30), and an endpoint that explains a prediction, for the transparency requirement in the European regulation on artificial intelligence (the AI Act).
The model's cost, metered
The model client keeps a per-call cost counter and an in-memory cache expiring at 3600 seconds and holding at most 512 entries, plus a rate limiter of its own for requests per minute to the provider. The main model is Azure OpenAI, with Groq as the fast fallback.
Data and operation
What goes into the system. What has to be checked.
- The present corpus is private and personal
- The path in the startup configuration points at a SQLite database holding a personal Telegram history. That is fine for development and completely unfit for a service: a deployment at a client starts from the client's own sources, with the stated purpose and the legal basis for processing, not from this corpus.
- Two stores, one erasure
- The data sits in SQLite (the source) and in Neo4j (the graph), and the predictions in a third place. Erasure on request touches all three plus the consent record and writes a log — because an erasure that leaves the copy in the graph is not an erasure.
- What protects the service at the door
- Rate limiting with a token bucket: 100 requests per 60 seconds per IP address, globally, plus tighter limits on the expensive endpoints. Strict security headers, with a content policy that blocks scripts and frames, HSTS for a year with subdomains, and a permissions policy that shuts off the camera, the microphone, location and payments. The allowed origins are set through an environment variable.
- What is missing at the door, and matters
- Authentication. In our own security plan, the authentication and authorisation chapter is entirely unticked: no token validation on the engine's endpoints, no roles, no API keys stored as hashes, no lockout after repeated attempts. Until that is resolved, the engine runs behind a controlled network, not on the open internet.
From exploration to deployment
How we prepare a project with Cronberry.
The source and the legal basis first, the code after
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 CRM-over-Telegram pattern; for a different kind of material, a specific one can be generated.
We shut the door before any exposure
Authentication, roles and keys stored as hashes are a launch condition, not a later improvement. Rate limiting and the security headers already exist and stay switched on.
We calibrate the predictions against real outcomes
The structure for measuring accuracy exists in the code. A useful pilot means recording what the engine predicted and what then happened, until the figures have a history behind them.
Questions worth settling.
Can I go to cronberry.ai and see it?
No, and this is not a temporary server problem. The domain does not resolve at all: the DNS query returns NXDOMAIN, and the .ai registry answers `Domain not found` — checked on 6 September 2026. The server named in the project documentation, `74.248.16.185`, does not answer on the engine's port either. What does exist and can be shown: the code, running locally, and a demonstration prepared on an agreed data set.
The site describes it as a workspace for documents and semantic search. Is that right?
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 out of an archive of conversations: a Neo4j graph, contact profiles generated from history, message testing against those profiles, and Monte Carlo simulation over a plan. The text on the site describes a different product 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 against profiles generated from history and reports the distribution. The code holds the structure that would compare the prediction against reality — accuracy rate and confidence calibration — but we found no series of measurements to fill it. So the figure is there to rank options against one another, not as a promise of results.
Can it run on our own clients' data, instead of a personal archive?
Yes, but that is the first step of any deployment, not an adjustment at the end. The present development corpus is a personal Telegram archive, pointed at directly in the startup configuration, and it is not reused. The import starts from the organisation's own sources, with the purpose and the legal basis for processing settled beforehand.
What happens when a person asks for their data to be erased?
There is a dedicated endpoint, and the erasure is not partial: it touches SQLite, Neo4j, the predictions generated about that person and the consent record, and it writes an erasure log. Full export, rectification, consent status, the record of processing and the explanation of a prediction are implemented as well.
Is it ready to be put on the internet?
No, and the reason is precise: authentication. The authentication and authorisation chapter of our own security plan is entirely unticked — there is no token validation on the engine's endpoints, no roles, no API keys stored as hashes, no lockout after repeated attempts. What already exists: a limit of 100 requests per 60 seconds per IP, tighter limits on the costly endpoints, strict security headers and configurable origins. With the front door shut, the conversation about launching becomes a real one.
The internal documentation ticks a lot of things off as done. Can that be checked?
In part, and it deserves saying. The security list points at files that do not exist in the repository (`swarm_api.py`, `security_middleware.py`, `gdpr_routes.py`). The corresponding code does exist, only elsewhere: `cronberry_swarm/security/rate_limiter.py`, `headers.py` and `gdpr.py`. So the ticks describe real functionality, but the references are wrong — we followed them through the code, not through the list.
Illustrative example
A work plan put through simulation before it is started
A usage scenario, with no client data and no commercial results attributed.
The starting situation
A team writes a plan in text — who to contact, in what order, on which channel — and picks 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 is checkpointed, so it can be resumed if it is interrupted.
Rezultatul
A probability of success with a confidence interval, the list of steps at which the plan gets stuck and the reason for each blockage, plus a suggested order for the contacts. All of them are simulation outputs, to be used for comparing variants against one another.
Ce este necesar:Sursă de date proprie a organizației, cu scop și temei de prelucrare stabilite; Neo4j pornit și graful importat; cheie de model configurată. Nu există azi o instanță publică pe care să rulezi asta.
Ways of working together
Cronberry, in the context of your organisation.
Internal flows and information
Connecting the authorised sources, organising the information and having the team review the actions, with access separated by role.
Private companies
We define a pilot around one real process: users, data, integrations, costs and acceptance criteria. Expansion follows once the result has been assessed.
Public institutions and state-owned companies
We establish the requirements for accessibility, hosting, data protection and interoperability. Any connection to services run by Moldova's e-Governance Agency (AGE) or its state information-technology service (STISC) requires eligibility, access and approvals to be validated.
These are adaptation scenarios, not statements about existing contracts or partnerships. The proposed capabilities are confirmed within the project's scope of work.
Discută un pilotPart of an ecosystem.
Inteligență geospațială
FlowMind
FlowMind organizează hărți, surse publice și produse Copernicus într-un spațiu de analiză.
Implementare specializatăAPI pentru modele AI
LongDay
Acces API la modele AI printr-o interfață comună.
PlatformăOrganizarea muncii
Taskin
Taskin explorează transformarea discuțiilor și a contextului de proiect în angajamente, priorități și pași de lucru.
Dezvoltare & demonstrațiiWhat 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.