X12 Capital Limited — Portfolio Management System

One section per workspace. Each names the server read the pages depend on and the command a decision goes through. The "?" in the page header opens the section for the page you are on. Confirm the fund, the date and the environment (production or sandbox) before relying on a figure; a value the server did not return is shown as unavailable, never as zero. The funds in the registry are DAA, Silea (SL), OMPA and the private credit fund PCF; a page that does not apply to the selected fund says so instead of showing another fund's numbers.

Operations — what needs me, what is due, what has completed

• Today reads the open cases and the last verified outputs from the server (the operations inbox and the close register). It is a queue, not a status page: each row states the fund, date, reason, owner, age, evidence and next action.
• Inbox is the case register (pms_ops_inbox, refreshed by pms_ops_inbox_refresh). A source that could not be read is itself a case; a kind with nothing open is stated as not due. A case closes when its condition no longer holds and keeps its outcome.
• Approvals are cases whose next action is an approval; approving runs the command with the rationale and evidence recorded in the operations log.
• Reconciliation shows cash and position breaks as cases with their evidence and tolerances. A break is resolved by tracing it to source, never by a plug; the reconciliation is either zero or it is broken. Force-match and typed external balances are this browser's working papers, not the book.
• Daily Close is scheduled (Temporal, then the daily-close function). One claimed run per fund, date and mode (close_intent); the result is versioned and its ledger, NAV and status must agree before completion is shown. Running it from this page is an exception: investigate the existing run first and give the reason.
• Settlements and Confirmations (DAA OTC) track each leg's expected and actual amounts, residual, due time and evidence; confirmation preparation and delivery are separate statuses. A partial receipt never implies full settlement.
• Attestations are human sign-offs kept in this browser's working state; a provable check is a server assertion on the System page, not an attestation.
• Automation outcomes lists scheduled runs with their business outcome; a run that finished green with an unresolved break stays open as a case.

Portfolio — what we own, how it changed, what drove performance

• The book is one server read for the selected fund, date and basis (pms-positions, pms-financials); every figure carries its source and time. Positions, futures (prompt, lot, exchange, gross legs, margin for Silea and OMPA), performance, NAV history and pricing status are lenses on that read, never a second engine.
• Trades come first from imported fills. A manual booking is an exception entry through the same trade command and validation (pms_book_trade); amendments and cancellations produce linked corrections, not deletions. A roll is a pair of trades.
• Pricing status shows observations and approved close marks with their sources and staleness; the valuation rules that govern them are approved reference records.
• PCF: the facilities register (drawdowns, receipts, covenants, collateral, ECL, distributions) is entered through the facility command and read on the Facilities overlay of the overview.

Cash — what is available and what must move

• Balances and movements come from the cash ledger and imported bank statements; actual cash, expected cash and reconciled evidence are kept distinct. There is no manual cash transaction: a correction is a journal through Accounting → Journals.
• The account register on this page is the governed register (v_reference_records): each approved account shows whether its instruction is verified. An unverified instruction is not usable for payment until evidence is recorded under Reference Data.

Accounting — what is posted, reconciled and certified

• Financial statements and the Ledger are server reads of the posted book (pms-financials; the ledger pages on the server). Posted versus live basis is stated on the page.
• Journals is the correction path: a manual journal goes through the journal command with the same validation and period guard as every automated posting. The server refuses a write into a period whose close is COMPLETE.
• NAV and close shows official NAV and close versions; capital movements are entered under Investors. Close periods holds this browser's working lock and the year-end and batch close, which run on the server.
• Administrator reconciliation keeps a working record beside the signed-off reconciliation of record (nav_reconciliation, sign-off through its command). Ascent is the official books and records: the shadow is amended to Ascent, never the reverse.
• Accrual schedules are calculated by the close from the approved, date-effective fee rules; when no rule is effective for a fund and date the close halts and says which rule is missing. A manual accrual is an exception entry through the journal command.

Investors — committed, due, paid, allocated

• The investor register, capital activity and statements read the server registry (B6): commitment, call, receipt, share issue and redemption are distinct events, each through its own command; a PCF receipt is allocated and allotted through the capital lifecycle commands.
• Class and series states what equalisation is implemented; series accounting and per-investor high-water marks are a COO policy decision before they are built, and the accrual refuses to net credits until then.

Risk — what is breached or unmeasurable

• Exposure is computed on the server over the canonical book against the versioned policy; a metric that cannot be measured is shown as unavailable, never as within limit.
• Limits are configuration written directly to risk_config from this page; they are not a governed reference record.
• Scenarios is non-posting analysis over the same book with its assumptions stated.

Reference Data — the approved facts and rules

• Accounts and SSIs, counterparties, wallets, instruments, fee rules and valuation rules are effective-dated approved versions: propose (with a source reference), verify (evidence for a material change), approve (a second person for a material change). The approved version keeps serving until the change is approved; a pending material change withdraws a counterparty's dealing approval until it is verified or rejected, and the page says why.
• Bank instructions carried over from the old static register are approved but unverified until a verification is recorded; the inbox raises a case for each.
• Custodians are reference text, not a governed record type.

System — are services and controls working, with what evidence

• Audit reads the server operations log and the accounting hash chain (pms_audit_events) by fund, entity, actor and period, with the chain verification and its time. Local browser activity is a separate panel and never the audit record.
• Integrity and recovery reads the server assertions (pms_integrity_checks) with an explicit state each (passed, failed, stale, unavailable, not applicable) and the stated coverage; the backup manifests, restore rehearsals and releases are records written by the service runtime (daily-backup, the restore-rehearsal workflow, the deploy workflow). A missing backup or rehearsal is a failed assertion and a case.
• Releases lists what the deploy workflow recorded; the sidebar footer shows the latest.
• Access: what you can do is the capability set the server declares for your role and the funds you are entitled to; a control you cannot use is disabled with the reason, and signing out or switching account clears everything loaded.

When something is missing