Key European Cybersecurity Events — January to March 2026

The first quarter of 2026 marked an intense period of engagement for our teams across Europe. Our people participated as speakers, presenters, and technical contributors in four major cybersecurity events — spanning Greece, Italy, and Romania — all tied to EU-funded projects in which we are active consortium partners. Here is a summary of what took place and how we contributed.

1. CYBERGUARD — 1st General Assembly Meeting

29 January 2026  |  Thessaloniki, Greece  |  International Hellenic University (IHU)

The CYBERGUARD Consortium launched its First General Assembly Meeting at Thessaloniki City Hall, hosted by the International Hellenic University (IHU). The event brought together over 40 participants and marked the first major project milestone since implementation began on 1 December 2024.

CYBERGUARD aims to strengthen Security Operations Centres (SOCs) through AI-driven technologies and an efficient Cyber Threat Intelligence (CTI) sharing framework, improving the resilience of SOCs against complex and evolving attack vectors. The meeting covered project objectives and guidelines, management progress, AI-driven cybersecurity system design, CTI and offensive strategies, threat detection achievements, and technical partner demonstrations. Partners also reviewed Pilot Use Cases in terms of usability, performance, and operational relevance.

Dr. Mihai PĂUN (I-ENERGYLINK), consortium coordinator, opened the meeting. Mrs. Malgorzata Agata KOWALSKA (ECCC Project Officer) joined remotely to address the consortium. The project is funded under the Digital Europe Programme and brings together 13 partners from Cyprus, Greece, Spain, and Romania.

Our contribution

DVLOPER was represented by Tudor Chihaia, Mihai Chihaia, and Răzvan Georgescu. The team delivered a live demonstration of the CYBERGUARD Dashboard to consortium partners, showcasing its current state and capabilities. They also conducted a technical demonstration of Suricata intrusion detection rules, explaining their structure and operational logic within the CYBERGUARD architecture.

2. INTERSOC — 2nd General Assembly Meeting

10 February 2026  |  Terni, Italy  |  Hosted by ASM TERNI

The INTERSOC (INTERconnected Security Operation Centres) project held its 2nd General Assembly in Terni, Italy. The project focuses on disruption preparedness and resilience of digital infrastructures through advanced threat forecasting, cyber-incident detection and response, and the development of a user-centric intelligent threat defence platform.

The agenda included work package progress updates, Final Review Planning, a visit to the ASM TERNI pilot site, and a dedicated workshop — "Overall INTERSOC Architecture, Main Solutions and Demos" — covering the technology stack, integration interfaces, dashboard, and SOC-targeted system architecture. A workshop on Pilot Testing and Evaluation also took place.

INTERSOC is coordinated by EXIMPROD ENGINEERING (RO), funded by the ECCC under the Cybersecurity and Trust Programme (Grant No. 101145853), and gathers 13 partners from Spain, Italy, Greece, Cyprus, and Romania.

Our contribution

DVLOPER was represented by Louis Sardarescu and Adrian Batanu. Louis presented the latest Dashboard updates to the consortium, walking partners through the current development status and upcoming features. Adrian participated in the technical working discussions around the SOC Connector, contributing alongside the other technical partners in the consortium to define integration approaches and next steps.

3. SECUR-EU — 2nd General Assembly Meeting

12 February 2026  |  Terni, Italy  |  Hosted by ASM TERNI

Two days later, also in Terni, the SECUR-EU Consortium held its 2nd General Assembly. The project — "Enhancing Security of European SMEs in Response to Cybersecurity Threats" — focuses on open-source security solutions for SMEs, white-hack testing via the HackOlympics initiative, and improving cybersecurity preparedness across the SME market.

The agenda covered work package progress, Final Review Planning, an architecture and demos workshop, and an open debate on SME training activities and stakeholder involvement — addressing capacity-building strategies and how to maximise the project's reach and sustainability. A Pilot Testing and Evaluation session was also held.

SECUR-EU is coordinated by EXIMPROD ENGINEERING (RO), funded under the ECCC Cybersecurity and Trust Programme (Grant No. 101128029), and gathers 14 consortium partners and 2 supporting organisations from across Europe.

Our contribution

DVLOPER was represented by Carol Bazga and Adrian Batanu, both actively engaged in the pilot use case discussions. Carol also delivered a dedicated presentation on the status of DVLOPER's pilot — the Distributed IDS System Deployed on the Edge for IoT Cyber Attack Detection — covering current implementation progress, technical findings, and next steps within the SECUR-EU validation framework.

4. CRA EUROPE 2026 — Cyber Resilience in Action

4 March 2026  |  Romanian Parliament, Bucharest  |  CYBERFORT Consortium, coordinated by I-ENERGYLINK

The flagship event of the quarter was the CRA EUROPE 2026 conference, held at the Romanian Parliament in the Hall Nicolae IORGA. The event was organised by the CYBERFORT Consortium and coordinated by I-ENERGYLINK, with the support of the Romanian National Cyber Security Directorate (DNSC). It drew over 200 participants and 35 speakers and moderators from across Europe.

The event focused on the practical implementation of the Cyber Resilience Act (CRA) and its implications for SMEs, public authorities, and critical sectors. Three thematic sessions addressed CRA compliance frameworks, the role of standardisation, European policy perspectives, CYBERFORT project outcomes, pilot use case showcases, and the path from compliance to capability. Key representatives from ENISA, DNSC, ELECTRICA, ASRO, Deloitte, and the Authority for the Digitalization of Romania (ADR) were among the contributors.

Dr. Mihai PĂUN (I-ENERGYLINK, CYBERFORT Coordinator) opened the conference, framing the event as a transition point: "CRA EUROPE 2026 is moving from Policy to Practice, from Compliance to Capability, and from Ambition to measurable Cyber Resilience."

Our contribution

Mihai Chihaia, CIO of DVLOPER, participated as a speaker in Session 2 — "Cybersecurity Projects, CRA Compliance & European Policy Perspectives" — as the Manufacturer/Vendor voice on the panel. His intervention addressed three interconnected themes:

