Technical Report
A technical account of the paired-hedge model, the control architecture, the evidence posture, and the remaining distance to a fully proof-closed live system.
Polyventure is an operator shell that trades a single, mathematically defined edge on Kalshi's binary event markets: the paired maker-entry hedge. It posts passive post-only orders on both sides of the same contract at prices whose sum, plus a conservative fee reserve, is strictly below the one-dollar settlement value, so that equal matched fills return a determinate, outcome-independent profit (Eqs. 1–2). This report documents the system as a control architecture built to preserve that guarantee at the venue boundary: deterministic discovery and ranking, constraint-shaped position sizing, a binary-scope fail-closed gate, a pre-submit guard stack, truthful broken-pair accounting, and a signed retained-evidence posture, together with the datapack, simulation, and replay surfaces that support offline calibration. The principal unresolved risk — one-sided fill exposure, where one leg fills and the hedge is broken — is analyzed explicitly, and the remaining distance to a fully proof-closed live system is enumerated as evidence-gated work items with a sequenced roadmap. The report omits real P&L figures and superseded implementation attempts except where a historical boundary explains a current invariant.
Tooling disclosure. This report and project were developed using a repository governance harness and AI-assisted coding/curation workflow engineered by Joe Waller and enabled through OpenAI and Anthropic tooling. These tools support development and documentation, including summarization and report drafting, and do not replace the author's judgment. Names such as CodeSentinel, ORACL, Calamum, and Polyventure appear as internal identifiers for governance, agent assistance, validation, and project-specific tooling.
Polyventure is an operator shell that trades a single, mathematically defined edge on Kalshi's binary event markets: the paired maker-entry hedge. It posts passive buy orders on both sides of the same contract — YES and NO — at prices whose sum, plus a fee reserve, is strictly below the settlement value of one dollar. When both legs fill in equal quantity, exactly one side settles to a dollar and the other to zero, so the pair returns a determinate, outcome-independent profit. The entire system exists to find those opportunities, size them, place both legs, and — above all — to refuse the trade whenever the guarantee cannot be honored.
The system is built around a narrow invariant: only matched YES/NO quantity carries the guaranteed hedge. Discovery, ranking, sizing, scope-checking, pre-submit guards, reconciliation, and evidence capture all exist to preserve that invariant at the boundary between local decision-making and the live venue. Lane selection, credentials, thresholds, and endpoints must be explicit; unresolved values rest the system in an inert offline or no-submit state instead of allowing silent substitution.
The principal unresolved risk is one-sided fill exposure. When one leg fills and the other does not, the hedge is broken and the position carries directional risk outside the theorem. Polyventure accounts for that state explicitly, but prevention remains proof-gated: the flow floor, positive survivor path, session loss cap, and broader evidence enforcement are the main distance-to-ideal items summarized in Section 13 and sequenced in Section 14.
This report explains the current system model, active control surfaces, figures, and proof gaps. It omits real P&L figures and does not enumerate superseded implementation attempts except where a historical boundary is necessary to explain a current invariant.
| Capability | State | Note |
|---|---|---|
| Guaranteed-hedge edge model | Operational | The theorem applies to equal matched YES/NO quantity. |
| Discovery, ranking, dynamic sizing | Operational | Deterministic and decimal-exact within the active market surface. |
| Binary-scope fail-closed gate | Operational | Event-family suitability is treated as a pre-submit proof obligation. |
| Final-set coverability guard | Operational | Fresh terminal orderbook check before sizing and pair-plan construction. |
| Flow-floor calibration (entry gate) | Open | Observation capture is built; separating threshold and positive survivor proof remain evidence-gated. |
| Settlement truth for broken pairs | Operational | One-sided exposure is surfaced as exposure, not flattened to zero. |
| Datapack extract / validate / canonical inventory | Partial | Evidence bundles, checksums, restore policies, identity gates, and append-only ledger exist; full load-hydration semantics remain a bounded gap. |
| Offline replay and synthetic augmentation | Operational | Retained flow-balance replay and non-authoritative synthetic fixtures support threshold stress testing without live orders. |
| Session cumulative-loss circuit breaker | Absent | Per-pair loss bounded; per-session loss is not. |
| Deficient-leg recovery | Partial | Canonical interim path caps the ahead leg and preserves the opposite repair order; amend-based repricing remains deferred. |
| Submit-handoff signature integrity | Proof open | Member-derived identity path is present; live advance past queued remains open. |
| Signed-evidence enforcement breadth | Partial | Sign/verify exist and fail closed; coverage not yet universal. |
The strategy is derived, not tuned. It follows from the settlement mechanics of a binary contract and one inequality.
A Kalshi binary market pays a YES contract one dollar if YES resolves and zero otherwise; a NO contract is its mirror. Buy one YES and one NO on the same market, in equal quantity, and the payout is deterministic — exactly one side settles to a dollar per matched pair, regardless of which outcome occurs. The only variable is what you paid to acquire the pair.
Let p_Y and p_N be the average fill prices for the YES and NO legs, q the matched contract count on each side, and F the combined fees. Cost to acquire is C = q(p_Y + p_N) + F; settlement payout is always P = q. The guaranteed net result is therefore:
Dividing the fees into a per-contract reserve f_r = F/q gives the single condition the whole system is built to enforce — the guaranteed-profit inequality:
This is why the strategy cannot be executed by crossing the spread. In a standard book the YES ask is implied by one minus the best NO bid, and vice versa, so an immediate taker pair costs 2 − b_Y − b_N, which almost always exceeds a dollar. The inequality can only be satisfied by posting passive maker orders at or below the resting bids and waiting to be filled. Polyventure is, at its core, a disciplined maker: it places post_only, good-till-canceled orders at target prices that satisfy the inequality after a conservative fee reserve, and it treats a fill as something earned, not taken.
The guarantee holds only on matched contracts. If YES fills and NO does not, there is no dollar-neutral payout — only a naked directional position. The inequality is necessary but not sufficient: it makes a filled pair profitable, but it says nothing about whether both legs will fill. That single gap between "priced to win" and "actually hedged" is the origin of every structural loss in the system, and Section 8 is devoted to it.
Because only matched contracts carry the guarantee, profit is computed strictly on the locked quantity q_L = min(q_Y, q_N), never on the larger of the two fills. The unmatched remainder q_U = |q_Y − q_N| is tracked separately as exposure, not profit:
This asymmetry — count the guarantee conservatively, count the exposure fully — is the accounting posture that keeps the system honest about what it actually holds. Broken-pair accounting is covered in Section 9; its unresolved prevention boundary is summarized in Section 13.
The discovery layer is a reducer. It starts with a broad live market surface and eliminates every candidate whose edge cannot be stated from current, authoritative data.
The first screen is time. Polyventure is only interested in markets close enough to produce near-term fills and settlements, but not so close that there is no operational room to observe, save, submit, cancel, reconcile, or recover. The market fetch therefore carries an explicit entry window rather than trusting whatever order the venue returns under a page limit. This sounds mundane, but it matters: if the system lets a stale or out-of-window market into ranking, the later math can be correct and the trade can still be wrong.
After the time screen, each candidate is normalized into a common contract shape: ticker, close time, outcome family, top-of-book prices, book depth where available, final-window trade flow where available, and the derived quantities used for edge and risk. The ranking formula is deliberately narrow. A candidate must first satisfy the paired-hedge inequality; then it is ordered by the value that actually belongs to the strategy: expected locked-pair edge under maker fills. Polyventure does not rank on a story about the underlying event. It ranks on whether the market is offering a mechanically hedgeable spread.
That primitive is intentionally incomplete by itself. A high edge can be a gift, but it can also be an empty book, a crossed representation bug, a non-binary event family, or a lopsided market where one side can fill and the other side cannot. The ranked list is therefore not an order list. It is a candidate list passed into scope checks, risk checks, and a final fresh-coverability pass. The architecture separates finding an apparent edge from earning permission to trade it.
The active money path intentionally uses a narrower market-data surface than the venue exposes. Candlesticks, batch orderbook endpoints, public trade streams, exchange status, and product-specific reference data can improve risk estimation, but they require endpoint-family validation, freshness contracts, and threshold policy before they can block or permit orders. This is a current gap, not an implementation detail; it is carried into the market-data breadth item in Section 13.
A variable that sounds financially plausible does not become a guard until it is tied to authoritative venue data and a measurable outcome boundary. The current report therefore distinguishes active guards from candidate research surfaces.
Polyventure's data science problem is not predicting the event winner. It is estimating whether a mathematically profitable paired entry is executable as a matched hedge under live market microstructure.
The in-repository data science report frames the project as an applied decision-science system: deterministic hedge mathematics, structured feature extraction, rule-based ranking, density-aware sizing, final coverability gates, and retained evidence for later threshold calibration. The most important empirical result is negative. Coarse fields such as top-of-book size, 24-hour volume, and open interest did not safely separate clean two-sided fills from one-sided exposure. That result pushes the system toward decision-boundary features: final-window per-side flow, live divergence, current orderbook shape, intended size, and seconds to close.
The retained modeling specification defines two row grains: candidate-decision rows and pair-outcome rows. Candidate rows preserve the state at each decision boundary: scan candidate, saved-set member, final coverability evaluated, final survivor, or final blocked no-order. Pair rows summarize the realized execution path: intended prices, filled quantities, locked quantity, unmatched quantity, terminal state, and available outcome labels.
| Scientific object | Examples | Use |
|---|---|---|
| Profitability features | YES bid, NO bid, gross edge, fee reserve, net edge | Determine whether a matched pair can be profitable. |
| Timing features | close time, seconds to close, entry-window eligibility | Separate operational feasibility from pure price math. |
| Microstructure features | best bids, depth within band, divergence | Describe the current tradable shape of the book. |
| Flow features | YES flow, NO flow, required floor, flow imbalance ratio | Estimate whether both maker legs have recent counterparty participation. |
| Outcome labels | both filled or locked, partial both, one-sided exposure, final block, no fill | Train, replay, or calibrate guards against explicit outcomes. |
The flow-balance replay work already extracts retained datasets without changing live behavior. A verified inventory found meaningful outcome evidence but a small flow-bearing terminal-gate sample; that is the right conclusion, not a weakness to hide. The current scientific posture is therefore: continue read-only collection, replay candidate thresholds offline, and promote a guard only when it reduces one-sided exposure without relying on synthetic-only evidence. This data limitation is reflected directly in the flow-floor and simulation-harness gaps in Section 13.
The retained dataset can already support offline replay and sensitivity checks, but the flow-bearing live sample is still too small for strong threshold claims. Polyventure should not present adaptive flow optimization as production-ready until the evidence window grows and the replay harness is validated against later outcomes.
Polyventure has a data-portability and simulation surface that is more mature than a simple export button. Datapacks freeze bounded runtime state into checksummed bundles, while the replay harness turns retained observations into non-live counterfactual experiments.
The datapack subsystem exists for three related purposes. First, it packages lane-scoped runtime and analytical state with a manifest, restore policy, checksums, and identity metadata. Second, it lets the application validate or rebind a bundle before admitting it to a canonical inventory. Third, it gives the operator a way to preserve or transfer a local evidence state without treating transient browser state as scientific truth. The current command surface includes export, validate, rebind, synthetic-refinement generation, canonical add, and canonical archive-remove operations.
The current datapack contract is strongest around extract, validation, canonical inventory, and retention. A canonical add must pass control-pair attestation, payload checksum validation, lane/key identity checks, containment checks, post-copy verification, and append a mutation-ledger record. A canonical remove archives rather than deletes and records the source-to-archive mapping. That is a meaningful evidence-governance surface.
The less mature boundary is load hydration. The active operator contract says load should hydrate selected system state from datapack payloads, and if target lane data exists, it should warn, offer extract-first preservation, then perform clear-before-load on confirmation. Datapack load is therefore not fully proof-closed: it is a current, bounded gap carried into Section 13.
| Datapack family | Classification | Scientific role |
|---|---|---|
| Runtime state | export then optional purge | Preserves lane-scoped pair plans, orders, fills, pair states, heartbeats, and runtime events as bounded evidence. |
| Analytical state | restore with revalidation | Preserves analysis snapshots but requires revalidation before operational use. |
| Candidate review history | history only | Maintains candidate-selection provenance without automatically authorizing a future submit. |
| Synthetic refinement fixtures | synthetic proof | Exercises renderer, score, and threshold-boundary behavior without becoming empirical authority. |
| Evidence references / session control | reference or excluded | Keeps non-portable or session-sensitive material outside payload authority. |
Polyventure supports two separate non-live evidence modes that should not be conflated. The older synthetic-refinement datapack generates deterministic proof fixtures such as sparse frontiers, crowded threshold elbows, and noisy threshold edge cases. Those fixtures are useful for renderer validation, score-shape checks, candidate-math display, and threshold-boundary explanation. They are not observations of counterparty behavior.
The newer flow-balance replay harness is closer to data science. It opens the runtime SQLite database read-only, extracts candidate decisions and pair outcomes, optionally enriches labels from authoritative transaction CSVs, writes a checksummed retained package, and runs deterministic guard sweeps. It can append synthetic fixtures, bootstrap rows, or perturbation rows, but the tool explicitly marks all such rows as non-authoritative and excludes them from threshold authority counts.
The monitoring, datapack, and replay surfaces form a practical scientific loop: observe a live or retained decision boundary, package it with checksums and provenance, replay candidate guards offline, and keep synthetic rows visibly outside empirical authority.
Recorded-data replay is counterfactual screening, not a fill simulator. It can estimate which historical decisions a proposed guard would have blocked or retained; it cannot reconstruct queue priority, exact maker-fill timing, or unavailable historical orderbook depth.
Sizing is a risk control, not just a profit multiplier. The correct size is the largest contract count that remains inside every explicit bound.
For a clean pair, the natural temptation is to size by the attractive edge: more contracts convert a small guaranteed spread into a larger result. Polyventure instead sizes from constraints. The candidate must clear available-funds truth, per-pair exposure caps, market liquidity, fee reserve, minimum-profit requirements, order precision, and the final set of candidates being submitted as a batch. If any of those inputs are missing or stale, the system does not invent a substitute.
Sizing belongs after final-set resolution. The system evaluates upstream survivors with fresh venue reads, resolves the actual final submit set, and only then constructs the persisted pair plan. That ordering keeps the size, the identity of the selected candidates, and the submitted order group in the same decision frame.
All money-path arithmetic is decimal-exact and expressed in the venue's domain units before conversion to the order payload. The distinction between YES prices and domain NO prices is preserved; complement prices may be useful for display, but the order rows retain the prices actually submitted. This matters because a one-cent representation error can turn a modeled maker edge into an invalid order, a rejected batch, or a false account of what happened after acceptance.
The sizing surface is operational for attended live use, with final-set authority and retained validation around the no-order boundary. The positive survivor path remains an empirical gate: the system needs a live candidate that clears every guard and advances into order placement under the current integrity contract. That gap is listed as positive survivor proof in Section 13 and sequenced first in Section 14.
The mature claim is "operational under attended controls with positive survivor proof open." It is not yet a fully empirical unattended claim.
The paired hedge only applies to a true binary pair. A market family that looks binary in one row can still be structurally non-binary at the event level.
The strategy assumes exactly two mutually exclusive settlement states: YES and NO. Threshold, range, ladder, multi-lane, and other event families can expose rows that resemble binary contracts while the event-level family contains more than two outcome paths or different mutual-exclusion semantics. A pair built on the wrong family is not a hedge; it is an accidental directional strategy wearing the hedge's clothes.
Polyventure therefore treats binary suitability as a fresh proof obligation. Before submit, the system checks the event family rather than relying only on the individual market row. Non-binary family observations may be cached for faster rejection, but that ledger is evidence, not the authority. The authority is the current venue readback and the explicit rule: if the family cannot be proved binary, the candidate is not actionable.
This gate is one of the clearest examples of the project's design discipline. The system does not try to infer missing structure from a ticker name, a UI label, or the presence of YES/NO fields. It asks the venue for the family shape and refuses to trade when the shape does not support the theorem.
A candidate earns permission to become an order only by passing a sequence of independently motivated gates. The gates are redundant by design because the failure modes are different.
The guard stack can be read as a contract between the math and the live venue. Each layer answers a specific question:
| Gate | Question answered | Failure posture |
|---|---|---|
| Mode and credential gate | Is the system explicitly in a live-authorized lane with required keys loaded? | Offline / inert. |
| Fresh funds gate | Is strict available-funds truth fresh enough to back submit decisions? | No submit; banner display may carry separate user-facing estimates. |
| Market lifecycle gate | Is the market still inside the actionable entry window? | Candidate expires or is cancelled. |
| Binary-scope gate | Does the event family support the paired-hedge theorem? | Reject and retain non-actionable evidence. |
| Maker-price gate | Do both proposed prices preserve the guaranteed-profit inequality after fees? | No order construction. |
| Terminal coverability gate | Do fresh orderbook and flow observations support the final set and size? | Block before pair-plan persistence. |
| Submit-handoff integrity gate | Does the saved set being submitted match the set the operator/automation selected? | Halt before order placement. |
The funds split is easy to misread in the UI. Strict money truth is a submit gate and must be fresh. The banner is an operator-facing estimate and may legitimately prioritize stability over immediate blanking. The system does not bind those two surfaces to the same staleness rule: a blank banner is annoying; stale strict funds on a live order is a money-path defect.
The terminal coverability guard is the current money-path boundary. It runs after upstream discovery and before final sizing and pair-plan construction. It performs fresh venue reads for upstream survivors, applies the static coverability logic, and persists evidence for every evaluated candidate. If all candidates fail, the correct behavior is not a degraded submit; it is no pair plan and no order.
The live no-order boundary has been observed: fresh sessions emitted terminal coverability evidence, resolved an empty final submit set, and created no pair plans or orders. That evidence supports the negative path. The positive path still needs a live market that clears the gate, after which order placement and downstream reconciliation can be observed under the current implementation.
Coverability is probabilistic because the strategy posts maker orders. It cannot force both legs to fill without crossing the spread, and crossing both legs destroys the edge. The best available lever is therefore not "pay more"; it is "select markets where both sides are actually trading in the final window." Polyventure captures per-side flow and depth at the terminal gate, including for blocked candidates, so the threshold can be tuned from evidence instead of taste.
Divergence remains useful as a structural guard, but it is not treated as the primary separator for one-sided exposure. Flow-floor calibration remains a distance-to-ideal item in Section 13.
The central risk boundary is simple: the model is outcome-neutral when both legs fill, and directional when only one does.
The hedge equation is a theorem about matched contracts, not a promise about execution. If one side fills while the other remains resting, cancels, or reaches settlement unfilled, the position is no longer neutral. Polyventure therefore treats one-sided exposure as a first-class state rather than a temporary display irregularity.
The relevant control rules are conceptual as much as technical:
The hard part is prevention. Truthful exposure accounting is necessary, but it does not by itself reduce broken-pair frequency. Aggregate liquidity fields and simple bid divergence are insufficient as standalone predictors. The active hypothesis is narrower: per-side final-window flow, measured from authoritative trades, is the most direct available evidence that both sides are actively tradable at the moment maker orders are posted. Its calibration is explicitly carried as an open gap in Section 13.
If the system wants a guaranteed hedge immediately, it must take liquidity on both sides. On a binary market, that turns the spread against the strategy. The same spread that creates maker edge becomes the cost of instant cover. That is why Polyventure cannot eliminate one-sided fills by simply "being safer" at submit time. Safety requires selecting better maker opportunities, sizing them smaller, changing timing policy, cancelling aggressively, or accepting that some opportunities should not be traded.
The remaining question is not whether one-sided exposure exists; that is settled. The question is which observable pre-submit variables reduce its rate enough to make unattended operation acceptable. Flow-floor calibration is the next experiment because it is directly tied to two-sided participation rather than to stale or aggregate liquidity proxies.
The state machine exists to prevent ambiguous money states. A pair is discovered, saved, submitted, locked, repaired, settled, cancelled, expired, or errored; it is never allowed to be "sort of" live.
The ideal lifecycle is short:
The real lifecycle needs more branches because live markets do not cooperate. Orders can be rejected, one leg can partially fill, a market can close, a saved set can expire, a websocket can reconnect, or the operator can stop automation mid-cycle. The state machine's job is to make each branch explicit and terminal where appropriate.
The lifecycle is shared by persistence, automation, and the operator-facing deck. A saved set that expires, retires, or terminalizes must leave the active surfaces consistently; otherwise the human interface and the backend scheduler can reason from different state. Remaining display-coherence follow-up is tracked in the UI section.
Stop automation is modeled as a scheduler-owned transition. The backend scheduler owns retry, cadence, eligibility, and priority; stop requests must cancel, terminalize, or reconcile the relevant candidates and return the system to a known state. The design goal is that a browser refresh, reconnect, or delayed UI surface cannot create an independent source of lifecycle authority.
The ideal Polyventure is not a button-click script. It is a supervised control loop whose backend owns state and whose UI reports that state without becoming the source of truth.
The automation loop is organized around a backend scheduler, explicit modes, fail-closed submit gates, retained runtime events, monitored sessions, and an operator deck for review and intervention. The scheduler decides when to scan, when to retry, when submit priority supersedes scan cadence, and when a stop or expiry event should unwind the deck. Browser timers and card surfaces are presentation and eligibility signals; they are not independent money-path authorities. The live monitoring script deserves separate treatment because it is the system's retained empirical witness; Appendix C describes what it captures and why DOM capture remains experimental.
The operator shell remains essential. Polyventure is live-authorized only in a small, attended posture; it is not represented as an unattended money machine. The shell exposes the candidate set, strict money state, automation state, stage columns, terminal rows, and diagnostics. The technical requirement is that these surfaces agree with backend state; a correct strategy with a misleading control deck is still unsafe.
The browser shell is not just decoration over a backend process. It is the operator's route into lane posture, evidence, data management, and safety controls. Those surfaces matter scientifically because many current gaps are disagreements between what the backend knows, what the operator sees, and what a retained artifact can later prove.
| Surface | Current role | Boundary |
|---|---|---|
| Workflow controls | Find candidates, refresh shell, cancel non-terminal pairs, and inspect next-step posture. | Can request backend actions; cannot override submit gates. |
| DATA controls | Detect, select, load, and extract datapacks. | Extract/validate/canonical controls are stronger than load hydration, which remains a gap. |
| Key and credential posture | Shows key-file reference, loaded credential state, and readiness. | Display is not sufficient for submit; strict gate truth remains backend-owned. |
| Runtime settings | Displays threshold and sizing parameters, with bounded session overlays. | Parameter display drift remains a tracked display-coherence risk. |
| Websocket and context posture | Separates sandbox/live routes, session identity, and reconnection state. | Reconnect evidence must reconcile against runtime events and DB state. |
| Evidence browser | Surfaces retained runs, local reports, and aggregate evidence. | Convenience surface only; retained artifacts remain the audit authority. |
Automation is allowed to reduce operator workload, not operator awareness. The system should move faster than a human can click, but it should not create a state the human cannot audit.
Polyventure's safety model depends on evidence because many failures are temporal. A snapshot after the fact is often too late to prove what the system knew at submit time.
The system keeps retained evidence at several levels: test runs, runtime events, monitor records, signed or checksummed records, design plans, implementation records, and state-contract updates. In this report, that material functions as audit substrate rather than narrative sequence. The main question is whether a claim can be traced to an observation made before the relevant money-path transition.
The signing posture is partial but real. A signing key is provisioned, sign and verify paths exist, and unsigned records fail closed rather than forging trust. The remaining work is coverage and enforcement breadth: every mandatory evidence site needs to participate in the same trust contract, and the policy snapshot used for verification needs a complete definition. Until that breadth is closed, the correct status is partial, not absent and not complete.
Datapacks extend that posture from individual records to portable state bundles. A useful bundle is not merely a folder of JSON; it is an artifact with a manifest, restore policy, payload checksums, lane/key identity metadata, and canonical inventory history. The current implementation proves meaningful extract and attestation discipline, but the load-hydration path still needs the same level of proof before it should be treated as an operational restore authority.
The saved set, its member list, its persisted signature, and the submit gate's readback must refer to the same ordered candidate set. If those surfaces disagree, no order should be placed. The member-derived signature path satisfies the local identity contract.
A fail-closed system sometimes blocks trades that might have been fine. That is acceptable. The unacceptable alternative is placing live orders when identity, funds, scope, price, or evidence freshness is unresolved.
The idealized Polyventure is clear: a live event-market hedge operator that only trades when the theorem, the venue state, and the control surfaces all agree. The current system is close in architecture and not yet closed in proof.
| Gap | Scientific meaning | Current posture |
|---|---|---|
| Flow-floor calibration | The system can observe per-side final-window flow, but the threshold that separates acceptable from unsafe opportunities is not yet empirically established. | Evidence-gated; collect passed and blocked candidates, then set the floor. |
| Positive survivor proof | The terminal gate has proved it can block bad final sets; it still needs live evidence of a good set advancing through placement under the current code. | Open empirical gate. |
| Session cumulative-loss cap | Per-pair exposure can be bounded while the session as a whole still accumulates multiple small losses. | Absent; should precede unattended operation. |
| Signed-evidence breadth | Trust machinery exists, but not every mandatory evidence record is covered by the same enforcement contract. | Partial coverage. |
| Datapack load hydration | Datapack extract, validation, canonical inventory, and archive-ledger controls exist; loading a datapack as runtime state needs proof of clear-before-load, overwrite warning, hydration, and post-load verification. | Bounded implementation gap. |
| Synthetic-data authority boundary | Synthetic datapacks and replay augmentation are useful for renderer, schema, and guard-stress testing, but they cannot prove live microstructure thresholds. | Operational as non-authoritative evidence only. |
| Market-data breadth | The venue offers more potentially useful data than the current money path consumes. | Audit ready; implementation requires schema/freshness contracts and thresholds. |
| DOM capture viability | Hydrated browser observation would help distinguish rendered UI state from backend payload truth, but the current capture path can cause severe projection lag. | Experimental; monitor backend and DB evidence remain authoritative. |
| Replay-to-live ratio enforcement | The offline replay harness can evaluate candidate flow-balance thresholds, but the live ratio guard and optimizer application path must be separately authorized and validated before they affect submit decisions. | Replay operational; live enforcement not yet proof-closed. |
The most important distinction is between truthfulness and profitability. Polyventure's current truth controls record exposure, refuse non-binary scope, block stale final sets, and halt on identity mismatch. Profitability at unattended scale depends on the next layer: reducing one-sided fills enough that the positive locked-pair edge dominates under realistic flow conditions and explicit loss caps. That claim should not be made until the evidence supports it.
The shortest credible path is not to add more cleverness. It is to close the remaining proof gates in the order that protects money first.
Run a monitored live session under the member-derived saved-set identity path and prove that a valid saved set can advance past queued to the order-placement boundary. If it halts, classify the halt by the gate that fired and do not bypass it. This phase establishes the live boundary under the current integrity contract.
Use terminal coverability events that retain per-side flow, participation-floor inputs, and depth summaries. Capture both passed and blocked candidates, then set the flow floor where it separates clean both-sided fills from one-sided exposure. The threshold should be operator-approved and evidence-backed; it should not be hand-picked because it "feels conservative."
Before wider unattended operation, introduce a cumulative session loss circuit breaker. The paired model bounds each intended trade, but repeated one-sided exposures can still compound. A session cap is the portfolio-level complement to per-pair controls.
Admit richer venue data only after endpoint family, freshness, schema, and threshold contracts are written and validated. Candlesticks, public trade streams, batch orderbooks, and exchange-status signals may all help, but they must enter as measured controls, not as post-hoc explanations.
Promote datapack load from a partially specified capability to a proof-closed restore path: detect existing target-lane data, warn before destructive overwrite, offer extract-first preservation, clear before load, hydrate from payloads, and verify the resulting rows, families, lane identity, and checksums. In parallel, keep replay outputs separated from runtime configuration until the live flow-ratio guard is explicitly authorized and validated.
The simulation and replay harness exists; the next maturity step is using enough recorded authoritative data to tune thresholds inside an operator-defined cage. The adaptive system should be able to choose "do not trade" as a successful outcome. The goal is not more activity; it is a lower rate of broken pairs per unit of captured edge.
Polyventure's ideal form is scientifically coherent: a fail-closed paired-hedge operator that treats the hedge equation as a theorem and every live venue interaction as an evidence problem. It should still be described as attended and proof-gated until flow calibration, session loss caps, and signed-evidence breadth are closed.
The appendices provide terminology, evidence classes, and internal provenance without interrupting the main technical account.
| Term | Meaning in this report |
|---|---|
| Matched quantity | The minimum of the filled YES and NO counts. Only this quantity carries the outcome-independent hedge. |
| Unmatched exposure | The absolute difference between filled YES and NO counts. This is directional risk until recovered, frozen, or settled. |
| Final-window flow | Per-side traded quantity near the market close. It is the primary candidate input for flow-floor calibration. |
| Terminal coverability | The last fresh venue-state check before final sizing and pair-plan construction. |
| Strict money truth | The funds state allowed to gate submit decisions. It is separate from any display-oriented banner estimate. |
| Submit handoff | The identity transition from saved candidate set to order-placement candidate set. |
| Datapack | A bounded, checksummed state bundle with manifest, restore policy, payload families, lane/key identity, and canonical inventory controls. |
| Replay harness | An offline analytical tool that evaluates proposed guard thresholds against retained empirical rows without mutating live state. |
| Synthetic fixture | A deterministic non-authoritative row or datapack family used to stress schemas, visuals, or threshold boundaries; it cannot close empirical safety gates. |
| Evidence class | Purpose | Current role |
|---|---|---|
| Unit / service tests | Prove deterministic math, state transitions, and guard behavior under controlled inputs. | Required for local contract confidence. |
| Sandbox / simulation | Exercise non-live integrations or replay recorded data without placing live orders. | Required for adaptive threshold work where live proof would be unsafe or unavailable. |
| Monitored live session | Observe actual venue timing, submit behavior, state projection, and UI/backend agreement. | Required for positive survivor proof and flow-floor calibration. |
| Runtime events | Retain time-ordered gate and transition evidence near the money boundary. | Primary source for coverability, submit handoff, and reconciliation evidence. |
| Datapack artifacts | Preserve lane-scoped state with manifest, restore policy, checksums, and identity controls. | Useful for evidence portability; load hydration proof remains bounded work. |
| Offline replay packages | Evaluate threshold candidates against retained rows without changing live behavior. | Operational for flow-balance analysis; synthetic rows remain excluded from authority counts. |
| Signed / checksummed records | Bind evidence identity and detect mutation or missing trust context. | Partially deployed; breadth remains open. |
The monitoring script is a substantive part of the system, not a convenience wrapper. It is the empirical witness used to observe live sessions without granting the browser UI authority over money-path truth. Its core value is that it can assemble backend bootstrap state, runtime events, database summaries, scheduler fields, websocket posture, candidate-surface counts, findings, packet hashes, and cross-run time-series metrics into retained artifacts that can be audited after the session.
| Monitoring lane | Status | Scientific meaning |
|---|---|---|
| Backend payload and scheduler fields | Operational | Primary source for scan, retry, submit lease, timer, and inactivity-guard evidence. |
| Runtime database cross-checks | Operational | Counts and transitions are checked against retained DB state rather than UI impressions. |
| Time-series ledger | Operational | Tracks findings and metric changes across monitor packets without making causal claims. |
| DOM capture | Not viable yet | Still buggy, can cause debilitating UI projection lag, and requires further development before it can be trusted as a routine proof surface. |
DOM capture should remain experimental. It is intended to distinguish backend payload agreement from rendered browser agreement, but the current mechanism is not viable for routine proof because it can perturb the very UI projection it tries to observe. Until it is isolated, throttled, and proven not to create material lag, backend payloads and database evidence remain the authoritative monitor surfaces.
The compliance posture is summarized from retained Polyventure compliance artifacts, not from a new legal review. It should be read as an engineering compliance account: what assumptions the system is built around, which agreement constraints the implementation is designed to respect, and which re-review triggers remain open. It is not legal advice and should not be treated as a current statement of Kalshi's live terms beyond the dated artifacts named below.
The retained June 14, 2026 live-lane review records a go decision for Polyventure live-lane submission under an own-account, single-operator posture. The May 8, 2026 review remains the broader mode-plan anchor for offline, sandbox, and live operation.
| Compliance artifact | Scope | Report interpretation |
|---|---|---|
| Mode-plan compliance review, 2026-05-08 | Reviewed the offline, sandbox, and live plan against pasted local agreement captures. | Polyventure is framed as an operator-owned trading workflow, not a data-harvesting, benchmarking, redistribution, or third-party signal product. |
| Live-lane compliance review, 2026-06-14 | Re-reviewed live-lane activation against an updated member agreement and regulatory status note. | Live lane was cleared for the operator's own trading posture; no new blocker was identified. |
| Developer agreement local capture, 2026-05-07 | API-use constraints, rate-limit posture, account security, data-use limits, and prohibited uses. | Constrains Polyventure retention and analytics to the operator's own trading purpose. |
| Member agreement local capture, 2026-05-07 | Member obligations, event-contract risk, security responsibility, jurisdictional restrictions, and CFTC/DCM context. | Supports the single-account, single-operator, risk-aware live posture. |
| Shop terms local capture, 2026-05-07 | Merchandise/shop terms preserved as source material. | Not treated as governing the trading/API posture. |
The governing posture across both compliance reviews is narrow and affirmative: Polyventure exists to facilitate the operator's own Kalshi trading. The application therefore keeps Kalshi-derived data internal, bounded, and purpose-tied to trading facilitation, auditability, readiness review, and safety analysis. This posture is consistent with the application's architecture: datapacks, replay datasets, monitoring packets, and retained events are internal evidence surfaces, not externally sold data products.
| Constraint | Polyventure control | Current status |
|---|---|---|
| Own-trading purpose | Single-operator workflow; no third-party trading facilitation or signal delivery. | Aligned |
| Bounded data retention | Runtime DB, datapacks, monitor packets, and replay datasets are retained for internal trading, safety, and audit purposes. | Aligned |
| No redistribution posture | Kalshi-derived data and analytics remain inside the operator project context. | Aligned |
| No benchmarking posture | Monitoring focuses on Polyventure safety, state truth, retry behavior, and operator awareness, not comparative Kalshi service benchmarking. | Aligned |
| Secure authorized access | Credentials are environment/local-secret based; no hardcoded keys; live orders require explicit lane and credential posture. | Aligned |
| Rate-limit and API-responsibility posture | Automation is bounded, fail-closed, and monitored; retry/submit loops are treated as evidence-gated engineering surfaces. | Ongoing control |
| Member and jurisdiction obligations | Live-lane clearance assumes the operator remains an eligible US-based own-account user and complies with Kalshi member obligations. | Operator duty |
| Updated agreement review | Developer agreement was not re-reviewed in the June 14 artifact because no updated version was provided. | Re-review trigger |
The compliance significance of the datapack and replay surfaces is that they remain internal evidence and safety tools. Synthetic refinement datapacks and flow-balance replay packages do not create a public dataset, third-party signal service, or exchange-performance benchmark. They support the same operator-owned trading workflow described throughout this report.
Compliance should be re-reviewed before broadening Polyventure beyond single-operator own-account use, sharing Kalshi-derived data or analytics externally, adding third-party execution, using monitoring as service benchmarking, or treating a newer Kalshi developer/member agreement as operative.
The report body names concepts rather than development artifacts. The internal artifacts below are the provenance surfaces for maintainers who need to trace the claims.
| Figure | Purpose | Section |
|---|---|---|
| Figure 1 | High-level architecture: venue data, discovery, gates, submit path, deck, and evidence. | Executive summary |
| Figure 2 | Payoff distinction between matched hedge and one-sided exposure. | Model |
| Figure 3 | Data-science pipeline from venue observation to retained replay. | Data science |
| Figure 4 | Flow-balance replay region and threshold interpretation. | Data science |
| Figure 5 | Datapack evidence lifecycle from lane state to canonical inventory and archive. | Datapacks |
| Figure 6 | Simulation authority boundary between empirical rows and synthetic stress fixtures. | Datapacks |
| Figure 7A/B | Flow floor and divergence cap as distinct risk controls. | Guard stack |
| Figure 8 | Scheduler-owned automation transition model and branch labeling. | Lifecycle |
| Figure 9 | Monitoring evidence topology and DOM-capture boundary. | Appendix C |
References are limited to sources needed to understand the system's domain assumptions and technical contracts.
