Original research protocol
How Lumiere measures pre-trade review completeness
A pre-specified, privacy-limited method for measuring whether explicitly consenting Lumiere beta reviews contain ten inspectable risk fields. It is not a performance study, a ranking of traders, or a result about active traders generally.
Direct answer
What does the Lumiere completeness benchmark measure?
It measures whether an eligible saved pre-trade review contains ten defined workflow fields, from source freshness through a no-trade condition and save timing. Results stay withheld until the sample, privacy, account-cap, suppression, repeatability, and legal-review gates all pass.
Current publication status: results withheld
What is public now
The research question, fixed field definitions, inclusion rules, privacy boundaries, publication thresholds, and required interpretation.
What is not public
No completeness percentage, field rate, account result, comparison, performance association, or claim about “most traders” is authorized.
Method source: This page is the visible protocol for methodology version discipline-benchmark-1. Lumiere will update this same canonical if an eligible beta baseline is later approved; it will not backfill a result into an earlier review period without naming the applicable version.
Research question and unit of analysis
The question is narrow: among explicitly consenting Lumiere beta accounts, how often does an eligible saved review contain the minimum structured fields needed to inspect the planned risk before an order decision?
The unit is one completed paper-planning review, not a person, trade outcome, order, fill, account return, or pageview. Multiple reviews from one account can be included only after deduplication and the account-contribution cap. The method does not score trading skill or performance, and the consenting product sample is not presumed representative of active traders.
The ten deterministic completeness fields
- Source and freshness
- A provider label and valid evidence timestamp exist, with stale state recorded explicitly.
- Setup or thesis
- The saved setup or structured trade-plan setup is non-empty.
- Invalidation
- The plan names what would make the setup wrong and includes a positive numeric level.
- Entry condition
- The plan contains an observable entry trigger rather than the undefined-entry placeholder.
- Dollar-risk budget
- The structured risk budget is finite and greater than zero.
- Risk per unit
- The structured risk per unit is finite and greater than zero.
- Valid position size
- Quantity is a positive whole unit and is not above the risk- and capital-constrained theoretical maximum.
- Execution limitation
- The plan contains at least one non-empty execution or order limitation.
- No-trade condition
- The plan contains at least one explicit condition for standing aside.
- Saved before outcome
- The saved timestamp is valid and, when a later paper outcome exists, is no later than the outcome-review timestamp.
These are completeness checks, not quality scores. A field can be present and still be poorly reasoned, based on stale or incorrect inputs, or followed by a losing paper outcome. See the risk-first checklist for the underlying workflow.
Minimum publication gates
- Current consent
- Only events recorded under the current separate Discipline Benchmark consent and Privacy versions are eligible.
- Approved retention
- The consent text and retention treatment must receive explicit approval; sample size cannot imply that approval.
- Minimum sample
- At least 30 consenting accounts and 100 eligible reviews after exclusions and account capping.
- Account cap
- No account may contribute more than 10% of included reviews.
- Small cells
- A field result is suppressed when either its complete or incomplete cell is smaller than 10.
- Exclusions reported
- Invalid, out-of-period, outdated-consent, duplicate, and capped reviews must be counted.
- Repeatable aggregate
- A second read-only run over the unchanged snapshot must reproduce the first run’s SHA-256 aggregate fingerprint.
- Legal/privacy wording
- Publication language must receive explicit approval and remain limited to a beta workflow baseline.
How repeatability is proved
- Derive on the server.The browser cannot choose the ten boolean results or supply benchmark identity fields.
- Run read-only once.The report deduplicates eligible review updates, applies the account cap, records exclusions, and prints an aggregate fingerprint while withholding all field statistics.
- Run the unchanged snapshot again.The second run must receive and match the first run’s 64-character fingerprint. Generation time and input ordering do not change that fingerprint.
- Keep approvals separate.A matching fingerprint does not satisfy consent, retention, sample, small-cell, or legal/privacy gates. Every gate remains independently visible.
Privacy boundary
Included metadata
Salted pseudonymous account and review identifiers, event and saved timestamps, consent and Privacy versions, app version, and the ten server-derived boolean fields.
Excluded data
Email, Lumiere user id, symbol, free text, journal text, exact prices, broker credentials or account data, screenshots, voice, raw prompts, orders, fills, and performance outcomes.
Discipline Benchmark consent is separate, signed-in, and off by default. Withdrawing it stops future collection. The account’s delete-research control removes locally stored research events associated with the current salted identifier and withdraws optional research consent. Read the Privacy Policy for the complete current data-practice statement.
What an eligible result could—and could not—say
Permitted interpretation
A dated beta workflow baseline describing the included consenting Lumiere sample, with raw numerators, denominators, exclusions, caps, suppression, version, and limitations.
Prohibited interpretation
That Lumiere users are more disciplined, the checklist improves returns, reviews prevent losses, the sample represents most traders, or completeness causes a trading outcome.
See the workflow