• The standards gap as the primary compliance blocker — with Type C product-specific standards still pending publication and SBOM format not yet mandated, manufacturers face the risk of building compliance processes that require rework once final standards are issued.
• The underestimated complexity of SBOM — arguing that an SBOM is not a document but a living, automated process embedded in CI/CD pipelines, particularly challenging for products built on deep open-source dependency stacks (such as DVLOPER's MultiCloud platform, which integrates 30+ OSS tools).
• SME resource asymmetry as the harmonisation gap — large enterprises can absorb compliance costs, while SMEs building digital products cannot staff dedicated compliance teams. EU-funded projects like CYBERFORT and CYBERGUARD are essential complements to regulation.

In a solo intervention later in the session, Mihai also addressed how CRA compliance can become a competitive advantage — positioning it as a market access strategy rather than a cost centre, drawing on DVLOPER's experience serving US-based enterprise clients through Broadcom's partner network.

What Q1 2026 Meant for Us

Across four events in three countries, our teams contributed technically, strategically, and publicly to some of the most important conversations in European cybersecurity today. From SOC architecture and intrusion detection to CRA compliance and SME readiness, Q1 2026 has reinforced our position as an active and relevant voice in the ecosystem. We look forward to continuing this engagement in the months ahead.

In most enterprise deployments, the model is not the limiting factor. The failure appears at the system level, once the AI is exposed to real operational conditions.

In a controlled demo, inputs are predictable, context is bounded, and retrieval pipelines operate on clean, well-structured data. Latency is stable, and responses are evaluated in isolation. Under these conditions, the system performs as expected.

Production introduces a different set of constraints.

Queries are less structured and often underspecified. Input data is distributed across systems with inconsistent schemas and varying levels of reliability. Retrieval pipelines must handle partial failures, timeouts, and conflicting signals. Context windows become a constraint as the system attempts to combine multiple sources into a coherent response.

These are not edge cases. They are the baseline conditions of real usage.

The architecture decisions made during development become visible at this stage. How the system prioritizes sources when signals conflict. How it maintains state across multi-step workflows. How it degrades when a dependency is unavailable. How it handles concurrent requests without compounding latency or reducing accuracy.

Most implementations are not designed for this level of complexity. They are optimized for single-step interactions, not for sustained, multi-step reasoning under load.

The result is predictable. Accuracy degrades as query complexity increases. Latency becomes inconsistent. Failure modes are unclear or poorly handled. Trust declines, and usage shifts toward low-risk scenarios.

The model has not changed. The environment has.

The difference between a working prototype and a reliable system is the architecture that accounts for these conditions — before they surface in production.

Schedule an AI System Diagnostic

Or, if you want to understand how this is built in practice: See how the AI Factory works → https://dvloper.io/ai-factory

How we at dvloper.io build enterprise agentic AI that actually ships, and why the model isn't where your agent lives or dies.

Every enterprise AI program starts with the same enthusiasm and ends with the same question: “Why does the demo look so sharp and the production pilot look like a toddler with a search engine?”

We see this constantly. A team picks a model, wires it to a handful of tools, builds a nice chat UI, and ships something that crushes the happy-path scenarios the product owner demoed. Then it meets real enterprise data, real business rules, real ambiguity, and it collapses. Outputs drift. Trust erodes. The project quietly gets re-labeled as “exploratory” and everyone pretends the roadmap always had that caveat.

The thing nobody wants to say out loud is this: the LLM is not where your agent lives or dies. The model is a commodity. GPT, Claude, Gemini, Llama. Swap them, benchmark them, argue about them on Twitter. None of it will save an agentic system that doesn't understand your enterprise.

The layer that actually determines whether your agent survives contact with production is the one underneath the model. The one that tells it what your enterprise actually means.

That layer is an ontology. And building it properly is what we do at dvloper.io.

What a production-grade enterprise agent actually requires

When we talk about agentic AI at dvloper.io, we mean something very specific: a system that encodes the data, logic, actions, and security of the enterprise into a coherent semantic model, and then lets humans and agents operate on top of it with full fidelity. We call the capability we build for our clients the AI Agentic Factory, and it rests on four things, not one.

Strip away the buzzwords, and an enterprise-grade agent has to do four jobs simultaneously:

• Encode the data of the enterprise. Unify the vast and fragmented sources of truth: CRM, ERP, systems of record, ticketing platforms, document stores, operational telemetry, into coherent objects, properties, and links. Not a dashboard. Not an API gateway. A single semantic model the agent can actually reason over.
• Capture the logic of the enterprise. The rules, constraints, and decision frameworks currently living in someone's head, in a PDF from 2022, or worse, buried in fifteen different stored procedures nobody has touched since the person who wrote them left. Encoded once. Consistent everywhere.
• Model the actions of the enterprise as first-class primitives. Not just “the agent can generate an answer,” but “the agent can write back to the system of record, with the right approvals, the right audit trail, and the right rollback path.” Simple transactions and multi-step workflows, both governed the same way.
• Govern both humans and agents under one security model. Same identity, same permissions, same audit logs, whether the actor is a senior analyst or an autonomous agent. No CISO is going to sign off on “the LLM decided what was allowed.”

None of that is LLM work. All of it is semantic-layer work. And it is exactly what most agentic AI programs skip in the rush to ship a demo, which is exactly why most agentic AI programs stall between demo and production.

Why agents fail without a semantic layer

Let's be specific about what actually breaks when you skip the ontology.

1. The same term means five different things. A “customer” in CRM is not the same as a “customer” in billing, is not the same as a “customer” in the churn model, is not the same as the entity your contract says you owe money to. Your agent sees all five and averages them.

2. Business rules live in humans, not systems. The rule that “we never onboard vendors from jurisdiction X without a Tier-2 compliance review” exists in someone's head and in a PDF from 2022. Your agent has no idea.

3. The agent can't tell when it doesn't know. This is the failure mode that destroys enterprise trust faster than any other. An agent that confidently answers with incomplete information is worse than no agent at all, because you stop checking it.

4. Nothing is explainable. When the agent produces a decision, nobody can reconstruct why. No auditor will sign off on that. No compliance team will let it run unsupervised. No regulator will let it touch a regulated workflow.

5. Every new use case is a from-scratch rebuild. Without a shared semantic backbone, each agent is its own snowflake. Pilots never become platforms. Year two looks exactly like year one except with more sunk cost.

These are not model problems. No amount of swapping from GPT-4 to Claude to Gemini to Llama will fix them. They are architectural problems, and the architecture is the ontology.

How we actually build these systems

Here is the pattern we use at dvloper.io, and what makes the Agentic Factory approach different from “hook an LLM to LangChain and hope.”

1. Ontology-first, model-second

Before we pick the LLM, we model the domain. What are the entities? What are the relationships? What are the rules, constraints, and required properties? What does “done” look like for each workflow? What does every actor (human or agent) needs to know to make a safe decision?

This is boring, unglamorous, diagram-heavy work. It is also exactly what separates the systems that ship from the ones that don't.

2. The agent's job is semantic translation, not answer generation

Once the ontology exists, the LLM's job gets narrower than people expect. It is not “generate the answer.” It is: take the user's request, map it to ontology concepts, identify what is being asked, and route to the right tools.

That is a much more tractable problem for an LLM. It is also much easier to make reliable, testable, and debuggable. Most of what people call “hallucination” in production agents is actually the LLM being asked to do a job the architecture should have handled for it.

3. Tools are first-class citizens, and they are boring on purpose

We build tools as small, deterministic, testable pieces of code that the agent composes into workflows. Boring tools are good tools. They fail predictably. They log cleanly. They don't hallucinate.

The tools that show up in every ontology-driven agent we build:

• The Gap Capture tool. Identifies what is missing before the agent acts. If an onboarding request does not have a jurisdiction, the agent does not guess. It records the gap.
• The Question Generation tool. Turns gaps into targeted follow-up questions, grounded in the ontology rather than generic “can you clarify?” prompts. “Is this vendor operating in a restricted jurisdiction?” beats “Tell me more about the vendor” every time.
• The Assumption Logging tool. When a workflow has to proceed with a temporary assumption, the agent records it explicitly. Every decision becomes auditable. Every assumption becomes a conversation the team can later have.
• The Validation tool. Checks that requests and resolved entities satisfy ontology constraints before any action is taken. Every contract must be linked to a legal entity. Every change request must have a rollback path. Every product must have a capability owner. The ontology says so; the validator enforces it.
• The Reasoning tool. Applies rules over ontology relationships to derive facts the input didn't explicitly contain: eligibility, risk tier, dependency chains, blast radius. This is where ontology stops being a dictionary and starts being an inference engine.
• The Escalation tool. When the agent can't safely complete a task, it routes to a human with full context (gaps, assumptions, partial work, recommended next actions), not a generic ticket with “agent failed, please investigate.”

These are the tools that make the difference between an agent that answers fast and an agent you would actually put in front of a regulator.

4. Observability on top, governance on the side

Every agent call, every tool invocation, every assumption, every escalation, all logged, queryable, auditable. This is not bolted on at the end. It is part of the architecture from day one. When an agent makes a decision six months from now, you can reconstruct exactly why.

5. The platform compounds

This is where the “Factory” in Agentic Factory matters. The first agent we build comes with a semantic model, a tool library, and observability plumbing. The second agent reuses all of it. By the third or fourth use case, the incremental cost of a new agent is a fraction of the first one.

That is when agentic AI stops being a project and starts being a capability.

A real example: agent-driven network operations

Some of our most demanding work lives in network operations: proactive monitoring, configuration validation, incident triage. Real-time, high-stakes, zero-tolerance-for-wrong-answers territory. An agent that confidently pushes a bad change into a production network does not produce a bug. It produces an outage with a name.

What does ontology look like here?

• Entities: devices, interfaces, links, policies, tenants, service paths, SLAs, maintenance windows.
• Relationships: which device serves which tenant, which policy applies to which interface, which link is primary versus backup, which tenant shares which blast radius.
• Rules: what constitutes a valid configuration change, what requires tenant approval, what can be auto-remediated, what must never be touched outside a maintenance window.

A traditional agent asked “Can we push this configuration change?” might confidently answer yes based on syntactic validation alone. That is dangerous.

An ontology-driven agent answers a different question entirely: given the ontology of this network, is this change safe, for which tenants, with what downstream effects, and what assumptions is it making?

It might conclude:

Change validation: Blocked.

Gaps detected:

• Affected tenant SLA window not confirmed

• Rollback path for interface bundle not verified

• Peer link redundancy currently degraded

Questions requiring human input:

• Is this change scheduled inside the tenant's approved maintenance window?

• Has the peer-side team acknowledged the redundant-link status?

Assumptions logged:

• Tenant SLA tier inferred from most recent service catalog snapshot

• Rollback path assumed to be the previously-deployed configuration baseline

Recommended next actions:

• Route to on-call network engineer with full context

• Hold change until peer-side redundancy restored

That is not a chatbot. That is a co-worker with enough context to be trustworthy, and enough self-awareness to escalate when it shouldn't proceed alone.

The business case, said plainly

The reason this architecture is worth the upfront work is not theoretical. It shows up in five places:

Trust. The agent shows what it knows, what it doesn't know, and why. Users stop second-guessing outputs, which means they actually start using them.

Explainability. Every decision is grounded in ontology, rules, and traceable gaps. Regulators, auditors, and internal risk teams can follow the reasoning end-to-end.

Reusability. The ontology becomes a shared asset across every agent and workflow you build. Second use case costs a fraction of the first.

Governance. Assumptions, questions, unresolved issues, and escalations are explicitly captured, not hidden inside model weights you cannot inspect.

Scalability. Different domain agents share the same semantic backbone. Your platform grows as a coherent system instead of a collection of disconnected pilots.

These are not theoretical benefits. They are the reason enterprises that adopt this pattern end up with agentic AI running in production, and the ones that don't end up with a graveyard of demos.

The closing thought

LLMs are excellent at generating language. Enterprise decisions require structure, meaning, constraints, and the discipline to recognize when an answer is incomplete. One of those things is a commodity in 2026. The other is the work.

At dvloper.io, the work is what we sell. The ontology-driven agent is not a demo pattern for us. It is how we ship.

If you are stuck somewhere between a promising POC and a production agent you'd actually trust with a regulated workflow, the missing layer is probably not a better model. It is the ontology underneath.

We would be happy to talk about yours.

Want to discuss where your agentic AI program is stuck, or how an ontology-first architecture would fit your stack? Get in touch at dvloper.io.

Razvan Georgescu, VP of Data & AI, dvloper.io

At some point, every team stops being able to remember everything it has already learned. The knowledge is there sitting in ten thousand Jira tickets, buried in comment threads, resolution summaries, and carefully-written post-mortems of incidents from years ago. All of it is searchable, technically. None of it is findable in the way a human actually asks questions.

New team members spend their first weeks asking questions that have been answered a dozen times before. Senior engineers get pulled off their own work to explain history they’ve already explained, which isn’t just a productivity tax it’s one of the quieter reasons people burn out. Incidents drag on longer than they should because nobody can remember whether this exact symptom has happened before, or whether a similar issue in a different service was already root-caused and resolved.

The organization owns the answers. It just can’t access them at the speed of conversation. That gap between “we know this” and “we can retrieve this” is worth closing. That’s the problem JiraAI was built to solve at dvloper.io.

Why we built our own product layer

Before we wrote a line of code, we spent serious time evaluating RagFlow, the open-source RAG engine that has become one of the most capable platforms in its category. It’s genuinely impressive: deep document parsing, intelligent chunking, multi-modal retrieval, grounded citations, agent workflows, and native Jira support since v0.22.0. For many teams, it’s an excellent starting point. Three concerns ruled out a direct deployment for us.

Access control you can prove

Engineering managers and security leads don’t just want “a chatbot over Jira.” They want to prove that a contractor on Project A has no path through the UI, through the API, or by guessing identifiers to data from Project B. RagFlow’s open-source edition is designed around workspaces, not per-user per-knowledge-base grants. The maintainers confirmed this when they closed the RBAC request in May 2025: granular permission control is a commercial-tier feature. For our use case, this wasn’t a limitation we could work around it was the core of what we needed to deliver.

Roadmap autonomy

Building entirely on a third-party platform means your product’s future is tied to their release schedule and licensing decisions. Owning the application layer while leaning on RagFlow as the retrieval engine underneath meant we could ship the features our teams actually asked for, on our timeline, without waiting for an external roadmap to catch up.

Technology vs. product

A RAG engine does one thing extraordinarily well: retrieve. A knowledge product is the onboarding flow that makes a junior engineer feel supported, the audit trail that satisfies a security review, the dashboard that justifies the budget. None of that ships inside a retrieval engine by default. JiraAI is the product. RagFlow is the engine. Keeping those two things separate, and letting each do what it’s best at, is the most important architectural decision we’ve made on this project.

What JiraAI delivers

1. Real RBAC tied to your existing identity

JiraAI integrates directly with Keycloak (or any OIDC-compliant IdP). Access is enforced at three independent levels: site-wide roles (site.admin, project.admin, project.user), per-user knowledge base grants for contractors and cross-functional contributors, and project-to-knowledge-base mappings that make tenancy clean and auditable. One Keycloak change grants access; one change removes it entirely. MFA, session policies, and password rotation are all inherited JiraAI can’t accidentally weaken them. For a security review, this is the difference between a two-week conversation and a two-day one.

2. An admin dashboard for decision-makers

Every early demo ended with leadership asking the same three questions: Is anyone actually using this? Are the answers good? What are we getting for what we’re spending? The /admin view answers all three adoption by team and project trended over time, per-response helpfulness signals captured directly in chat, and LLM usage tied to specific tickets and projects. It’s a product owner’s view of whether the thing is working, not a RAG operator’s view of embedding health and vector metrics.

3. Jira data understood before it’s indexed

Raw Jira tickets are noisy: triage summaries written before the problem was understood, low-signal comments (“bump,” “retry,” “any update?”), attachments in mixed formats, and resolutions buried in the last reply of a long thread. Feed that directly into a knowledge base and you get answers that reflect the noise.

JiraAI’s ingestion pipeline runs every ticket through an AI enrichment step before it reaches the knowledge base restructuring it into what the problem was, what was tried, what was ruled out, and what finally worked. Atlassian Document Format comments are parsed correctly. A single ticket can fan out to multiple knowledge bases without duplicating the enrichment work. The result is cleaner retrieval and more accurate, more specific answers.

4. Project-centric UX and a resilient pipeline

Instead of navigating a list of opaque knowledge base identifiers, users start from a project, intuitive and familiar organizing unit they already work in every day. The assistant, access controls, and analytics all follow automatically. Behind the scenes, a decoupled producer/consumer pipeline handles incremental Jira polling, enrichment, and fan-out independently. If the downstream is temporarily unavailable, the producer keeps collecting and the consumer catches up. Single-ticket failures don’t affect the batch. Idempotency is enforced at the database level. Reliability isn’t a feature you market it’s the absence of the outages you didn’t have.

How a question becomes an answer

An engineer hits a familiar-looking Kafka consumer timeout and types: “Have we seen this lag spike before, and what was the fix?” JiraAI authenticates them via Keycloak, resolves their project memberships, and queries only the knowledge bases they’re allowed to see the access boundary is enforced at the retrieval step, not just at the UI. Enriched ticket chunks are retrieved, re-ranked, and passed to the LLM with a carefully designed system prompt. The answer streams back with citations to specific tickets.

The engineer clicks through to an eleven-month-old ticket and finds the root cause in three minutes. They mark the response helpful that signal feeds the admin dashboard, where a product owner can see which teams are getting value and which knowledge bases have gaps. Nobody thought about knowledge base IDs, RAG configuration, or which model is powering the response. It just worked, and it was safe, and it was measurable.

The lesson

Retrieval engines don’t ship with the parts that make them products. Access control, audit trails, domain-specific data handling, a UX that fits how engineers think about their work none of that comes in the box, regardless of how good the underlying engine is. A thin interface on top of RagFlow would have passed the demo. It would not have passed the security review.

So we built those parts ourselves and layered them on top of RagFlow’s retrieval quality, which we trust and don’t have to maintain. The hard foundational work is someone else’s problem. The product experience the part our teams open every morning is entirely ours to shape and iterate on.

Further reading

–  RAGFlow on GitHub

–  RAGFlow v0.22.0 data sources, admin UI, parser improvements

Dvloper is entering Phase 3 of a strategic AI collaboration with a Fortune 10 infrastructure leader, evolving an enterprise assistant into a more advanced agentic system designed to reason across complex internal knowledge and support real operational workflows in production environments.

Enterprise AI rarely fails during training. It fails in production.

That reality has shaped our collaboration with a Fortune 10 infrastructure leader, where the goal was never to build another impressive assistant, but a system capable of navigating complex internal knowledge and supporting real operational workflows.

After successfully delivering Phase 1 and Phase 2, we are now entering Phase 3 - the biggest stage of the partnership so far.

From Early Validation To Deeper Operational Value

The earlier phases of this collaboration were centered on building the right foundation: understanding the problem space, shaping the assistant architecture, integrating knowledge sources, and validating how AI could be applied in a way that was actually useful inside a real enterprise environment.

That part matters more than people think.

In enterprise settings, AI is not valuable just because it can answer questions. It becomes valuable when it can work within complex systems, reason through fragmented information, and produce outputs that are relevant, reliable, and aligned with how teams actually operate.

That is exactly where this collaboration has been heading.

With the first two phases successfully completed, with great feedback from the stakeholders of going beyond the initial scope - the project is now moving post foundational capability and into a more advanced stage focused on broader reasoning, stronger orchestration, and deeper operational fit.

What Phase 3 Is About

This next stage focuses on expanding the agentic capabilities of the platform so that it can do more than respond, it becomes a proactive agentic framework instead of a reactive agentic mechanism. It needs to reason across enterprise context, coordinate specialized workflows, and support more structured decision paths in environments where accuracy and traceability matter.

At a high level, this phase builds on the progress already made in areas such as:

• Agent orchestration for more structured task handling
• Context aware reasoning across multiple internal knowledge sources
• Improved routing between specialized flows and capabilities
• Stronger support for complex operational investigations
• A more production minded approach to integration, validation, and rollout

The goal is not to build AI for the sake of AI.

The goal is to build a system that can genuinely support teams operating in complex technical environments, where the volume of information is high, the paths to resolution are rarely linear, and trust in the output matters just as much as speed.

Why This Work Matters

A lot of AI content today focuses on generic assistants and surface level automation. But enterprise reality is different.

Real internal systems are layered. Knowledge is distributed. Processes evolve over time. And the people using these tools are not looking for novelty; they are looking for practical value in their day to day workflows.

That is why this collaboration has been shaped around a more grounded engineering approach.

Instead of treating the assistant like a standalone chatbot, the system has been designed as a more structured, agent driven capability: one that can connect to enterprise knowledge, follow defined reasoning paths, and support users in a way that feels closer to an operational companion than a generic interface.

That distinction is important, especially in larger organizations where adoption depends on whether the solution can fit into real workflows, not just perform well in a controlled demo.

In most large organizations, operational teams deal with high volumes of structured and unstructured information coming from multiple systems that were never designed to talk to each other. The people doing the work are experienced - they know how to navigate the complexity - but they spend a disproportionate amount of time on the repetitive cognitive work: gathering context, cross-referencing sources, triaging what matters from what doesn't. That is not an automation problem. It is a reasoning problem. And that is where agentic AI actually starts to make sense - not as a replacement for expertise, but as a layer that handles the heavy lifting before a decision needs to be made.

What Makes This Phase Different

What makes Phase 3 significant is not only the scale of the work, but the level of maturity behind it.

By this point, the collaboration is no longer about testing whether the idea has potential. That has already been demonstrated through the earlier phases. Phase 3 is about extending that success into a larger, more capable system with stronger real world value.

For our team, this is also the kind of work we care deeply about: combining modern AI frameworks with disciplined engineering, thoughtful architecture, and a strong understanding of how enterprise systems actually behave.

It is one thing to prototype an assistant.

It is another to design one that can evolve responsibly inside a large operational environment.

That is the challenge and the opportunity in front of us now.

Looking Ahead

We are excited to begin Phase 3 and continue building on the trust, momentum, and technical foundation established so far.

This next chapter represents more than just another milestone. It reflects the strength of a partnership built through delivery, iteration, and a shared commitment to building AI systems that are useful, reliable, and grounded in real operational needs.

For Dvloper, it is also a strong example of how we approach enterprise AI, not as a trend, but as an engineering discipline.

The companies that will lead with AI are not the ones moving fastest. They are the ones building systems that their teams actually trust.

My time at the dvloper.io academy was a transformative experience designed to bridge the gap between basic programming knowledge and enterprise-level software development. The primary objective of the program was to familiarize students with real-world applications, full-stack development, and professional workflows, all within a structured Agile methodology emphasizing continuous delivery and iterative improvement.

The curriculum followed two-week sprints, with tasks building on each other and increasing in complexity. Agile practices guided the process: sprint planning to set goals, bi-weekly meetings to stay aligned, code reviews for quality, and retrospectives to reflect and improve. Mentorship was a key part of the academy experience. 

The first month at dvloper.io focused on laying a stable foundation for enterprise-level development. I began by setting up Virtual Machines, installing development tools, and configuring all dependencies required to run complex applications. Understanding the infrastructure behind these systems was equally important, I learned how enterprise applications rely on interconnected services and environments to function reliably. Alongside this, I worked on designing application workflows, planning scalable structures, and mapping how different components would interact. This phase was critical for building core technical skills, developing a structured approach to problem-solving, and learning how to manage tasks efficiently through the two-week sprint structure.

With the technical foundation in place, I moved on to backend development and enterprise data workflows. I focused on writing robust backend logic capable of handling complex business processes and designing REST APIs to facilitate smooth communication across application layers. Integrating these backend components into a cohesive system taught me to think in terms of system architecture and data flow management, reinforcing how enterprise applications are designed for scalability, reliability, and maintainability. By the end of this month, I felt confident tackling enterprise-level backend challenges and understood how backend services support the overall functionality of large-scale applications.

The third month emphasized full-stack development and integration. I shifted my focus to building interactive, responsive frontends and connecting them to the backend APIs I had developed. Testing and refining the end-to-end workflows gave me a clear view of how all components of an application come together to create a seamless user experience. This stage reinforced my understanding of full-stack development and highlighted the importance of integration and user-focused design in enterprise applications. By seeing how each part of the system interacts, I gained hands-on experience in managing complexity in a way that mirrors real-world professional environments.

The final month introduced enterprise DevOps practices, ensuring the applications we built could be deployed and maintained reliably. I learned how to package applications with containerization for consistent environments, deploy and manage them at scale using Kubernetes, and automate testing and deployment through CI/CD pipelines. This phase enhanced my skills in automation, deployment, and scalable system management , all essential for enterprise software development. It also demonstrated how modern development workflows rely on collaboration between developers, operations, and continuous delivery systems to maintain reliability in production environments.

Takeaways

The program provided an invaluable start to my career, equipping me with both the technical expertise and professional skills required in real-world software development. I am now confident to approach other challenges, and continuously improve in a professional environment. 

At dvloper.io, we believe that code quality is not just a nice-to-have. It is the foundation of sustainable software development. As our portfolio grew to include complex platforms like JIRA AI, NationalHR, and Backstage.io, we faced a common challenge: how do we maintain consistent code quality standards across diverse teams and technologies?

SonarQube became our answer, a powerful static code analysis platform that has transformed how we approach quality assurance. In this article, I will share our journey of implementing SonarQube across multiple projects and the lessons we have learned along the way.

The Challenge: Scaling Quality in Microservices

Our flagship project, JIRA AI, is a multi-module Spring Boot microservices application comprising several interconnected services: a core REST API backend, Kafka message producers and consumers, shared utility libraries, and a React frontend. Each module has its own complexity, dependencies, and potential for technical debt.

Similarly, our work on NationalHR and our contributions to Backstage.io required a unified approach to quality that could scale with our ambitions. We needed a solution that would provide consistent standards without stifling the unique requirements of each project.

Our Configuration Strategy

The key to our successful SonarQube implementation lies in a multi-layered configuration hierarchy. At the root of each project, we define core properties: unified project identification, quality gate integration that ensures pipeline failures on violations, and secure environment-based token management. This centralized approach guarantees that all modules inherit the same baseline standards.

Each service module then maintains its own configuration for granular control, including targeted source and test directory mapping, Java version alignment per module requirements, intelligent exclusions for generated code and configuration files, and seamless JaCoCo test coverage integration. We maintain a minimum 80% test coverage threshold across all projects, which has significantly reduced our production bug rate.

CI/CD Pipeline Integration

For JIRA AI, NationalHR, and our other projects, we have implemented sophisticated three-stage GitLab CI pipelines covering build, SonarQube analysis, and deployment. Our configuration features intelligent caching for Maven dependencies and SonarQube results, full Git history access for accurate blame information, and branch-specific analysis with different rules for protected versus feature branches.

A crucial design decision was setting our SonarQube analysis to non-blocking mode. Quality issues are surfaced and tracked without preventing deployments, empowering teams to make informed decisions while maintaining delivery velocity.

The Benefits We Have Realized

Automated Quality Gates: Our quality gates prevent technical debt accumulation by catching issues early. Across all projects, we have seen a measurable reduction in production incidents and maintain code duplication below 3%.

Enhanced Security: SonarQube's vulnerability scanning helps us identify and remediate security issues before production. The OWASP compliance features provide actionable guidance for our security-conscious development practices.

Developer Productivity: With IDE integration and real-time feedback during development, our teams catch issues before they even commit code. Pull request analysis provides automated quality feedback, significantly reducing code review burden.

Lessons Learned

Strategic Exclusions Matter: Do not analyze everything. Exclude generated code, configuration files, and model/DTO classes from duplication detection. This focuses your quality metrics on code that actually matters.

Start with Reasonable Thresholds: We began with achievable quality gate thresholds and gradually tightened them as our codebase improved. This prevented team frustration while still driving continuous improvement.

Leverage Caching: Our caching strategy for both Maven dependencies and SonarQube analysis results significantly reduced pipeline execution times, which is essential for maintaining fast feedback loops.

Conclusion

Implementing SonarQube across JIRA AI, NationalHR, Backstage.io, and our other projects at dvloper.io has been transformative. By combining automated analysis, comprehensive coverage reporting, and seamless CI/CD integration, we have established a culture of quality that scales with our growth.

The multi-module configuration approach provides both unified oversight and granular control, which is essential for enterprise-grade applications. If you are looking to elevate your code quality practices, I encourage you to explore SonarQube. The investment in setup pays dividends in reduced bugs, improved security, and happier developers.

Have questions about our SonarQube implementation? Reach out to us at dvloper.io. We are always happy to share our experiences with the developer community.

About the Author: Bilciurescu Gabriel is a software engineer at dvloper.io, where he focuses on building scalable microservices architectures and implementing DevOps best practices.

The ESTEEC Olympics Hackathon has officially concluded, and the results were nothing short of impressive.

While the energy of a hackathon is often about the "game", this event was rooted in a much larger mission. It served as a promotional platform for the Cyberguard project—a major European initiative where our team holds key development responsibilities.

The Cyberguard Connection

Cyberguard (funded by the European Commission’s Digital Europe Programme) is dedicated to "Fortifying SOCs Against Evolving Cyber Threats." Our day-to-day work in this project involves developing advanced AI-driven technologies to protect critical infrastructure—spanning energy, finance, and healthcare—from sophisticated attacks.

We wanted this hackathon to mirror that level of technical rigor. The goal wasn't just to "spread awareness", but to showcase the intense engineering reality of modern cybersecurity. We challenged participants to step into the shoes of the developers building the next generation of Security Operation Centers (SOCs).

The Challenge: AI/ML SIEM for POS Fraud

We tasked the teams with a highly specific, real-world problem: Building a custom SIEM (Security Information and Event Management) system for Point of Sale (POS) fraud detection.

Participants had to ingest a continuous, high-velocity data stream, analyze it for anomalies, and visualize threats in real-time.

Engineering Under Pressure

To simulate the critical nature of the systems we build at Cyberguard, we introduced strict constraints:

• 30-second live checker: Security is time-sensitive. Once an event hit the stream, teams had exactly 30 seconds to detect the fraud and report it. This forced them to prioritize low-latency architecture over sluggish, heavy processing.
• Real Logic vs. Wrappers: We explicitly banned the "lazy" use of LLMs (simply sending data to a prompt). We demanded genuine algorithmic creativity, hybrid models and custom heuristics that demonstrated true engineering expertise.

From data to decisions

On top of the AI models creation, the hackathon teams delivered on this front with robust dashboards that answered critical business questions instantly:

• What are the top 5 active fraud patterns?
• Which age demographics are being targeted right now?
• How does the current alert volume compare to previous hours?

Summary

This event was a successful extension of our work with Cyberguard. By bringing the complexity of critical infrastructure defense to a hackathon format, we didn't just promote the project—we highlighted the vital importance of integrating AI and machine learning into the fabric of our digital security.

Congratulations to the winners, and thank you for helping us demonstrate what it takes to truly guard the grid.

We’re proud to share that several members of our team won the NASA Space Apps Challenge 2025,  the world’s largest global hackathon for innovation using NASA data.

Their project, AiRo, stood out for its bold approach to one of the most pressing issues of our time: air quality management.

What AiRo Does

AiRo automates industrial air quality management by combining NASA TEMPO satellite data with AI-powered infrastructure analysis.

Traditionally, companies rely on manual environmental consulting - a process that can cost over €57,000 per year. AiRo replaces this with automated, real-time monitoring and reporting for about €10,800 annually, helping organizations save around €47,000 per year while improving environmental compliance and community safety.

The Challenge It Solves

According to the World Health Organization, 99% of people worldwide breathe polluted air. Many organizations still operate reactively - responding to pollution exceedances only after they happen.

AiRo changes that. It shifts industrial facilities from reactive compliance to proactive prevention by continuously analyzing air quality, infrastructure context, and risk factors around industrial sites.

When air pollution levels exceed thresholds, AiRo doesn’t just send alerts - it can call managers directly through AI-powered voice notifications to ensure immediate action.

How It Works

1. Infrastructure Analysis – Uses OpenStreetMap and OpenAI Vision to understand the facility’s surroundings: roads, schools, hospitals, and building density.
2. Environmental Data Integration – Combines NASA TEMPO satellite data (NO₂, HCHO, O₃, AQI) with local measurements and weather data.
3. Contextual Risk Assessment – Models how pollutants move and affect surrounding communities.
4. AI Mitigation Planning – Multi-agent AI systems recommend short-, medium-, and long-term actions with cost-benefit analyses.
5. Automated Reporting – Generates both detailed Markdown reports and executive PowerPoint presentations.
6. Proactive Alerts – Delivers dashboard notifications and AI-initiated phone calls when pollution thresholds are exceeded.

The Impact

For organizations, AiRo means: – Lower compliance costs and fewer consultant hours – Prevention of violations, fines, and permit delays – Access to data that supports grant and tax credit applications

For communities, it means: – Cleaner air – Reduced health risks – Transparent, accessible air quality information

AiRo demonstrates how AI, automation, and NASA open data can come together to protect both the environment and the economy.

Built by the Team at dvloper.io

The project reflects our team’s engineering philosophy: solve real problems with clarity and precision.

AiRo’s technical stack includes React, FastAPI, Kubernetes (K3s), Longhorn distributed storage, and Keycloak SSO, running on Hetzner servers for scalability and performance. Its AI agents leverage OpenAI GPT-5, OpenAI Vision, and Retell AI for data analysis, visual interpretation, and natural-language phone alerts — proving that AI can be both intelligent and actionable.

Why This Matters

Winning NASA Space Apps isn’t just about recognition. It’s about validation that deep tech can create measurable environmental and social impact.

AiRo helps industries become cleaner, smarter, and more responsible and we’re proud of our people who were behind it!

Explore the Project

🌍 NASA: Project Presentation

 📄 Project Report: View Presentation

 💻 GitLab Repository: AiRo on GitLab

At dvloper.io, we believe great systems are never built in isolation.They’re built by teams who see complexity as an invitation to innovate.

Congratulations, Bilciurescu Gabriel-Cosmin, Burea Mihai-Ovidiu, Mitran Andrei-Gabriel, Bazga Mihai-Carol, Pasaroiu Mihai! You did it!

Clarity. Collaboration. Code that matters.

In today's fast-paced IT operations and development environment, teams are drowning in tickets, runbooks, and scattered knowledge across JIRA, and countless documentation repositories. What if you could transform your entire incident history, knowledge articles, and runbooks into a single, secure AI brain – in less than a day?

Meet the AI Ticket Support Assistant by Dvloper.io – a revolutionary solution that super-charges your ticket systems with enterprise-grade AI, turning decades of tribal knowledge into instant, actionable intelligence.

The Opportunity: Your Ticket History is a Gold Mine

Every organization sits on a treasure trove of knowledge:

• Years of Incident Resolution: Thousands of tickets with solutions that worked
• Expert Runbooks: Procedures and workflows refined through experience
• Knowledge Articles: Documentation created but rarely discovered when needed
• Tribal Knowledge: Critical insights locked in resolved tickets and comments
• Repetitive Patterns: The same issues being solved over and over by different teams

Traditional ticket systems treat incidents as isolated events. But what if JIRA, and your other ticket systems could learn from every resolution, every runbook, and every knowledge article to become an intelligent support brain?

The AI Ticket Support Assistant transforms your entire incident history into actionable intelligence – automatically, continuously, and securely.

What Makes This Different: Enterprise AI Done Right

The AI Ticket Support Assistant isn't just another chatbot slapped onto your ticket system. It's a purpose-built, enterprise-grade platform with capabilities that set it apart:

Specialized ETL for Ticket Systems

No more hand-rolled scripts or custom integrations. Our pre-built connectors automatically ingest:

• JIRA: All major deployment types with comprehensive issue tracking
• Multiple Systems: Flexible integration with various ticket platforms

Configure once, and data flows automatically through scheduled syncs or real-time webhooks. Deploy in less than a day.

HybridRAG + GraphRAG Retrieval

This is where the magic happens. Our advanced retrieval system goes far beyond basic semantic search:

• Semantic Understanding: Comprehends the meaning and context of queries, not just keywords
• Relational Intelligence: Discovers connections between tickets, runbooks, and knowledge articles
• Superior Accuracy: Retrieves the most relevant solutions by combining multiple AI techniques

Result? Your team gets the right answer the first time, dramatically reducing resolution time.

LLM-Agnostic Architecture: Your Choice, Your Control

Unlike solutions that lock you into a single AI provider, we support multiple deployment options:

Cloud Options:

• OpenAI (GPT-4, GPT-4 Turbo)
• Microsoft Copilot
• Azure OpenAI Service

On-Premises Options:

• Open-weight models (Llama, Mistral, and more)
• Complete air-gapped deployment
• Zero data leaving your network

Switch anytime. Control costs. Meet data residency requirements. No vendor lock-in. Ever.

Truly Enterprise-Ready Security

Built from the ground up for enterprise security requirements

Any Deployment Model: Your Infrastructure, Your Rules

Every organization has unique security, compliance, and infrastructure requirements. That's why we support any deployment model:

Cloud Deployment

Azure Deployment

On-Premises Deployment

Hybrid Deployment

Choose what works today. Change tomorrow if needs evolve. No penalties. No migration headaches.

The User Experience: Simple Yet Powerful

One dashboard. Complete visibility. Total control.

System Requirements: Flexible & Accessible

The AI Ticket Support Assistant is designed to work with your existing infrastructure:

Ticket System Compatibility

JIRA - All major deployments (Cloud, Data Center, Server)
Multiple Systems - Integrate various ticket platforms simultaneously

LLM Requirements (Choose Your Path)

Cloud Option:

• OpenAI subscription (GPT-4, GPT-4 Turbo)
• Microsoft Copilot subscription
• Minimal infrastructure requirements

Azure Option:

• Azure subscription with Azure OpenAI Service
• Existing Azure infrastructure utilized
• All processing within Azure tenant

On-Premises Option:

• Hardware suitable for hosting local LLMs
• Air-gapped deployment capability
• Complete data sovereignty

Security & Authentication

Enterprise-grade security requirements supported
Keycloak integration for identity management
Compatible with existing SSO and RBAC systems
Compliance-ready for regulated industries

Perfect For These Use Cases

IT Operations & ServiceNow Teams

Transform your incident management process. Instead of escalating tickets to senior engineers, Level 1 and Level 2 support can query the AI system to find similar past incidents and their exact resolutions. Reduce escalations by 60%while improving MTTR (Mean Time To Resolution).

Software Development Teams

Stop reinventing the wheel. When developers hit a bug or technical challenge, they can instantly access solutions from similar issues across all projects. Cut research time by 75% and accelerate feature delivery.

DevOps & Infrastructure

Build an always-available expert system for operational procedures, troubleshooting guides, and infrastructure decisions. New ops team members can understand complex system architecture and common failure patterns in days instead of months.

Customer Support

Enable support teams to provide faster, more accurate responses by leveraging the collective knowledge of your IT operations and development teams. First-call resolution rates increase by 40%.

Compliance & Audit Teams

Maintain complete audit trails and ensure consistent responses to security incidents and compliance queries. Every AI interaction is logged and traceable.

Ready to Transform Your Team's Productivity?

The JIRA AI Producer-Consumer System represents the next evolution in project management – where artificial intelligence doesn't replace human expertise but amplifies it. Your team's collective knowledge becomes a powerful, searchable, and intelligent resource that grows stronger with every project.

Stop letting valuable knowledge get lost in ticket graveyards. Start building your intelligent project ecosystem today.

Key Takeaways

Transform existing JIRA data into intelligent, searchable knowledge
Reduce research time by 75% with natural language queries
Accelerate onboarding with AI-guided project exploration
Preserve tribal knowledge across team transitions
Enterprise-ready security with role-based access control
Measurable ROI through improved productivity and reduced costs

While testing Skyvern with different integrations, our teammate Serena ran into some unexpected authentication issues when connecting it to Bitwarden. She not only solved the problem, but also improved Skyvern so others won’t face the same roadblocks. Here’s what she had to say.

The Problem: Vague Authentication Errors

I kept getting authentication failures with no useful explanation. The output was short and gave no direction. After asking on the Skyvern Discord, I learned this was common. Bitwarden's CLI often produces vague errors that are hard to troubleshoot.

I eventually found the cause and fixed it. But the experience made me think about how Skyvern could make this easier for others.

The Idea: More Helpful Error Messages in Skyvern

The main issue was the lack of guidance. I added an optional extra field in error messages. This field can include:

• Hints that point to a possible solution
• Extra context relevant to the specific error condition

The system is general and can be expanded to include more conditions and hints over time.

The First Use Case

The first condition detects the exact Bitwarden CLI issue I faced. When triggered, it outputs the same fix that worked for me.

Why This Matters

• Reduces guesswork by giving practical guidance
• Helps new users troubleshoot faster without needing deep system knowledge
• Allows easy addition of new error-hint pairs in the future

Closing Thoughts

Debugging is part of development, but vague errors slow everyone down. By adding small, targeted hints to error messages, we make the system easier to work with and reduce repeated troubleshooting. This improvement should help anyone integrating Skyvern with Bitwarden.

We are proud to announce the release of our new internal application, now live in production. This platform has been designed to bring together essential day-to-day tools into a single, secure, and efficient environment. By centralizing these functions, we aim to reduce time spent switching between systems, improve visibility of information, and provide a consistent user experience for all employees.

The new product integrates several key operational areas into one cohesive solution. Employees can now manage leave requests, participate in performance check-ins, track goals, stay informed through company announcements, and access critical resources, all from a single interface. The result is not just a collection of features, but a fully connected system that supports everyday workflows and long-term productivity.

A Modern, Scalable Technology Foundation

The solution was developed using a technology stack carefully chosen for its ability to meet current needs while supporting future growth. Angular powers the user interface, providing a responsive and intuitive experience across devices. On the backend, Node.js with Express and TSOA offers a robust and maintainable service layer, while Prisma ORM ensures reliable and efficient communication with the database.

Security and authentication are handled through Keycloak SSO, enabling employees to log in with their existing credentials while ensuring compliance with modern identity management standards. The product’s components are containerized and orchestrated by Kubernetes, ensuring scalability and resilience. Continuous integration and delivery are managed through GitLab CI/CD, allowing for rapid, safe, and automated updates.

One of the key enhancements is the addition of the OKR (Objectives and Key Results) diagram, providing a visual and interactive way to track progress toward strategic and individual goals.

A Closer Look at the Features

At the heart of the application is the dashboard, which serves as a central hub for employees. From here, they can quickly navigate to timesheets, the company wiki, GitLab repositories, and other important resources. The layout prioritizes accessibility, ensuring that the most commonly used tools are only a click away.

Leave management is one of the core modules, allowing employees to request annual, sick, or other types of leave, view their remaining balances, and review their leave history. The system also provides a shared calendar view, making it easy for managers and colleagues to see upcoming absences and plan accordingly.

The performance check-in feature supports regular self-assessments and feedback exchange. Employees can complete structured assessment forms, reflect on their progress, and view feedback received from others. This promotes transparency, professional growth, and a culture of open communication.

The user profile section gives employees the ability to search for colleagues and view their profiles, making it easier to connect, collaborate, and understand team structures. It also allows users to manage their own personal details, ensuring information is accurate and up to date.

Ensuring Quality from Day One

A rigorous quality assurance process was applied throughout the development cycle. Automated testing verified the stability of core components, while manual testing ensured that the interface was intuitive and functioned as expected. User acceptance testing was conducted with realistic scenarios to confirm that the product met operational requirements.

In addition, security and performance checks were carried out to safeguard sensitive information and confirm that the system performs reliably under load. This careful approach ensures that employees can depend on the application from the moment they begin using it.

Accessing the Application

All employees may access the application after authentication. A detailed user manual link is available on the dashboard, providing step-by-step guidance and explanations for each feature. This resource ensures that employees can quickly become familiar with the product and make full use of its capabilities.

This launch represents a significant step forward in modernizing our internal systems. By consolidating multiple tools into a single, secure platform, we have created an environment that will evolve alongside the company’s needs. Feedback from employees will continue to shape future updates, ensuring that the system remains relevant, efficient, and valuable to our daily work.

ZTCM is a modular platform that automates configuration management for distributed edge and IoT devices. The platform reduces manual configuration tasks, speeds up deployment processes, and provides consistent security policies across device networks. ZTCM helps organizations in retail, manufacturing, logistics, and infrastructure manage their distributed devices more efficiently.

What ZTCM Does

• Automated device setup - Configure multiple devices without manual intervention
• Works with existing tools - Integrates with Keycloak, Ansible Tower, MongoDB, GitLab, and Teleport
• Reusable templates - Create configuration patterns once, use them repeatedly
• Security and tracking - Built-in access controls and detailed activity logs
• Flexible hosting - Deploy on cloud platforms, your own servers, or mixed environments
• Easy integration - Connect with existing IT management systems through APIs
• Real-time monitoring - Track device status and configuration compliance

1. What is Zero Touch Configuration?

How It Works

Zero Touch Configuration means devices can be set up and managed without manual steps during deployment or ongoing operations. The system handles device discovery, security authentication, configuration deployment, and status monitoring automatically.

The approach requires three main components: secure device identification using digital certificates, template-driven configuration using standard automation tools, and two-way communication between the management platform and devices for status updates and remote control.

Configuration templates contain all the settings a device needs including network parameters, security policies, and operational rules. These templates can include variables that change based on location or device type while keeping everything else consistent.

Where It's Useful

Manufacturing and Industrial Settings Factories deploy sensor networks that need identical configurations across production lines. Automated setup allows quick sensor replacement during maintenance without requiring specialized technicians on-site. Templates ensure all devices collect data the same way and follow the same security rules.

Retail and Edge Computing Stores, clinics, and transportation hubs use distributed computers that need standard configurations adapted to local network conditions. Automated deployment reduces setup time from hours to minutes while maintaining consistent security across all locations.

Network Equipment Management IT teams benefit from template-driven configuration that applies security policies, network settings, and service rules consistently. This approach reduces configuration mistakes and allows administrators to manage more devices with the same staff.

Remote Monitoring Applications Environmental monitoring, fleet tracking, and asset management systems need device configurations that vary by location while maintaining centralized data standards. Automation enables scaling these deployments without proportional increases in support staff.

2. How ZTCM Started

Managing distributed devices manually creates significant challenges for IT teams. When organizations deploy hundreds or thousands of IoT sensors, edge computers, or network devices across multiple locations, configuration becomes a bottleneck that slows operations and introduces errors.

The ZTCM project was developed as an academy learning initiative to address three key problems: the time-consuming nature of configuring devices individually, the difficulty of maintaining consistent security settings across all devices, and the need for centralized control without requiring technical staff at every location.

Research showed that existing solutions were either limited to specific vendors or too complex for many organizations. This created an opportunity to develop a flexible, straightforward approach to automated device configuration that works across different hardware types and deployment scenarios as a comprehensive learning project.

3. Building ZTCM as a Learning Project

Project Goals and Technical Learning

The ZTCM development served as a comprehensive learning initiative covering distributed system design, integration with existing tools, and automated configuration management. The project tackled real technical challenges while building practical experience with modern infrastructure management.

Learning objectives included implementing service-based architecture, designing secure communication protocols, optimizing databases for different data types, and integrating with existing authentication systems. These areas provided hands-on experience with production system development practices.

System Architecture

ZTCM uses a modular architecture that separates different functions like authentication, configuration management, task execution, and monitoring. This separation allows each part to scale independently based on demand while maintaining clear connections between components.

How the System Works

Users access the platform through a web interface that sends configuration requests to a request handler for validation and routing to the control center. The control center works with validation modules including marketplace and device verification components, while task execution happens through Ansible Tower integration.

All activities are tracked and recorded, with data stored in MongoDB and user authentication handled by Keycloak. Configuration scripts and templates are version-controlled in GitLab, while secure communication with remote devices uses Teleport tunneling and local agent software.

Development Process and Learning

The learning experience followed an step-by-step approach combining theoretical knowledge with practical implementation. Each development phase addressed specific technical challenges while building understanding of distributed system architecture.

Development started with single-server prototypes to validate core concepts, then moved to distributed architecture that introduced service communication and data consistency challenges. Later phases focused on integration requirements and deployment considerations.

Technical skills developed included container management, API design, database optimization, security implementation, and monitoring system integration. These skills align with industry requirements for infrastructure management platforms.

Technical Challenges and Solutions

Database design provided significant learning opportunities because different devices need different configuration parameters. This led to flexible document-based storage solutions rather than rigid table-based databases.

Authentication system integration revealed complexities in working with existing identity providers. Implementation required understanding security protocols and certificate-based authentication to support different organizational requirements.

Service communication introduced challenges in service discovery, load distribution, and error handling. The learning process involved implementing health monitoring, failure protection patterns, and distributed logging for system visibility.

Configuration template management required understanding variable replacement, template validation, and version control integration. These concepts connected software development practices with infrastructure automation requirements.

4. How ZTCM Can Be Used

Standalone Platform

ZTCM works as an independent device management solution for organizations that need comprehensive configuration control over distributed devices. Standalone deployment provides complete lifecycle management including device registration, configuration deployment, monitoring, and compliance reporting.

Infrastructure requirements include dedicated computing resources for control components, network connectivity to managed devices, and certificate authority integration for device authentication. Storage needs scale with device count and configuration complexity.

The platform supports device populations from hundreds to thousands of units, with performance scaling through horizontal component expansion and database optimization. Deployment time ranges from minutes for single devices to hours for large-scale updates.

Integration Tool

ZTCM connects with existing management platforms through standard APIs and notification interfaces. The platform can function as a specialized configuration component within larger IT management systems.

Development Pipeline Integration Configuration templates integrate with continuous integration pipelines for automated testing and deployment. GitLab integration enables version control workflows while notifications trigger configuration updates based on code changes.

IT Service Management The platform provides API endpoints for integration with IT service management platforms. Automated ticket creation captures configuration failures while status updates maintain visibility within existing management dashboards.

Network Management Integration Monitoring capabilities enable integration with network management platforms for centralized device status reporting. Configuration compliance checks integrate with security policy systems for automated correction workflows.

Deployment Options

Cloud Deployment Container management enables flexible scaling based on operational demands. Cloud provider integration supports managed database services and certificate management. Multi-region deployment provides geographic distribution for global device management.

Mixed Environment Cloud-based management console combines with on-premises execution components for organizations with data sovereignty requirements. Encrypted communication maintains security while enabling centralized management of distributed infrastructure.

On-Premises Deployment Local deployment supports environments with restricted network connectivity. Local certificate authority integration maintains security while offline capabilities enable configuration management during network outages.

5. Conclusion

ZTCM demonstrates how academy projects can address real-world operational challenges in distributed infrastructure environments. This learning initiative showcased practical approaches to automated device configuration management while developing expertise in distributed systems design.

The development process provided valuable insights into distributed systems design, secure communication protocols, and configuration management automation. Technical decisions regarding database selection, service-based architecture, and integration proved effective for the target use cases and demonstrated the potential for production implementation.

Platform capabilities developed through this academy project include significant reduction in configuration deployment time, elimination of manual configuration errors, and improved security through consistent policy application. The project demonstrates how educational initiatives can produce solutions with real operational value.

Future development could include machine learning integration for predictive configuration management, expanded device support for emerging IoT platforms, and enhanced integration capabilities with cloud-native management platforms. The modular architecture foundation developed during the academy program supports these enhancements without requiring fundamental redesign.

The ZTCM academy project establishes a foundation for understanding large-scale automation challenges while demonstrating practical solutions for modern device infrastructure management requirements through hands-on learning and development.

These three questions sparked our weekend sprint at ETHDam. The result is ChainLabGrid: an open source ROFL app that lets anyone contribute or consume compute power, while Trusted Execution Environments (TEEs) keep every contribution secure and every result verifiable.

Framing the problem

Research deadlines rarely wait for procurement cycles. If your model suddenly needs 10× more horsepower, you either overpay a cloud provider or scramble for hardware you’ll soon under-utilise. On the other side of the fence, countless CPUs and GPUs sit idle on laptops, workstations and edge boxes. ChainLabGrid bridges those two worlds: it turns spare capacity into a fluid, on-demand pool while guaranteeing data privacy and result integrity via Trusted Execution Environments (TEEs).

What we actually built at ETHDam

During the 48-hour sprint we delivered a running MVP that was awarded a place in the top 10 applications of the hackathon that:

• Accepts any compute job from a front-end App and records it on a Main Contract.
• Explodes the job into bite-sized subtasks—each gets its own Sub-contract so hundreds of workers can chip away in parallel.
• Lets contributors discover and claim work with a single wallet click; no prior staking or hardware disclosure required.
• Runs every validation step inside TEEs, producing cryptographic attestations that the correct code path executed on untampered data.
• Aggregates and encrypts the final artefact, then releases automatic payments to all successful workers.

A tour of the flow

1. Task creation – A user submits a compute request; the Main Contract stores metadata and notifies an off-chain Request Listener.
2. Task expansion – The listener verifies the payload, updates the active-task ledger and calls back to mint individual Sub-contracts.
3. Discovery & assignment – Contributors pull a live list of open work, pick a subtask, and the contract assigns it atomically.
4. Execution – The contributor’s node crunches numbers; capacity checks prevent over-commitment.
5. Validation – Sub-Task Validators inside TEEs replay the job deterministically; only approved outputs move forward.
6. Aggregation & payout – Once every piece passes, a Task Aggregator stitches results, encrypts them for the requester, and the chain disburses rewards.

Why TEEs instead of classic crypto-proofs?

• Privacy first – sensitive research data never leaves enclave memory.
• Lightweight trust – we sidestep heavy zero-knowledge proofs; the hardware attestation is both cheaper and faster to verify.
• Interoperability – by building on Oasis Sapphire (EVM-compatible), we reuse the Solidity ecosystem while inheriting enclave guarantees.

The impact we’re chasing

ChainLabGrid turns compute into a liquid commodity: researchers rent milliseconds instead of machines, newcomers monetise idle rigs with two clicks, and enterprises gain a privacy-preserving overflow buffer for bursty workloads. All secured by the same enclave tech that protects mission-critical fintech and healthcare systems.

What began as a hands-on learning experience has now grown into a reliable, daily-use internal product: the Timesheet App. Built entirely in-house, the app is now our centralized system for tracking time, managing project involvement, and generating reports that support HR, Project Managers, and Admin teams.

Why We Built the Timesheet App?

In every organization, time is one of the most valuable resources. We needed a way to clearly track and report how it’s spent—per person, per project. Off-the-shelf tools didn’t give us the flexibility or insight we were after, so we created a custom solution that could.

The goal was to build something that:

• Allows employees to easily clock hours on assigned projects
• Gives PMs visibility into team assignments and project timelines
  
• Enables HR to pull clean, exportable reports on time spent
  
• Ensures secure, role-based access to all data

A Closer Look at the App

At the heart of the Timesheet App is the Clocking tab, where employees record the time they’ve spent on their assigned projects. It’s intentionally minimalistic—quick to use and built to encourage consistency without getting in the way of the work itself.

The Projects tab gives everyone visibility into the current state of projects: when they start and end, who’s involved, and who’s managing them. This helps keep teams aligned and avoids confusion about responsibilities or timelines.

In the Users tab, admins can manage user roles and access levels. It provides a clear breakdown of who is working on what and helps ensure that people only see the data relevant to their role.

Finally, the Reporting page is where things come together. From here, users can generate detailed CSV reports filtered by date range, project, or user. These reports are used regularly by HR for audits and time analysis, and by project leads for better planning.

Engineering Behind the Scenes

We dedicated time to developing a robust backend to ensure optimal app performance and security. We also built a strong technical foundation to support the app's functionality and long-term performance.

• Authentication and Authorization: Integrated Keycloak for secure, centralized user management, including SSO, identity brokering, and fine-grained access control.
• Data Synchronization: Keycloak user data is automatically synced to the Timesheet App database to maintain consistency and simplify role assignment.
  
• State Management: Used NgRx Store to manage application state. As the app evolved, this centralized approach helped simplify data flow and improve responsiveness.
  
• Logging and Monitoring: A custom logging module gives us better insight into traffic and backend activity, helping us monitor usage patterns and quickly identify issues.
  
• Admin Dashboard: Built for administrators to oversee data, troubleshoot, and manage system-level settings.

Quality Assurance: Built-In from the Start

QA wasn’t an afterthought—it was embedded into the development process from the very beginning. Delivering a reliable experience was non-negotiable, especially for an internal tool that's used daily. 

Quality Assurance was integrated early into the development lifecycle, with a strong emphasis on test coverage and real-world use case validation, based on the following main focus-points:

• Comprehensive Test Case Design: Based on user stories, we created detailed QA test cases covering all primary and edge-case interactions.
• Post-MVP Bug Strategy: A structured bug identification and resolution plan was created after the MVP release, helping prioritize fixes and enhancements based on user impact.
• Automated Testing Suite: We implemented full automated testing across critical workflows. These tests ran consistently to validate new updates, catch regressions, and maintain app stability.
• Continuous Improvement: Feedback loops between QA, developers, and stakeholders ensured quick iterations, faster delivery, and consistent quality.

The end result? A smooth, high-performance tool that passed all automated checks and met our internal reliability standards before going into full production.

Real-World Results: The Impact

Since launching, the Timesheet App has become an essential part of our internal workflow. It’s used daily across departments and has become a reliable source of truth for time tracking and reporting. HR uses it for audits and payroll prep. Project managers use it to monitor progress and allocate resources. Employees use it to track their time with ease.

What began as a small internal experiment has grown into a production-ready tool that solves real problems. And thanks to its solid technical foundation, we’re well-positioned to keep improving it over time.