Valuation, pricing, reserving & capital

A reserve range you can reproduce to the digit.

Chain ladder, Bornhuetter-Ferguson, Cape Cod and ELR on one triangle, with Munich reconciling paid against incurred and a seeded bootstrap for the range — behind a gate that refuses to run production work on uncertified data, and evidence packs sealed so a reviewer can verify them without us.

app.aegisnow.ai/analytics

Actuarial Workspace

Live

Gated

11

Sections

18

Repro.

100%

Methods

6

Actual-vs-expected, last 12 periods

Trend

AegisNow Actuarial Platform runs reserving, valuation, capital and pricing as engines rather than spreadsheets. Four deterministic reserving methods run against one triangle, and the range comes from Mack’s analytic standard error and a residual bootstrap that is seeded — the same triangle and seed reproduce the same percentiles exactly. IFRS 17 measures under GMM, VFA and PAA with a CSM that rolls forward rather than being restated. Solvency II SCR aggregates by module through the prescribed correlation structure, and NAIC RBC runs on the same book. No production run may use uncertified source data unless it is explicitly labelled exploratory, and an exploratory run can never be published. Assumptions are versioned sets a run is pinned to by identifier, and a completed run seals into an eighteen-section evidence pack whose digest anyone holding it can verify.

0 production runson uncertified data — refused at the dispatch point, not reviewed after

Illustrative outcome. We will map Actuarial Platform to your own data, frameworks and targets in a working demo.

Why teams choose it

The case for Actuarial Platform

Every assumption versioned, every run reproducible, every sign-off logged — and uncertified data refused.

Uncertified data does not reach a production number

Certification is a named person's decision, not a quality score. An override is matched on exact purpose, so a waiver for a pricing study cannot open a reserve close.

"Exploratory" costs something

An exploratory run may read uncertified data and can never be published or approved — enforced by a database trigger, not by the route that sets the label.

A stochastic range you can reproduce

The bootstrap is seeded: the same triangle and seed give the same percentiles to the digit. A range you cannot reproduce is not evidence.

Paid and incurred must agree

Chain ladder on each triangle separately gives one book two ultimates. Munich uses the correlation between them and reports the gap that remains rather than averaging it away.

A pack you can check without us

The seal is a SHA-256 digest over canonical content, computed in portable code — so an auditor holding the pack verifies it themselves rather than taking our word for it.

The limitations section writes itself

Built from what the run could not establish — steps that found no data, had no executor, or were held. The section a reviewer needs most is the one nobody gets to compose.

The CSM rolls forward, not restated

Opening, interest, new business, fulfilment changes, release, closing — so "why did the CSM move" has a line-by-line answer an auditor can follow.

A run knows its basis

Assumptions are versioned sets recorded by identifier, and the approver cannot be the author — the platform rejects it rather than warning.

Inside the module

Capabilities that ship on day one

Every capability runs on the shared data fabric, the governed Cortex brain and the evidence ledger — so Actuarial Platform compounds with the rest of the platform.

Capability 01

Loss reserving with four methods and a reproducible bootstrap

Chain ladder, Bornhuetter-Ferguson, Cape Cod and ELR on one triangle, with Mack and a seeded bootstrap for the range.

One triangle, four deterministic methods. Chain ladder develops the paid or reported triangle on volume-weighted link ratios; Bornhuetter-Ferguson blends the development estimate with an a-priori loss ratio by the proportion still undeveloped; Cape Cod derives that a-priori from the data itself rather than taking it as an input; and the expected-loss-ratio method holds it fixed. Running them side by side is the point — the spread between them is the actuary's first read on how much the answer depends on the method.

The range comes from two stochastic methods with different assumptions. Mack gives an analytic standard error on the chain-ladder estimate without simulating anything. The bootstrap resamples residuals to build a full predictive distribution, and it is SEEDED — the same triangle and the same seed reproduce the same percentiles exactly. A stochastic reserve range you cannot reproduce is not evidence, and reproducibility here is a property of the implementation rather than a process someone follows.

