DSLCore
Operational software for the work between your systems
DSLCore builds working applications for the operational layer that enterprise and specialist systems leave to spreadsheets — inspections, permits, work orders, registers and returns — and connects them, so work moves between systems, and is checked, without re-typing.
The operational gap
Your enterprise system keeps the financial and transactional record.
Your engineering, monitoring and specialist systems keep their technical detail.
Between them sits the operational layer:
- inspections and defects
- permits and authorisations
- work orders and interventions
- technical registers
- statutory returns
- operational evidence
- calculations that feed invoices and reports
This is where spreadsheets, forms and undocumented workarounds tend to accumulate.
DSLCore is built for that layer. It works alongside your enterprise, engineering and monitoring systems, and where the work is operational it can be the system the work runs in.
Why DSLCore
Built from a model, so it can change. The operation is described once: records, relationships, workflow states and rules. The application, its documentation and its diagrams are generated from that description, so changing the operation means changing the model, not rewriting screens.
Adapted over time. A reference application is a working starting point. It is tailored to your terminology, roles and rules, and reshaped as the operation changes, without starting again.
Built from the ground up with current tools. DSLCore applications are made with current web technology from the base up.
Start small, and see it working. Begin with one bounded area. Review a working system with the people who do the work before committing to more.
Connected, with accountability. Applications join into networks, so work that crosses between them is carried out, recorded and checked.
From requirement to working application
Every DSLCore application begins with the same basic path:
source material or operational requirement
→ explicit operational model
→ generated working application
→ review and validation
→ organisation-specific implementationThe model defines the records, relationships, workflow states, controls and reporting requirements.
The application, documentation and relationship diagrams are generated from the same model, helping them remain aligned as the operation changes.
When the work crosses systems
Some operational problems fit within one application.
Others cross applications, teams and existing enterprise systems.
DSLCore applications can be connected so that information, exceptions, decisions and actions move between them while existing ERP, EAM, engineering, GIS, monitoring and specialist systems continue to perform the functions they already handle well.
This allows specialised applications to work together as an operational network rather than forcing everything into one large system.
Working reference applications
DSLCore reference applications show how defined operational models can become working systems.
The library now spans mining and resources, government and infrastructure, energy, oil and gas, shipping and ports, legal operations, asset management and operational assurance.
Examples include:
- critical control and permit-to-work management
- mine production and statutory reporting
- council fleet and workshop operations
- audit recommendation and evidence assurance
- AI governance and ethical risk
- grid connection and commissioning assurance
- port-call and shipping operations
- legal obligation and investigation management
Some applications manage a specialised operational process. Others manage evidence, exceptions, obligations, decisions and verification across a broader workflow.
Each is a working starting point rather than a universal procedure.
An implementation would be tailored to the organisation’s terminology, responsibilities, approval rules, regulatory obligations, integrations and operating practices.
Explore all reference applications
A lower-risk way to begin
A conventional software project often asks an organisation to commit before the structure of the problem has been properly tested.
DSLCore begins with a bounded operational area:
review → tailor the model → generate → validate → pilot → implementThis allows the organisation to review a working system with the people who perform the work before committing to a broader implementation.
Where suitable reference applications already exist, they can provide a starting point rather than beginning from a blank design.
See how an implementation works
Built from operational experience
DSLCore is the modern continuation of software and operational-system work developed over more than thirty years across heavy equipment, maintenance, workshops, reporting and coastal shipping.
That experience now underpins a broader library of operational, assurance and integration applications developed from real operating requirements, public specifications, statutory obligations and current industry needs.
Have an operational process no current system properly owns?
It may already contain the structure of a useful application.