> ## Documentation Index > Fetch the complete documentation index at: https://docs.axient.app/llms.txt > Use this file to discover all available pages before exploring further. # Architecture > A reference architecture for risk, ledger, execution, and lifecycle control. # Built above the venue, with explicit boundaries. Axient is designed around a clear operating boundary. The prediction venue remains the source of markets, outcome assets, matching, and final settlement. Axient coordinates risk, accounting, execution, and lifecycle actions around a connected position. ## Layers ### Prediction venue Creates the market, matches orders, holds the underlying outcome assets, provides the resolution path, and performs final settlement through its own rails. ### Axient margin layer Calculates risk from executable venue prices, maintains isolated collateral and debt, applies lifecycle controls, and coordinates debt-clearing actions before finality. ### User position The user receives a clear long or short exposure view. When leverage ends, residual tokens are fully funded and wait for the venue’s final resolution. ## Reference services * **Venue adapter** normalizes market state, order and balance information, execution results, and settlement status. * **Risk engine** computes executable value, health, position limits, partial-liquidation conditions, and hard-flat timing. * **Double-entry ledger** records cash, debt, token balances, fees, and realized sale proceeds as separate state. * **Execution service** submits bounded orders and reports their confirmed settlement state. * **Lifecycle worker** manages reduce-only, hard-flat, settlement, oracle, and redemption jobs. * **Signer or controlled subaccount** authorizes only typed, constraint-checked actions. * **Reconciliation worker** compares internal records with the venue before decisions use the data. ## Design principle Margin must end before the underlying market enters a period where it can close, delay, dispute, void, or resolve. This keeps any final outcome position separate from active borrowed exposure. For live adverse deleveraging, the implementation needs a control path that can execute permitted actions. A fully user-controlled external wallet cannot be assumed to sign at the required moment.