Tail development is fitted rather than assumed: a tail factor is estimated from the observed link ratios and applied beyond the triangle, so the ultimate does not quietly stop at the last development period the data happens to reach.

Paid and incurred are reconciled rather than selected between. Run classical chain ladder on each triangle in isolation and one book has two ultimates — the reserve then depends on which triangle somebody chose. Munich chain ladder uses the correlation between them, informing each triangle by the other's residuals so the two estimates converge instead of being averaged by hand and called a selection. It narrows the gap and does not close it, and the residual gap is reported: a method producing exact agreement would be hiding the disagreement rather than resolving it. Where the fitted lambdas are near zero Munich collapses back to plain chain ladder, which is the engine saying the method has nothing to add here.

Segment experience is believed in proportion to its exposure. Bühlmann-Straub credibility weights a segment's own loss ratio against the portfolio mean, so a small book cannot price itself on three volatile years — a segment swinging by a factor of four between years is telling you about its size rather than its risk. The weight is applied whether or not the answer it produces is the one the segment's owner wanted.

What it does

  • Run chain ladder, Bornhuetter-Ferguson, Cape Cod and ELR against the same triangle.
  • Derive the Cape Cod a-priori loss ratio from the triangle rather than accepting it as an input.
  • Produce an analytic standard error via Mack without simulation.
  • Build a predictive distribution by residual bootstrap, seeded so the same inputs reproduce the same percentiles.
  • Bound the bootstrap between 50 and 5,000 iterations, defaulting to 500.
  • Fit a tail factor from observed link ratios and apply it beyond the triangle.
  • Return percentiles from the fitted distribution rather than a point estimate alone.
  • Reconcile paid and incurred ultimates with Munich chain ladder, reporting the gap that remains.
  • Collapse Munich back to chain ladder where the fitted lambdas carry no signal.
  • Weight a segment's own experience against the portfolio mean by Bühlmann-Straub credibility.
  • Leave the lower-right of a triangle empty where it has not developed rather than filling it with zeros.

Implements

  • Chain ladder, Bornhuetter-Ferguson, Cape Cod, expected loss ratio
  • Mack analytic standard error
  • Residual bootstrap with fixed seed
  • Fitted tail factor
  • Munich chain ladder (paid / incurred reconciliation)
  • Bühlmann-Straub credibility

See it in the product

Run a reserving job twice with the same seed: the percentiles are identical to the digit. Change the seed and the distribution moves — which is what tells you the range is simulated rather than stored.

Capability 02

IFRS 17 measurement and CSM roll-forward

GMM, VFA and PAA with a contractual service margin that rolls forward rather than being restated.

IFRS 17 is implemented as measurement models rather than a disclosure template laid over existing numbers. The general measurement model, the variable fee approach for contracts with direct participation features, and the premium allocation approach for short-duration business each compute their own liability, and which applies is a property of the portfolio rather than a reporting choice made later.

The contractual service margin rolls forward: opening balance, interest accreted, new business, changes in fulfilment cash flows relating to future service, release for services provided in the period, closing balance. Rolling forward rather than recomputing is what makes period-on-period movement explicable — an auditor asks why the CSM moved, and a roll-forward answers it line by line where a restatement does not.

The risk adjustment for non-financial risk sits alongside the fulfilment cash flows, and the loss component on onerous contracts is tracked separately from the CSM, because a group that is onerous does not have a CSM to release.

What it does

  • Measure under GMM, VFA and PAA according to the portfolio rather than a reporting preference.
  • Roll the CSM forward through interest, new business, fulfilment-cash-flow changes and release.
  • Hold the risk adjustment for non-financial risk alongside fulfilment cash flows.
  • Track the loss component on onerous groups separately from the CSM.

Implements

  • IFRS 17 general measurement model (GMM)
  • Variable fee approach (VFA)
  • Premium allocation approach (PAA)
  • CSM roll-forward and loss component

See it in the product

