Giovanni
Callebaut

The problem

A critical production installation needed a way to observe physical conditions associated with faults and wear. The project started with the machine and its failure modes: what should be measured, where a useful signal could come from and how it could reach a monitoring environment.

My contribution

I selected pressure, level, temperature, vibration and flow sensors according to the conditions being investigated. I worked out the sensor and network architecture around IO-Link and IFM moneo, including the route from field devices through the existing industrial network to the monitoring software.

The design had to fit the site’s IT and security conditions. Ethernet and Profinet infrastructure, network segmentation, virtual machines and software deployment were part of the integration context rather than details that could be decided independently.

The technical chain

Physical condition → sensor measurement → IO-Link communication → industrial network → monitoring environment

That chain required attention to power and cabling, protocol compatibility, network access, the monitoring software and the way the installation would be maintained. A sensor choice was useful only when the rest of the path could support it.

What reached the pilot stage

The work included a monitoring architecture and a partly implemented IFM moneo pilot, followed by handoff. Integration remained incomplete at the end of the project. The project should be assessed as an industrial IoT design and partial implementation, with a defined route for further work.

What I carry into an IT role

Tracing a problem across hardware, networking and software; working within an existing environment; understanding dependencies; and making technical decisions clear enough for others to continue the work.

The problem

The concept explored how measurements from a firefighter’s suit could reach a dispatcher. The intended information included heat, environmental conditions and body-related measurements.

My contribution

I worked on the complete data chain: sensing on the person, telemetry and communication, and a central view for the dispatcher. The task was to connect the physical measurement to an understandable display, while keeping the different parts of the system aligned.

The technical chain

Suit sensors → telemetry / communication → central dispatcher view

This was an early practical exercise in the combination of hardware, sensors, networking and software that later became central to my IoT studies.

Scope

The work was a proof of concept. Its value in this portfolio is the system thinking and technical exploration involved; operational deployment, field performance and safety certification are outside the demonstrated scope.

What I carry into an IT role

Thinking about information quality at each step, connecting devices to software and designing the result around the person who has to interpret it.

The work

I have explored web applications and source code to understand how security assumptions hold up in practice. My work has included reproducing behavior and preparing technical vulnerability reports with clear steps and an explanation of impact.

My method

I start with the permitted scope and a specific hypothesis. Source review and testing should explain the whole path: what a user controls, which behavior is reachable, what security property should hold and what actually happens.

For suitable local investigations, I use synthetic data and controlled environments. I aim for deterministic reproduction and a meaningful negative control, so a result can be distinguished from an assumption or an incidental error.

The report should make the technical issue understandable to another person: the relevant conditions, actual versus expected behavior, reproduction steps, limitations and observed consequence. I also check whether the issue is current and whether the root cause is already known before investing heavily in a report.

Public scope

This case describes the research process. Private reports and undisclosed findings are not part of this portfolio.

What I carry into an IT role

Structured troubleshooting, careful testing, attention to boundaries and the ability to turn a technical investigation into documentation someone else can use.

The concept

ATENA explored a modular platform through which satellites could receive power and servicing in orbit. A coherent concept needed to account for the spacecraft hardware as well as the vehicles, communication, control software and ground infrastructure supporting it.

My contribution

I helped bring satellite hardware, docking and power modules, servicing vehicles, communication, autonomy, control software and ground infrastructure into one architectural picture. I structured requirements, dependencies, development phases and demonstration steps for the founding team.

The work involved translating mission requirements and constraints into a system concept, alongside specialist mission-analysis input. The aim was to make the interfaces and assumptions explicit enough to investigate feasibility and plan further development.

The architectural question

What must each subsystem provide, and what must the surrounding system make possible for it to work?

Power, docking, communications, autonomy and ground operations all affect one another. Changing an assumption in one part can change the requirements elsewhere. Working through those dependencies was a substantial part of my contribution.

Scope

This is concept and planning work. The portfolio presents the architectural contribution and development thinking; flight hardware, funded deployment and a commercially operating service are outside the established project stage.

What I carry into an IT role

Breaking a complex problem into clear requirements and interfaces; making dependencies visible; and communicating across technical and business perspectives.

The context

Working in daily operations gave me a direct view of the information people need to keep a location running: products, stock, tasks, equipment, customer requests and the handover between shifts.

I progressed to Shift Leader during 2026. Alongside operational work, I looked at technical and system questions around POS, stock, reporting, data and internal tools in an operational context.

My contribution

I worked on concepts and prototypes for inventory follow-up, operational dashboards and structured menu and product data. I also helped translate recurring work into clearer procedures and customer-facing information.

The aim was to connect the operating reality to the data model: what a product is, which location it belongs to, what information a team needs and where the existing systems can provide it.

A concrete data-model example

One V1 design explored converting a menu image into structured menu and product data, stored per restaurant and associated with allergen information. That shared model could then support further work around POS integration, reservations or personalized menus.

Menu image → structured product / menu data → restaurant-specific records → downstream applications

The downstream uses were a design direction. They should be distinguished from integrations already implemented and validated.

Scope

The operational experience was hands-on. Dashboard, inventory and menu-data work included concepts and prototypes; individual production integrations and measured business improvements need separate evidence.

What I carry into an IT role

Listening to users, understanding practical constraints, translating an unclear request into a structured problem and making procedures easier to follow.

A public frontend experiment

ZOVU explores a restaurant-operations interface through a marketing frontend and an interactive POS mockup. It is a frontend prototype, not a functioning production POS. View the public repository

Hives

Hives is an initiative for practical ongoing support to businesses in Gent. Its scope includes websites, time-consuming administration and tools that help with daily work. I have worked on its service proposition, dashboard and onboarding concepts, with an interest in turning useful support into repeatable delivery.

The product question is practical: what does a business need help with, what information is required to deliver that help and how can the work be followed clearly by the customer and the people doing it?

Public project: hives.gent

HouseLively

HouseLively is a Shopify store project built around unusual, reasonably priced items for the home. My work has focused on the catalogue and customer journey: clearer product presentation, useful imagery, navigation and reducing friction around browsing and adding items.

The project connects product data and interface decisions to an understandable shopping experience. It also provides a practical setting for working with an existing commerce platform rather than designing every capability from scratch.

Public project: houselively.com

Scope

These cases show ongoing product and delivery work. Product ambitions, catalogue targets and planned marketing are kept separate from measured commercial results.

What I carry into an IT role

Turning requirements into a usable workflow, navigating existing platforms, organizing content and data, and iterating on an interface with the user’s task in mind.

The experiment

A location-based PWA prototype combining web technology, map and location APIs, data and mobile UX. The project used Mapbox / Google Maps APIs to explore a working location-based demo.

Scope

A working prototype/demo. The portfolio does not claim a production service, user count or operating scale.