Transparent reference prototype
Excel 365 with standardised worksheets, central configuration and automated test runs across instruments and oscillators.
TECHNOLOGY
Technology should make the domain logic reviewable – not hide it.
The current research state is documented in a transparent Excel prototype. Version 2 is intended to move the domain rules into a testable software architecture. The product value does not depend on the name of a programming language; it depends on independently reproducible calculations, controlled data handling and versioned change management.
CORE PRINCIPLE
From a transparent research prototype to a robust software chain
Excel is not treated as an embarrassment in the current state; it is the documented reference in which calculations can be inspected cell by cell. The next step is to implement the same logic independently and compare the output automatically against that reference. Only when both calculation paths agree under identical data and rules can the port be considered technically credible.
Independent reimplementation
The same calculation path is rebuilt in a testable core. Differences are explained rather than calibrated away.
Modular product architecture
Data, compute core, testing, interface, API, reporting and documentation are separated into clearly defined layers.
TARGET ARCHITECTURE
Six technical responsibilities instead of one large application
The exact tools may change during development. The responsibilities of the layers are more important than the brands used to implement them.
Data layer
Daily and intraday data, metadata, provenance, quality markers and test states are stored in a structured form.
Compute core
Decision Core, filters and execution rules are implemented as clearly bounded, automatically testable functions.
Test environment
Replication, regression tests, control groups, stress tests and later forward tests become repeatable processes.
User interface
Configuration, test control, analysis and help should be usable without changing the compute core.
Interfaces
API-ready module boundaries can pass data, results or risk states into existing institutional infrastructure.
Evidence & operations
Versions, test records, errors, warnings, provenance and technical documentation remain part of the system.
REPRODUCIBILITY
The first engineering task is not “more features” – it is the same calculation path.
A new implementation is trustworthy only if it can reproduce the existing reference state under identical data and parameters. That prevents silent rule changes during a technology migration.
Once the unchanged baseline is reproduced, new stops, cost models or APS functions can be introduced one at a time and their incremental effects measured.
1freeze reference data and rules
↓2implement independently
↓3compare outputs automatically
↓4explain every difference
↓5only then add new functionality
AI ASSISTANCE
AI may explain and assist – it should not autonomously rewrite the core.
In the target architecture, AI can support documentation search, result explanation, quality checks, development work and user assistance. The domain rules themselves remain versioned and controlled.
This keeps AI out of the role of an opaque decision-maker. A market or risk rule must still be describable, testable and explicitly approved.
AI transparency on this website →Appropriate AI tasks
- search and explain documentation
- summarise test reports
- assist plausibility and quality checks
- accelerate development and debugging
Not intended
- unsupervised changes to core rules
- black-box decisions without traceable cause
- automated performance promises
- replacement of domain approval
TECHNOLOGY CHOICES
Python, PostgreSQL and a web interface are working directions, not dogma.
A Python-based compute core with relational persistence, an analysis interface and API-ready boundaries is currently a sensible direction for Version 2. Those choices support reproducibility, automated testing and later integration, but they are not immutable buyer requirements. Institutional operating, security or infrastructure constraints may justify different tools.
Domain logic comes first: the technology platform should be replaceable. The domain definitions, data and test rules, and the requirement for reproducible results are the durable parts.
NEXT