One definition followed from the model to the places it is rendered and the checks that keep them honest — the entry, its change log, the JSON Schema export, the warehouse view, the graph projection, and the gate. Every company, system, person, figure and date in it is fictional.
Published
NetWrittenPremium is one definition held in three places. The policy admin system computes it as policies are written, the finance warehouse recomputes it for the monthly close, and the broker portal shows a third figure to producers. They disagree on one thing: whether a cancellation nets out in the month it is recorded or at period close. Last quarter that disagreement produced 31 wrong-total tickets — 19 raised by producers, 12 by finance — a fictional count from a fictional incident log, here to show the shape of the cost rather than to promise one.
1. The definition in the Core Model
The element as it sits in the model. The last three rows are the governed-meaning fields CoreModels lists for the dbt connector.
Field
Value
Name
NetWrittenPremium
Definition
Gross written premium for the period, less cancellations and endorsement reductions, before reinsurance ceded.
Grain
One row per policy per accounting month.
Owner
Finance Data — the team that can change this sentence.
meaningNote
Premium is booked on the policy effective date, not the bind date: a policy bound in March with an April effective date belongs to April.
commonMistake
Summing the warehouse column premium_amt, which still carries reinstatement rows and counts a reinstated policy twice.
doNotUseFor
Earned premium, commission bases, or any reinsurance-ceded view. Those are separate elements with their own grain.
2. The change
The change log the model keeps, and that exports with it. You own the Core Model, and the change log is yours on exit.
When
Who
What changed
Why
2025-11-04
Finance Data
First entry. The definition and its grain are written down: one row per policy per accounting month.
Three systems each held a version of this number and none of them was written anywhere.
2026-02-17
Finance Data, reviewed by Policy Ops
Cancellations net at period close, not in the month the cancellation is recorded.
Mid-month cancellations moved premium between months, so the close never matched the portal. Period close is the basis the statutory filing already uses.
3. Rendered three times
As the JSON Schema export. Ownership is not a JSON Schema keyword, so it stays in the model and its change log rather than being invented as a custom field here.
Keyword
Value
title
NetWrittenPremium
type
object
description
Gross written premium less cancellations and endorsement reductions, before reinsurance ceded. One row per policy per accounting month; cancellations net at period close.
As a dbt-style view for the finance warehouse. The GROUP BY is the grain, and the case expression is the netting rule from the February change.
Clause
SQL
select (grain)
policy_id, case when txn_type = 'cancellation' then period_close_month else date_trunc('month', accounting_date) end as accounting_month
select (measure)
sum(signed_amount) as net_written_premium
from
{{ ref('fct_premium_txn') }}
where
txn_type in ('written', 'endorsement', 'cancellation')
group by
1, 2
As a Cypher projection for a graph backend — the same grain and the same netting rule, produced from the entry, never edited as truth.
Clause
Cypher
MATCH
(p:Policy)-[:HAS_TXN]->(t:PremiumTxn)
WHERE
t.txnType IN ['written', 'endorsement', 'cancellation']
WITH (grain)
CASE WHEN t.txnType = 'cancellation' THEN t.periodCloseMonth ELSE date.truncate('month', t.accountingDate) END AS accountingMonth
RETURN (grain and measure)
p.policyId, accountingMonth, sum(t.signedAmount) AS netWrittenPremium
All three are renders of the one entry above, produced from it rather than maintained beside it. We author a Core Model three systems at a time, validate mappings at the boundary, and you leave owning the model in open formats — SQL, Cypher and vector indexes are render targets, not the product.
Four render files — the JSON Schema, a ShEx shape, the SQL view and the Cypher projection — plus the sample engagement clause, the boundary-check skeleton and a sample refuse record are here to download and diff. They are hand-authored illustrations in the formats CoreModels exports and the formats an engagement renders to; they are not a CoreModels export. On 2026-09-05 the SQL view and the Cypher projection were run against PostgreSQL 16 and Neo4j 5 on the same six-row fixture and returned the same three rows, with the cancellation netted in its period-close month; the ShEx shape parses in the reference parser and the JSON Schema compiles under draft 2020-12 and rejects a malformed month. Beside the record sit its schema and an eval fixture that replays the same answer against a frozen contract version and asserts the decision — the check your CI runs from conformance.example.yml is the one your evals assert.
The renders are checked on every pull request that touches either of them, and the third check reads the agent tool schema, because agents read the governed model through the MCP endpoint under the permissions of the account they run under. The gate is Ariesnet's engagement practice, run in your own continuous integration. It is not a coremodels.io feature; nothing on the platform switches it on. That is the point: the gate is written into your engagement's conformance contract and your own CI, where your auditor can read it, rather than into a vendor setting nobody outside the vendor can inspect. The clause and the configuration skeleton the engagement leaves behind are in the downloads above, so what 'set in the engagement' means is something you can paste into a Monday deck. Illustration: the grain check below would map to BCBS 239's accuracy-and-integrity principle in a bank's reporting framework; the mapping is written into the engagement, not assumed.
Three checks on the pull request.
Check
Passes when
Fails when
Grain
The view's GROUP BY is exactly the grain in the definition: policy and accounting month.
A change adds coverage_id to the GROUP BY, or drops policy_id. The view now returns a different grain than the definition states, and the total moves.
Netting
Cancellation rows are attributed to the period close.
A change routes cancellations back to the month recorded, restoring the old behaviour without touching the definition anyone approved.
Agent tool schema
The tool that answers 'net written premium' cites the governed element.
The tool cites a warehouse column instead, so the answer stops following the definition the next time the definition changes.
Questions
Answered directly
When two systems disagree on the same metric, how is it resolved and can I reproduce yesterday's answer?
The disagreement is resolved as a mapping in the Core Model, approved by the owner of each schema, and recorded in the change log with who changed what and when. Agents read the model through the MCP endpoint, so an answer traces to the model version it was read from. Version history is a Team and Enterprise feature on coremodels.io; with it in place, yesterday's version is read back, and the answer with it.
When two systems disagree on a definition an agent needs, who freezes the mapping, and what does the MCP endpoint do until then?
The owner of each schema agrees the mapping in the Core Model; that agreement is the freeze, and the change log records who changed what and when. Until it exists, the behaviour at the boundary — whether an agent refuses the answer or returns it with a warning — is set by the conformance contract written into your engagement, not by the platform. The platform publishes no refuse-or-warn default; the engagement sets it. On Managed Operations, every refusal is logged and carried into the incident attribution an auditor receives. Refuse is the default; warn is enabled only for non-binding internal use, every warned answer is labelled non-authoritative, and that configuration is signed off by your named control owner — never by a vendor default and never by a merge.
Terms used
Definitions
Conformance gateway
The control point where context is checked against conformance and efficiency protocols before it is allowed into retrieval or agent use. See also: Context supply chain
Semantic layer
The shared meaning layer that aligns terms, entities, and relationships across systems so agents and people interpret the same business facts the same way. See also: Context supply chain
Related engagement
Want this assessed against your own estate?
The Core Model Blueprint takes one named agent workflow through all seven stages with your systems and your content, and ends in a sequenced Core Model your team could execute without us.