Open a CSM roll-forward: opening, interest, new business, fulfilment changes, release and closing are shown as movements, so the period-on-period question has a line-by-line answer.

Capability 03

Solvency II SCR and NAIC RBC

Regulatory capital computed on both regimes from the same book.

The solvency capital requirement is computed by module — market, life, non-life, health, counterparty default and operational — and aggregated through the prescribed correlation structure rather than summed. Aggregation matters more than any single module: summing SCRs ignores diversification and overstates the requirement, which is why the correlation matrix is part of the calculation rather than a footnote.

Lapse risk is computed as the worst of mass lapse, permanent increase and permanent decrease, which is the shape the standard formula actually prescribes — the worst case rather than a central estimate.

NAIC risk-based capital runs on the same book for US entities, so a group operating under both regimes reads two regulatory answers from one set of figures rather than maintaining two data preparations that drift.

What it does

  • Compute SCR by module and aggregate through the prescribed correlation structure.
  • Take lapse risk as the worst of mass lapse, permanent increase and permanent decrease.
  • Compute NAIC risk-based capital on the same underlying book.
  • Keep both regulatory views derived from one set of figures rather than two preparations.

Implements

  • Solvency II standard formula SCR
  • Modular aggregation with correlation
  • NAIC risk-based capital

See it in the product

Run the SCR and check the aggregation: the total is below the sum of its modules, because the correlation structure is applied rather than the parts added.

Capability 04

Mortality, lapse and experience studies

Actual-versus-expected against real tables, with credibility applied rather than assumed.

Mortality runs from real tables with interpolation between age nodes and separate smoker and non-smoker bases, so a rate at an intermediate age is derived rather than rounded to the nearest published row. Table ratings and flat extras apply on top, which is the structure a life pricing or valuation basis actually uses.

Experience studies compare actual to expected over an exposure period and apply credibility to the result — because a small exposure producing a striking A/E ratio is usually telling you about the exposure rather than the mortality. Applying credibility is what separates an experience study from a ratio.

Lapse and persistency studies run on the same machinery, and the resulting assumptions feed pricing and valuation from one place rather than being re-entered into each.

What it does

  • Interpolate mortality between age nodes, with separate smoker and non-smoker bases.
  • Apply table ratings in configurable steps and flat extras on top of the base rate.
  • Compare actual to expected over a defined exposure period.
  • Apply credibility to the A/E result rather than reporting the raw ratio.
  • Feed the resulting assumptions to pricing and valuation from a single source.

Implements

  • Mortality tables with age interpolation
  • Smoker / non-smoker bases, table ratings, flat extras
  • Actual-versus-expected with credibility

See it in the product

Run an experience study on a small cohort: the credibility-weighted result sits between the raw A/E and the expected basis, which is the behaviour that stops a thin exposure moving an assumption.

Capability 05

Assumption sets, versioned and approved

Assumptions are versioned records with lineage, so a run can be tied to the basis it used.

Assumptions live as versioned sets rather than as values inside a model. A set carries its own identity and approval state, and a run records which set it used — so the question every valuation review asks, "what basis produced this number", is answered by the run rather than reconstructed from a change log.

Because the set is versioned rather than edited, a superseded basis remains readable. A run records the version identifier rather than the table name, so publishing a new discount curve does not change last quarter's answer. Reproducing a prior period means pointing at the set that was in force, not restoring a backup.

Approval is separated from authorship: the platform rejects an approval by the author of the basis rather than warning about it. And the control sits on what may be PUBLISHED rather than on what may be computed — a projection pinned to an unapproved assumption version runs, and is marked not reportable. Blocking analysis on unapproved assumptions would stop actuaries doing the exploratory work that produces the approved basis in the first place, so the refusal lands where it belongs.

This is the same discipline the rate book uses on the underwriting side, and deliberately so: a number that cannot be tied to the assumptions behind it is not reproducible, whatever else is stored with it. Model definitions are held the same way — a validator returns every diagnostic with the path it came from in one pass rather than stopping at the first failure, a definition that fails validation is still saved because authors need drafts, and publishing re-validates against the assumption tables that exist at that moment.

