A representation
Defines a system, relationship or mechanism. A model can be useful without being a proven description of reality.
Lab
Models, experiments and open questions.
The Lab is a working record. A status label is part of each entry: established definitions are separated from hypotheses, prototypes and things not yet tested.
How to read the Lab
Each entry shows its status: what is defined, what is proposed, what has been tested and what would count as progress.
A testable claim
States what is expected and what evidence would support or weaken it.
An implementation in progress
Shows that some parts have been built, not that the system is deployed or validated.
A test
Defines population, intervention, metric, guardrails and interpretation.
Model / In progress
Entropy
A market-state interpretation system focused on whether observed movement is structurally meaningful, and what operational actions the current state permits.
At a glance
| Field | Entropy |
|---|---|
| Type | Model, with a prototype in development |
| Purpose | Decide what a market state permits, not forecast price |
| Inputs | Liquidity, volume distribution, volatility and persistence of movement. Not price alone |
| Outputs | A regime label (Trending, Rotational, Shock, Low activity) and the operational permission it implies |
| Status | Definitions established; prototype in progress; no validated live performance |
| Next step | Testable regime criteria, a fixed evaluation window, out-of-sample validation, documented failure modes |
Purpose
Entropy is designed to identify market state and operational permission. It identifies market state and permission rather than predicting direction.
Established definition
MTT / Minimum Trend Time
The minimum persistence or duration required for a trend to qualify as structurally meaningful.
Regime vocabulary
Information considered
The prototype's stated emphasis is liquidity, volume distribution and volatility rather than price alone.
Operating model
Observe market conditionsClassify regimeDetermine operational permissionAct only within permissionReview outcomes
Next milestone
Define testable regime criteria, fix an evaluation window, validate out of sample and document failure modes.
Architecture concept / Not deployed
Personal intelligence architecture
A proposed layered system where one orchestrator routes work to specialist capabilities, draws on a knowledge layer, and keeps a human in charge of consequential decisions.
At a glance
| Field | Definition |
|---|---|
| Type | Architecture concept. Working name: Strata |
| Purpose | Cut the fragmentation between projects, knowledge and repeatable workflows |
| Status | Concept |
| Next step | Write one decision record, then prototype one bounded workflow end to end |
How the layers work
Request and contextCentral orchestratorSpecialist capabilitiesKnowledge and memoryValidated outputHuman review
| Part | What it does | What it can access | Guardrail |
|---|---|---|---|
| Orchestrator | Reads the request, picks the capability, splits work, assembles the answer | Request, task state, capability list | Cannot act externally without approval |
| Capabilities | Do one job each: research, drafting, analysis, modelling | Only the context they are handed | Return sources and confidence |
| Knowledge and memory | Store confirmed facts, hypotheses, preferences and temporary state separately | Indexed notes and documents | Never overwrites a confirmed fact silently |
| Validation | Checks sources, conflicts, format and safety limits | Outputs and their sources | Failed checks go back, not forward |
| Human review | Approves anything consequential, and corrects the system | Final output and its evidence | Required for external or irreversible actions |
One workflow, end to end
Request: “Summarise what we know about attribution gaps for a case study.” The orchestrator sends it to research and analysis capabilities. Each pulls only the relevant notes. Validation checks every claim against its source and flags anything unsupported. A person approves the draft, and the correction is recorded as a labelled hypothesis, not a fact.
Experiment pattern / Template
Preapproval limit testing
An experiment design pattern for testing whether an offer change affects take-up while maintaining portfolio guardrails.
Hypothesis structure
A change to a loan offer may increase take-up. That is not sufficient to establish success: approval, disbursement, repayment and portfolio quality also matter.
Required experiment record
| Field | Required definition |
|---|---|
| Population | Eligibility, exclusions, sample size and assignment method. |
| Intervention | Exact difference between control and treatment. |
| Primary metric | Take-up rate with a precise numerator, denominator and window. |
| Secondary metrics | Offer selection, approval and conversion where relevant. |
| Guardrails | First-payment default, delinquency, portfolio yield and other approved risk measures. |
| Interpretation | Observed effect, uncertainty, limitations and decision. |