Architecture
MySirt is a model-centric Execution Engine based on an execution meta-model. Operational systems are derived from formal definitions and remain structurally aligned with those definitions over time. The architecture is organized to keep behavior deterministic, inspectable, and regenerable, avoiding feature-by-feature implementation drift.
Architectural Stack
The engine is decomposed into stable layers. Each layer has a single responsibility and exposes deterministic behavior: equivalent models yield equivalent structural outcomes.
DSL as Executable Specification
MySirt uses a declarative, text-based DSL to define system structure, operational behavior and organizational rules. The DSL is not a documentation artifact: it is the authoritative specification interpreted by the engine. Structural validity and behavioral constraints are evaluated against the model definition, not against manually coded features.
Complete MySirt DSL Specification
The complete MySirt DSL is intentionally not publicly disclosed for intellectual property protection.
Public documentation explains the architectural principles, execution model, and conceptual foundations of the language without exposing its complete syntax or representative excerpts.
Detailed language specifications are available only during the technology evaluation process and, where appropriate, under confidentiality conditions.
Structural Regeneration
Model changes trigger coherent regeneration of dependent structures. The system remains aligned with the definition by design: modifications applied at the model level propagate deterministically to the generated structures, preserving behavioral and structural consistency over time.
The regeneration process is structural rather than cosmetic: it preserves the integrity of the model contract and prevents incidental drift across unrelated components.
Extension Points (Custom Code Integration)
Custom behavior can be attached to defined extension points without breaking regeneration. Generated and manual components can coexist under explicit boundaries: the model remains the authoritative source for structure, while external code is constrained to designated integration hooks.
This separation supports long-term maintainability: regenerated structures stay coherent and external integrations remain traceable and replaceable.
Traceability Layer
MySirt provides built-in traceability at Execution Engine level. Generated systems can include integrated mechanisms for monitoring data changes and system access events, depending on the model configuration. Traceability is not implemented at application level but derived automatically from the Execution Engine.
Two complementary components provide this capability:
- Audit Trail — records entity data changes (INSERT, UPDATE, DELETE) together with the responsible user and the exact timestamp of the event, preserving both the modification delta and the full record snapshot.
- Access Log — records authentication events such as LOGIN_SUCCESS, LOGIN_FAILED and LOGOUT together with the originating IP address.
The audit engine stores both the delta of the modification and the full snapshot of the affected record, enabling complete reconstruction of the system state at any point in time.
Auditing behavior is configurable at model level. The system definition may enable auditing globally, while individual entities can adopt different auditing strategies depending on operational needs.
- Basic auditing — records that a modification occurred without storing detailed field changes.
- Delta auditing — records the specific fields that changed together with their previous and new values.
- No auditing — entities that do not require traceability can be excluded from the auditing mechanism.
This model-level configuration allows system designers to balance traceability, storage cost, and performance, applying detailed auditing only where it is operationally required.
Audit Trail – Event List: Generated systems provide a searchable view of recorded entity events.
Audit Trail – Event Detail: Each recorded event exposes both the operation metadata and the stored structural snapshot of the affected entity.
Access Log – Authentication Events: Authentication activity is tracked independently from data changes, providing operational visibility over system access.
Current Engineering Boundaries
- Frontend layer based on an earlier web framework, architecturally replaceable without affecting the core Execution Engine.
- Proprietary database access library (documented), replaceable at the integration boundary.
- Ongoing refinements focused on formalization and consistency of the model contract.
These constraints do not alter the engine’s execution model: the core architecture remains based on the execution meta-model and deterministic.