What it does

  • Hold assumptions as versioned sets with their own identity and approval state.
  • Record the version identifier on each run rather than the table name.
  • Keep superseded sets readable rather than overwritten.
  • Reject an approval made by the author of the basis rather than warning about it.
  • Run a projection pinned to an unapproved version, and mark it not reportable.
  • Return every model-definition diagnostic in one pass, each with the path it came from.
  • Re-validate a model definition against the assumption tables that exist at publish time.
  • Apply the same versioning discipline used for underwriting rate books.

Implements

  • Versioned assumption sets with approval
  • Approver-is-not-author separation of duties
  • Run-to-basis lineage by version identifier
  • Reportability gated on an approved basis

See it in the product

Open a completed valuation run: it names the assumption set version it used, and that version is still readable even though a newer one is now in force. Pin a run to a draft table and it still computes — and reports itself as not reportable.

Capability 06

Filings with hashed evidence packs

A filing ships with a SHA-256 hashed pack, so the evidence submitted is identifiable afterwards.

Regulatory filings assemble an evidence pack and hash it with SHA-256. The hash is the point: it makes the exact set of figures and documents submitted identifiable later, which is what a follow-up question from a regulator months afterwards actually needs.

Peer review and appointed-actuary sign-off are recorded against the work rather than tracked outside it, so the governance trail and the numbers are the same record.

The filing types the platform recognises span Solvency II, IFRS 17, NAIC rate filings, market conduct, RBC, LDTI and APRA — as filing categories. That is a routing and packaging capability, and it is worth being precise: recognising LDTI as a filing type is not the same as implementing LDTI measurement.

What it does

  • Assemble a filing evidence pack and hash it with SHA-256.
  • Record peer review and appointed-actuary sign-off against the work itself.
  • Route filings by category across Solvency II, IFRS 17, NAIC rate, market conduct, RBC, LDTI and APRA.

Implements

  • SHA-256 hashed evidence packs
  • Peer review and appointed-actuary opinion

See it in the product

Generate a filing pack and record its hash. Re-generate from the same inputs and the hash matches; change one figure and it does not.

Capability 07

P&C pricing and catastrophe modelling

On-level, trend, frequency-severity and credibility for pricing; accumulation-based PML for cat.

P&C pricing runs the standard chain: bring historical premium on-level to current rates, trend losses to the pricing period, fit frequency and severity separately rather than modelling pure premium as one quantity, and apply credibility to the indicated rate change.

Separating frequency from severity matters because they move for different reasons and respond to different actions — a severity trend driven by repair costs and a frequency trend driven by exposure are the same indicated rate change and completely different problems.

Catastrophe modelling works from real accumulations rather than a static PML figure: exposure is aggregated by zone and the probable maximum loss is derived from that accumulation, so a change in the book moves the number.

What it does

  • Bring historical premium on-level to current rates.
  • Trend losses to the pricing period.
  • Fit frequency and severity separately rather than modelling pure premium directly.
  • Apply credibility to the indicated rate change.
  • Derive PML from aggregated zonal exposure rather than a stored figure.

Implements

  • On-level premium and loss trend
  • Frequency-severity decomposition
  • Credibility weighting
  • Accumulation-based PML

See it in the product

Add exposure in a catastrophe zone and re-run: the PML moves, because it is derived from the accumulation rather than held as a figure.

Capability 08

The certified-data gate

No production run uses uncertified source data unless the run is labelled exploratory — and an exploratory run can never be published.

Certification is a DECISION, not a score. A data-quality run measures what the rows look like — how many errors, whether control totals tie — and it is produced by code. A certification is a named person saying "this version may back a production actuarial result", on the strength of that measurement. Collapsing the two is how this control usually rots, so they are separate records and only the second opens the gate.

