Incomplete information
An entity can exist without all information required to advance.
Control
Required relationships, explicit states and validations.
PERSONAL PROJECT · OPERATIONS · AUTOMATION · DATA · CONTROLS
SICALPE
From scattered processes to a connected system for operational processes.
SICALPE began with an apparently simple problem: reusing operational information without entering it again and again into different documents.
As the problem grew, so did the solution. What started as a spreadsheet-based automation evolved into a system for representing processes, relationships, rules, permissions, states and controls in a structured way.
THE PROBLEM WAS NOT THE DOCUMENTS
A document can be correct and the process behind it still be fragmented.
In complex operations, the same information can affect people, resources, movements, documentation, authorisations, planning and different controls. When each part is managed separately, gaps become difficult to see.
- The same data entered more than once
- Different versions of the same information
- Relationships known only by the person doing the work
- Documents generated from information that has already changed
- Controls applied too late
- Tasks that look complete before their prerequisites are met
THE SOLUTION GREW WITH THE PROBLEM
Each stage exposed the requirement for the next one.
01
Automate repetition
The first version centralised information in Excel and reused it to generate documents: enter the data once, rather than transcribe it repeatedly.
02
Structure information
An Access database made it possible to explore a more rigorous relational model, automate queries and understand dependencies between process elements.
03
Design for permissions, relationships and evolution
The current PocketBase-based platform progressively separates data, logic, automation and interface. PostgreSQL remains a possible next step when maturity, scale or operational requirements call for it.
A CONNECTED OPERATING MODEL
What was distributed across documents and individual knowledge becomes explicit system relationships.
The aim is not merely to store information. It is to understand what depends on what, what is missing, what has changed and what may be invalidated as a consequence.
- People
- Assignments and requirements
- Resources and assets
- Movements and planning
- Documents
- Validation and states
A sanitised view of the dependency chain.
DESIGN FOR ERRORS, NOT ONLY THE HAPPY PATH
Automation is useful only if it also prevents the wrong process from moving faster.
Duplicate information
The same reality should not be represented incompatibly more than once.
Control
Identifiers, relationships and uniqueness constraints.
Changes affecting other processes
Changing a data point can invalidate earlier documents or decisions.
Control
Traceability, history and relationships between entities.
Premature completion
A task can look complete while it still depends on another condition.
Control
Explicit states and prerequisites before allowing progress.
FROM DATA TO OPERATIONAL CONTROL
The useful question is not “do we have the document?”
- 01Are the data it contains still valid?
- 02Are the conditions needed to generate this result met?
- 03Which elements are affected if this information changes?
ARCHITECTURE DECISIONS
Architecture is knowing when a solution no longer fits the problem it has to solve.
Excel
Validated the principle of one reusable source quickly.
Access
Enabled a more structured relational model and exposed new requirements.
PocketBase
Supports rapid iteration on the model, relationships, authentication and application.
PostgreSQL
A possible evolution when the system needs greater robustness, scale or maturity.
AI IN THE PROJECT
A multiplier for implementation and review, not a substitute for system design.
Generative AI helps explore alternatives, analyse problems, work with code, queries and transformations, document, detect inconsistencies and divide complex work into smaller tasks. The process model, functional criteria, architecture decisions and final validation remain governed by the project.
MY ROLE
End-to-end involvement, from the recurring failure to the system that makes it inspectable.
- Problem and process — identifying real needs, recurring errors and the process model.
- Data — entities, relationships, states, constraints and traceability.
- Architecture — evaluating alternatives as requirements increased.
- Automation and product — reusable information, functional capabilities and interface.
- Quality and documentation — controls, validation, failure modes and reproducible structures.
STATUS AND MATURITY
Functional / evolving
People area
Functional.
Operational area
Advanced and still evolving.
Additional capabilities
Designed and developed progressively according to the project roadmap.
WHAT SICALPE DEMONSTRATES
SICALPE matters here not because of a particular technology, but because it captures a way of working: observe a real process, find recurring errors, understand dependencies, convert implicit knowledge into data and rules, introduce controls before errors reach the result, and evolve the architecture as the problem evolves.
The public case uses sanitised information and architecture and does not disclose personal or sensitive operational data.