PROJECT 01 / Independent research
LOGRETTA
A quantitative trading platform.
Website coming soon
- My role
- Architecture & software development
- Focus
- Python, C++, quantitative modelling & risk systems
How do you review the decisions behind a trade?
LOGRETTA is my independent research in quantitative finance, trading software and risk systems. I am interested in the complete decision: the market observation, the model’s interpretation, the conditions under which an order may proceed, and the record of what follows.
The project brings those questions into software architecture and interface design. The white dashboard shown here is an interactive study: change the reporting period, inspect a closing session, then read the trades behind it. The journal can be filtered and exported. On a phone, the complete interface opens from the still. The data is invented for this portfolio; it is not a live terminal or a record of verified trading returns.
Keep the reasoning as inspectable as the result.
From market inputs to execution.
- 01
Observe
Record the research inputs and their context. Missing or unsuitable inputs should remain visible rather than being silently replaced with convenient assumptions.
- 02
Evaluate
Make model decisions inspectable. Keep the reasoning context alongside the result so a research idea can be examined and repeated.
- 03
Constrain
Place explicit risk boundaries between a research decision and the order path. Required operating conditions must be satisfied before proceeding.
- 04
Record
Retain the order lifecycle, fills and account observations, so research can be reviewed against what actually happened.
A connected system, with explicit boundaries.
The architecture I am developing separates observation, interpretation and action. Data supplies market context. A model proposes a candidate decision. Risk determines the conditions under which it can be considered. Trade management follows orders and positions. Records preserve the observations that allow the whole sequence to be reviewed.
The wiring matters as much as the model. A decision should remain connected to its input context, configuration and account state, so it can be examined later. An execution record should distinguish an intended order from an acknowledgement, a fill and a confirmed position. That separation makes the system easier to reason about when information arrives late, a component fails or an account observation changes.
The mark and the workspace share a visual concern: distinct parts, held in a clear relationship. The same attention to hierarchy travels from identity to interface.
Observation
Market input, timestamp and quality travel together.
What was available?
Keep the input’s identity, observed time and quality context together. A later decision should be readable against the information that was available then, rather than against a newer observation.
Read the architectureCandidate decision
The model’s proposal retains its input context and configuration.
What was proposed?
Keep the candidate linked to that input and the configuration used to form it. A proposed action is still an intent; it does not establish that an order was submitted or a position exists.
Follow the decision traceRisk review
Required account observations and exposure limits govern whether it may proceed.
What conditions apply?
Configuration states what is required. An account observation states what is known. If a required observation is missing, preserve that uncertainty and hold the intent instead of substituting an assumed value.
Compare complete and missing contextInspectable record
Intent, acknowledgement, fill and confirmed position remain distinguishable.
What is actually known?
A response to an order request, an execution record and a confirmed account position answer different questions. Keeping them separate makes it possible to revisit a decision without treating an intention as an outcome.
Read how the workspace keeps context
The record returns the decision to its context. Missing or uncertain information must stay visible before another action is considered.
Keep each candidate connected to its input context and the conditions required to proceed. The record separates an intended order from acknowledgement, fill and confirmed position.
Independent research · explanatory architecture.
- Data & model context
- Preserve timestamps, input quality and the research configuration around a decision. Missing information should stay visible, rather than disappear behind a convenient default.
- Risk before execution
- Keep admission checks separate from signal generation. A model’s confidence is an input to review; it does not replace exposure limits, account checks or execution constraints.
- Records & recovery
- Retain the relationship between a decision, its order lifecycle and the account observation. Recovery should reconcile those records before creating another action.
- Configuration & provenance
- Keep the model version, input period and operating assumptions with the decision. Comparing two results requires knowing what changed between them.
The trade continues after the signal.
A signal is only one part of a trading system. Position sizing, available margin, total exposure, trading costs and drawdowndrawdownA decline from a previous high. This portfolio’s dashboard calculates it from the selected period’s running closing-balance peak; daily closing observations do not describe intraday losses or prove risk compliance. boundaries determine the conditions in which a candidate trade can be considered. My research treats risk as explicit operating constraints, with the account and the quality of the available information visible at the point of review.
Trade management follows the full lifecycle: intent, submission, acknowledgement, partial or complete fills, open-position observations and closure. The architecture needs to account for rejected requests, stale information and interrupted sessions. An exit also has a different purpose from an entry: reducing an existing exposure must remain distinguishable from proposing a new one.
The example below keeps one candidate fixed while its account context changes. Missing information, an older observation and a recent record from another account each answer the review question differently. The record has to retain why it was held, rather than making uncertainty disappear when the view changes.
Context before a new order
One fixed question: context for SAMPLE-A at . The times and two-minute boundary are authored example settings.
Complete context
Recorded context
- Input record
- Sample input for SAMPLE-A
- Account observation
- Sample observation available
- Observed at
- Age at this review
- 60 seconds
- Example boundary
- The same account; no more than 120 seconds before review
Candidate intent
Unsubmitted proposalThe candidate for SAMPLE-A stays linked to its recorded input and configured boundary while awaiting admission review.
Admission review
Context presentThe account reference matches. The fixed observation is 60 seconds old, within this example’s 120-second boundary. The proposal can be considered for review; this guard does not establish risk compliance.
Why a proposal is not a position
- Proposal
- An intended action awaiting review. It is not an acknowledgement or a fill.
- Acknowledgement
- A response about a submitted request. It does not establish that execution occurred.
- Fill
- An execution record, which may be partial. The account position still needs observation.
- Confirmed position
- The account observation that establishes the position state. Preserve it separately from the intention and order messages.
Inspectable record
Ready for reviewKeep the input, sample observation and configuration connected to the review outcome. Readiness is not execution.
Missing context
Recorded context
- Input record
- Sample input for SAMPLE-A
- Account observation
- Missing — account state unknown
- Observed at
- Unknown · no observation
- Age at this review
- Unknown
- Example boundary
- The same account; no more than 120 seconds before review
Candidate intent
Unsubmitted proposalThe candidate for SAMPLE-A stays linked to its recorded input and configured boundary while awaiting admission review.
Admission review
Intent heldThe sample account observation is missing. Hold the intent before any new order; do not assume an account state.
Why a proposal is not a position
- Proposal
- An intended action awaiting review. It is not an acknowledgement or a fill.
- Acknowledgement
- A response about a submitted request. It does not establish that execution occurred.
- Fill
- An execution record, which may be partial. The account position still needs observation.
- Confirmed position
- The account observation that establishes the position state. Preserve it separately from the intention and order messages.
Inspectable record
Held · uncertainty retainedKeep the candidate intent and configured boundary in the record, with the missing account observation explicitly marked.
Older observation
Recorded context
- Input record
- Sample input for SAMPLE-A
- Account observation
- Recorded for SAMPLE-A · outside the example interval
- Observed at
- Age at this review
- 300 seconds
- Example boundary
- The same account; no more than 120 seconds before review
Candidate intent
Unsubmitted proposalThe candidate for SAMPLE-A stays linked to its recorded input and configured boundary while awaiting admission review.
Admission review
Intent heldAn observation exists, but it is five minutes older than the fixed review point. This example requires one from the preceding two minutes. Keep the proposal held until the required context is available.
Why a proposal is not a position
- Proposal
- An intended action awaiting review. It is not an acknowledgement or a fill.
- Acknowledgement
- A response about a submitted request. It does not establish that execution occurred.
- Fill
- An execution record, which may be partial. The account position still needs observation.
- Confirmed position
- The account observation that establishes the position state. Preserve it separately from the intention and order messages.
Inspectable record
Held · newer context requiredRetain the original observation and its time with the held candidate. A newer observation would belong to another review; it should not silently rewrite this record.
Different account
Recorded context
- Input record
- Sample input for SAMPLE-A
- Account observation
- Recorded for SAMPLE-B · candidate belongs to SAMPLE-A
- Observed at
- Age at this review
- 60 seconds
- Example boundary
- The same account; no more than 120 seconds before review
Candidate intent
Unsubmitted proposalThe candidate for SAMPLE-A stays linked to its recorded input and configured boundary while awaiting admission review.
Admission review
Intent heldThe observation is recent, but it belongs to another account. A familiar-looking record cannot substitute for the candidate’s required account context.
Why a proposal is not a position
- Proposal
- An intended action awaiting review. It is not an acknowledgement or a fill.
- Acknowledgement
- A response about a submitted request. It does not establish that execution occurred.
- Fill
- An execution record, which may be partial. The account position still needs observation.
- Confirmed position
- The account observation that establishes the position state. Preserve it separately from the intention and order messages.
Inspectable record
Held · account identity differsKeep both account references visible: SAMPLE-A was requested; SAMPLE-B was supplied. Hold the candidate without borrowing another account’s state.
Complete context reaches a reviewable proposal. This example does not submit an order.
Complete context. Complete context reaches a reviewable proposal. This example does not submit an order.
Missing context. Missing context holds the intent. Its uncertainty remains visible in the record instead of becoming a convenient default.
Older observation. A known account reference does not make an older observation current. The record preserves why this review was held.
Different account. Fresh information still has to belong to this question. The account mismatch stays explicit in the resulting record.
Authored software example checking context presence, time and identity. No live account, broker connection or trading outcome is represented.
- Layered limits
- Consider per-trade risk together with instrument concentration, account exposure, available margin and session or drawdown constraints.
- Execution quality
- Review fill prices, slippage, costs and order status alongside the strategy decision. Gross returns alone do not describe the result of execution.
- A reviewable lifecycle
- Connect open positions, realised outcomes and execution records. Incomplete or uncertain state should be identified before another decision is admitted.
- Entries, exits & interruptions
- Distinguish new exposure from reducing an existing position. Loss limits, stale observations and session interruptions need defined responses, including the conditions for resuming activity.
Different contexts. Consistent records.
The workspace offers Standard, Prop and Research views over the same sample ledger. Standard pairs closing balances with performance and recent trades. Prop opens the risk view with illustrative daily-loss and drawdown limits. Research replaces reference limits with observed risk and adds a distribution of trade outcomes against initial risk.
Changing the reporting period updates the balances, statistics, charts and journal together. A chart observation leads to that session’s recorded trades; a day with no closed trades remains visible as a carried-forward balance. The journal can be filtered, sorted and exported. Expanding, reopening or returning from the compact still preserves the selected controls. These interactions use invented data within the portfolio, with no connection to a broker or live account.
A report is a chain of questions.
Begin with what the numbers belong to. Follow what changed. Then look at the records behind the result. That order is part of the interface’s structure.
What belongs to this report?
The account and the period give the figures their context. A change of view has to carry both with it.
Begin with the context.
- Account
- Demo · USD 100,000
- Reporting period
- 01 Jul – 30 Sep 2026
What changed across the period?
The curve holds the sequence of observations. A headline can summarise it; the shape makes the path visible.
Equity through the reporting period.Original concept crop · illustrative figures
Which records explain it?
A recorded outcome belongs beside the information that explains it. The journal gives the report something to return to.
- Account
- Demo · USD 100,000
- Reporting period
- 01 Jul – 30 Sep 2026
EURUSDBuyClosed · 30 Sep 2026 · 14:22- Entry
- 1.08342
- Exit
- 1.08654
- Net result
- +$312.40
One record from the owned interface concept.
Re-typeset for this view · invented figures
- Standard
- Balance and drawdown inspection, monthly net P&L, recent trades, instrument attribution and an exportable journal. One-month and three-month reports use the same underlying ledger.
- Prop
- Illustrative reference limits of 2% for the largest losing session and 5% for closing drawdown, with remaining headroom. These are demonstration settings, not the rules of a named funding provider.
- Research
- Observed risk, annualised Sharpe, expectancy and an outcome distribution in net R. Calculation notes explain the sample, cost treatment and observation interval.
Read the return alongside the risk.
The interface connects headline measures to a closing-balance curve, monthly net profit and loss, trade outcomes, instrument attribution and the trade journal. Each report reconciles to the same sample ledger. Commissions are deducted from every trade; win rate, profit factor and expectancy use those net outcomes.
Sharpe compares average differential return with the variability of those differential returns. The benchmark, observation interval and assumptions behind annualisation matter. Historical ratios do not establish future returns; the review also needs drawdown, trading costs, outcome distribution and the size of the observed sample.
- Net profit & balance
- Realised sample P&L after commission, carried into each weekday closing balance. The one-month report opens with the balance accumulated before September; unrealised positions are not modelled.
- Win rate & expectancy
- Winning net outcomes divided by all closed trades, alongside average win and average loss. Expectancy is the sample’s mean net result per trade; a breakeven outcome would count in the sample without counting as a win.
- Profit factor · net
- Aggregate positive net outcomes divided by the magnitude of aggregate negative net outcomes. A sample with no losses displays an em dash rather than an infinite ratio.
- Closing drawdown
- The largest decline from the selected period’s running closing-balance peak. Daily closing observations cannot establish intraday losses, exposure or risk compliance.
- Sharpe assumptions
- Weekday closing-balance returns, a zero benchmark, sample standard deviation and square-root-of-252 annualisation. A sample with no return variation displays an em dash.
- Attribution & journal
- Instrument totals reconcile to net P&L. Select an instrument’s total to open its matching trades, then inspect strategy, direction, duration and net R. Filters and sorting refine the journal; CSV export includes the complete filtered result with its illustrative-data notice.
Independent research
Research in progress.
An independent research project covering quantitative models, software architecture and risk systems. The white dashboard is a working interface study with reporting periods, chart inspection, risk views and an exportable trade journal. All figures are invented for the portfolio.
Return to the reasoning.
- Research into market inputs and model evaluation↗
The architecture argument: inputs, decisions and records.
- Architecture for risk admission and trade management↗
The admission study: uncertainty stays beside the decision.
- An illustrative account analytics workspace↗
The working portfolio interface, with invented account figures.
Still taking shape.
The dedicated LOGRETTA website is coming soon. Further architecture notes, research material and interface studies will be published as the project develops.