Effective status is derived at decision time rather than read from a stored column. The dataset-versions table caches a status so that listing versions is one query, and the gate deliberately ignores that cache: a cache is written when the decision is made and cannot know when a validity window later closes. Where no expiry was stated, a default 90-day window applies — finite by design, so nothing is ever certified forever. A withdrawal stays visible as `revoked` rather than being softened back to "nobody has looked at this yet", and any decision value the gate does not recognise blocks rather than falling through a default branch.

An override is the only way past an uncertified version, and it is matched exactly. Purpose is compared for equality against a closed set of eleven work types, so a waiver obtained to unblock a pricing study cannot authorise a reserve close; a scoped override authorises only its own project. The decision names the override it relied on, so a close run on certified data and a close run on a waiver are distinguishable afterwards rather than both reading "allowed". The other route past the gate is the exploratory label, and it is not free: an exploratory run may read uncertified data and can never be published or approved, enforced by a database trigger rather than by the route that sets the label. Without that second half, "exploratory" would be a one-word bypass of the whole control.

Where the gate reaches is a list you can read rather than a claim. Eleven work types each have their own provenance resolver, because "which dataset versions does this run depend on?" has a different answer for reserving, pricing and training. Twenty-one agent actions are gated at the executor dispatch point — before the executor is called, so a refused step genuinely did not compute — plus the reserving close, the reserving run and the pricing run routes. Work whose provenance does not reach a dataset version is counted and reported rather than blocked, because there is nothing there to certify; that limitation travels with the decision, since a gate that finds nothing to check and answers "cleared" is indistinguishable from one that checked.

What it does

  • Separate a data-quality measurement from a certification decision made by a named person.
  • Derive certification status at decision time instead of trusting the cached status column.
  • Expire a certification with no stated validity after a finite default window of 90 days.
  • Keep a revoked certification visible as revoked rather than as never-certified.
  • Match an override on exact purpose and scope across a closed set of eleven work types.
  • Name the override a run relied on, so a waiver and a clean pass are distinguishable.
  • Allow an exploratory run to read uncertified data, and refuse to publish or approve it.
  • Gate twenty-one agent actions at the dispatch point, before the executor runs.
  • Report work whose provenance reaches no dataset version rather than treating it as clearance.
  • Fail closed on any certification state the gate does not recognise.

Implements

  • Certification as a human decision, separate from data quality
  • Purpose- and scope-matched overrides
  • Production / exploratory run labelling
  • Per-work-type provenance resolution

See it in the product

Put an expired dataset version and an override granted for a pricing run against a reserve close: it is refused, and the refusal names the purpose mismatch. The interactive demo runs the same decision function the close route calls, so you can try every combination in the browser.

Capability 09

Sealed evidence packs a reviewer can check without us

Eighteen sections, a limitations list built from what the run could not establish, and a seal anyone holding the pack can verify.

A workflow evidence pack assembles a completed run into eighteen sections — source data versions, certification results, reconciliations, model and assumption versions, run parameters, output, diagnostics, sensitivities, movement analysis, recommendations, review comments, approvals, limitations, citations, generated reports and export history. Which section a step's output belongs to is DECLARED on each of the 219 capabilities rather than inferred from the step, so a new agent action cannot silently fail to appear in the evidence.

The limitations section is assembled from what the run could not establish: the steps that ran and found no data, the steps with no executor bound, the steps held for approval and never run. Nobody composes it. It is the section a reviewer needs most and the one a system is most tempted to leave flattering, which is exactly why it is derived rather than written. An empty section states which of three reasons applies — nothing feeds it, its feeding steps found no data, or they did not complete — because "we looked and there is none" and "we did not look" are different findings and a reader must not have to guess.

Immutability is enforced twice. A BEFORE UPDATE and BEFORE DELETE trigger prevents a sealed pack from being altered in the database at all, and a SHA-256 digest over a canonical serialisation of the content detects it if it were. Corrections supersede into a new version; a sealed pack is never edited. The digest is deliberately computed in plain TypeScript rather than through a Node built-in, so a reviewer holding the pack can verify the seal themselves — a seal only the issuing system can check is a claim about the issuing system rather than evidence. The hash covers content and excludes who exported it and when, so two people can confirm they are holding the same pack.

