Secret values
The door reports the platform connection key as a configured or not-configured boolean, and never its value. No answer prints a credential’s contents, and the door never reads a secret’s contents to publish them.
Security model · for operators
Five boundaries, what the product never reaches, and how to report a concern.
Security here is mostly a list of refusals: the product holds evidence integrity, mandate authority, effect idempotency, replay, and settlement as constraints rather than intentions. This page is the operator view of those boundaries and of the one channel for reporting a problem.
live:falsesimulation-onlyno custodyfail closed
Boundaries
What each boundary holds, and what it refuses.
Each row states the control in the product and the behaviour when it does not hold. The refusal column is the one that matters: a boundary that cannot refuse is not a boundary.
| Boundary | What it holds | What it refuses |
|---|---|---|
| Evidence integrity | Observation time, availability time, and source identity travel with every fact, and the content fingerprint is derived from the evidence rather than supplied by the caller. The sealed corpus digest is printed in the receipt. | Facts published after the decision clock, observation timelines that contradict the market or each other, and development cases that overlap the holdout all stop the run before inference. |
| Mandate authority | Nothing acts by default. A mandate states the permitted effects, the expiry, the confidence floor, and the exposure bound, and composes with the domain’s own risk policy. | A missing, expired, or invalid mandate, a prohibited effect, an exposure request beyond the declared bound, or a breach of the ruin policy produces a reasoned abstention instead of an effect request. |
| Effect idempotency | Only a replay-verified admitted act reaches an adapter. The first call returns a receipt bound to the requested key; the same key with the same request reads that receipt back. | The same key with a different requested effect fails closed and the original receipt stands, so an effect is never repeated to satisfy a retry. |
| Replay | A run records its replay law: a pure recompute, or the immutable inference receipt a recorded model replays without re-calling its provider or tool. | A replay that does not reproduce the recorded decision stops the run, and a recorded module that cannot replay its own receipt is refused rather than quietly re-inferred. |
| Settlement | The resolved outcome binds the market identity and the decision run identity, with an effect identity only when an execution exists. Corrections append a new record. | An outcome that names another run, a repeated settlement that would credit a run twice, and a correction that rewrites history all fail closed. |
The verification method behind these boundaries — replay, coverage, deflation, and settlement checks — is set out on the verification page, and the kernel reference explains the typed contracts that enforce them.
Reach
What the product never reaches.
Five things the shipped product cannot contact, stated as product constraints: an effect exists only through an explicitly admitted adapter, and today’s adapter is a simulation.
A broker
No order, position, or account reach-through exists in the shipped adapter, and no capital path is contacted.
A sportsbook or an exchange
No wager, stake, or trade leaves the process. The effect receipt class cannot represent one.
A model or tool provider
Recorded provider and tool identity is lineage data with no execution privilege. Replay never re-invokes a provider or a tool.
Credentials
No credential is minted, and no secret value is printed. The door reports only whether the platform connection key is configured.
Custody
No funds, no accounts, no customer assets, and no counterparty reach-through. There is no payment path anywhere in the product.
Handling
How refused material is handled.
A refusal is the product working, and it has a shape: it happens early, it names itself, it leaves nothing half-written, and it is visible where it matters.
- 01A refusal happens before inference or before an effect, never after one: the earliest gate that can stop the run does.
- 02The refusal is named. An error line, an abstention reason, or a rejection reason tells you which boundary answered.
- 03No metric is printed from material that did not verify. A document that fails its schema, its field law, or its content seal is rejected before any score exists.
- 04No partial artefact is written. A refused run leaves no receipt and appends no record to the history file.
- 05Refusals that are observable are counted or recorded: refused wakes appear in the health document, and gate refusals appear in the receipt.
- 06Nothing is repaired by best effort. Interpreting an unverified document loosely is not a service this product offers.
Redaction
What is redacted, and what is never printed.
The surfaces here publish identities, digests, counts, and named failures. They publish no secret value, and the public pages describe shapes rather than payloads.
Health and boot output
The health document and the boot receipt line carry identities, digests, counts, and named failures. Nothing in them is a secret, and the boot summary is deliberately compact.
Evidence and strategy payloads
The public surfaces describe the shape and the identities, not the contents: a receipt names the sealed corpus digest rather than reproducing the corpus, and this site holds no customer data set.
Sessions and identity
The sign-in path stores only what the Identity service issues — subject, optional organization, optional display name, and expiry — sealed in a host-only session cookie. The trust page owns that description in full.
Reporting
Report a concern to [email protected].
Security reports go to a person, not to a form. Write to us if a claim on this site is wrong, if a boundary fails open, or if you find a path that reaches further than it should.
Reporting channel
The same address is published in this site’s security.txt document, which also carries the document’s expiry and its canonical location. That document states plainly that no bounty and no response-time promise is offered.
What to include
- The surface you were on: a route, a command, or the door.
- The steps you took and what you observed.
- The named error, abstention reason, or rejection reason, if one was shown.
- Whether a receipt was involved, and which lines changed.
No secret belongs in a report: the shipped paths hold none, and no diagnostic here requires one.
Read moreThe posture this model sits inside
The trust page owns what the product holds, the data question, and the reporting commitments. The verification page owns what would falsify each claim. This page does not repeat either.
A refusal you can act on.
Most security-relevant events here surface as a named refusal. The troubleshooting page maps each one to what to check, and says when the refusal is the correct outcome rather than a fault.