What it does

  • Assemble a completed run into eighteen declared evidence sections.
  • Route each step's output by the `evidenceSection` declared on its capability rather than by inference.
  • Build the limitations section from steps that found no data, had no executor, or were held.
  • State which of three reasons an empty section is empty for.
  • Prevent update and delete on a sealed pack with a database trigger.
  • Detect alteration with a SHA-256 digest over a canonical serialisation.
  • Supersede a corrected pack into a new version instead of editing the sealed one.
  • Compute the digest in portable code so the holder of a pack can verify it independently.
  • Exclude exporter and timestamp from the hash so identical packs hash identically.

Implements

  • Eighteen-section workflow evidence pack
  • Trigger-enforced immutability
  • SHA-256 over canonical JSON
  • Supersede-not-edit corrections

See it in the product

Build a pack, note its hash, then change one integer in the content: the recomputed digest no longer matches. The interactive demo does exactly this in the browser using the platform's own seal function.

Capability 10

Where this module ends today

Stated rather than implied: the capital lab, PBR and the model-drift monitor are not built, and a pack exports as JSON.

This is the deepest module in the platform, which makes the few overclaims worth naming precisely rather than leaving among things that are true.

The capital module implements NAIC RBC and nothing else — there is no capital lab, no efficient frontier and no 50,000-simulation stress run. The page carried "50k stress simulations per capital run" as its headline metric and no such number exists anywhere in the engine. The genuine stochastic capability is the reserving bootstrap, which defaults to 500 iterations and is bounded at 5,000.

PBR and VM-20 are not implemented; LDTI exists as a filing category, not as a measurement model, and the page previously listed both alongside IFRS 17 and Solvency II as though they were peers. There is also no model-drift monitoring and no "AI time-to-breach" for actuarial models — those words appear nowhere in the codebase.

On the governance layer specifically: a sealed evidence pack exports as JSON, and there is no PDF or XLSX rendering of one. Compute runs synchronously behind hard input caps rather than on a job queue. And the certified-data gate rests on dataset versions and life-valuation model point versions — work whose provenance reaches neither is reported as unresolved rather than blocked, which is stated on every decision the gate makes.

What it does

  • Name the overclaimed capabilities rather than leaving them among the true ones.
  • State the real bootstrap bounds — 500 by default, 5,000 maximum — in place of the 50,000 figure.
  • State that evidence packs export as JSON, with no PDF or XLSX rendering.
  • State that unresolved provenance is reported rather than blocked.

Implements

  • Capability disclosure

See it in the product

Nothing to demonstrate, which is the point on a module where most of the page is demonstrable.

Built for the people who own the risk

Made for your team, aligned to your frameworks.

Cortex skill-agents draft the work, cite their sources and write every action to the evidence ledger — so Actuarial Platform accelerates the people accountable for it without putting your audit posture at risk.

Who it serves

  • Pricing actuaries
  • Reserving actuaries
  • Appointed & chief actuaries
  • Valuation teams
  • Capital managers

Aligned to

  • IFRS 17
  • Solvency II
  • NAIC RBC
  • LDTI
  • PBR / VM-20
  • ASOPs
CortexAI reasoning copilot
Grounded

Shared device fingerprint with the ring94
Repair shop tied to a prior SIU case87
Loss pattern matches the closed cluster81
SourcesPolicy ledgerClaims graphSIU casebook
Confidence94%
FAQ

Actuarial Platform FAQ

What evaluation teams want to know before a demo — answered plainly.

Chain ladder, Bornhuetter-Ferguson, Cape Cod and expected loss ratio deterministically, plus Mack for an analytic standard error and a residual bootstrap for a full predictive distribution. Cape Cod derives its a-priori loss ratio from the triangle rather than taking it as an input, and a tail factor is fitted from observed link ratios rather than assumed.

Yes, exactly. The bootstrap is seeded, so the same triangle and the same seed return the same percentiles to the digit. That is a property of the implementation rather than a process someone follows — and a range that cannot be reproduced is not evidence, whatever else is stored alongside it. The bootstrap defaults to 500 iterations and is bounded between 50 and 5,000.

GMM, VFA and PAA are implemented as measurement models, with the CSM rolled forward through interest accretion, new business, changes in fulfilment cash flows for future service, and release for services provided. The risk adjustment for non-financial risk is held alongside fulfilment cash flows, and the loss component on onerous groups is tracked separately — because an onerous group has no CSM to release.

Yes, from the same book. SCR is computed by module — market, life, non-life, health, counterparty default, operational — and aggregated through the prescribed correlation structure rather than summed, which is the difference between recognising diversification and overstating the requirement. Lapse risk takes the worst of mass lapse, permanent increase and permanent decrease. NAIC RBC runs alongside it.

No, and the page previously claimed one. The capital module implements NAIC RBC and nothing else — there is no capital lab, no efficient frontier and no 50,000-simulation stress run; the old headline metric of "50k stress simulations per capital run" corresponds to no number in the engine. The genuine stochastic capability is the reserving bootstrap at up to 5,000 iterations.

No. PBR and VM-20 are not implemented. LDTI exists as a filing CATEGORY the platform can route and package, which is not the same as an LDTI measurement model — the page previously listed both beside IFRS 17 and Solvency II as though they were peers. There is also no model-drift monitoring or "AI time-to-breach" for actuarial models; those appear nowhere in the codebase.

A gate that refuses it. Certification is a decision by a named person, kept separate from the data-quality run that measures the rows — only the decision opens the gate. Effective status is derived rather than read from the cached status column, because a cache written at decision time cannot know when a validity window later closes, and a certification with no stated expiry lapses after a finite default of 90 days. An override is the only way past, matched on exact purpose across a closed set of eleven work types, so a waiver granted for a pricing run cannot authorise a reserve close. Twenty-one agent actions are gated at the dispatch point, before the executor runs, plus the reserving close and the reserving and pricing run routes.

It would if the label were free, so it is not. An exploratory run may read uncertified data and can never be published, approved or promoted — enforced by a database trigger rather than by the route that sets the label. Without that second half, "exploratory" would be a one-word bypass of the entire gate: label the run, skip certification, publish anyway.

Yes, and that is the design. A sealed pack carries a SHA-256 digest over a canonical serialisation of its content, computed in portable code rather than through a platform-specific primitive, so anyone holding the JSON can recompute it with anything that runs JavaScript. A seal only the issuing system can check is a claim about the issuing system rather than evidence. Immutability is enforced twice — a BEFORE UPDATE/DELETE trigger prevents alteration, and the digest detects it — and a correction supersedes into a new version rather than editing the sealed one. The interactive demo builds and breaks a seal in the browser using the platform's own function.

Eighteen sections, from source data versions and certification results through diagnostics, sensitivities and approvals to citations and export history. Which section a step's output lands in is declared on each of the 219 capabilities rather than inferred, so a new agent action cannot silently fail to appear. The limitations section is assembled from what the run could NOT establish — steps that ran and found no data, steps with no executor bound, steps held for approval and never run. Nobody composes it, because it is the section a reviewer needs most and the one a system is most tempted to leave flattering. An empty section states which of three reasons it is empty for.

By Munich chain ladder rather than by selection. Classical chain ladder run on each triangle in isolation gives one book two ultimates, which means the reserve depends on which triangle somebody chose. Munich informs each triangle by the other's residuals so the estimates converge, and the gap that remains is reported rather than averaged away — a method producing exact agreement would be hiding the disagreement. Where the fitted lambdas are near zero it collapses back to plain chain ladder, which is the engine saying it has nothing to add.

See Actuarial Platform on your data

Book a working session and we will map your sources, workflows and frameworks onto Actuarial Platform — and show Cortex reasoning over them live.

Actuarial Platform — Every assumption versioned, every run reproducible, every sign-off logged — and uncertified data refused. | AegisNow Insurance