> Source: github.com/abdulbaruwa/context-wiki@15ab7576ebb52b3bbe27bd001c925ba89eec7244 # Context.Insure Docs Agent-ready Every documentation route ships a verified raw Markdown twin and an /llms.txt index. Explore /llms.txt
Four-part spine Strategy, domain rules, architecture, and runbooks stay in separate pages. Product switcher Six products, one header, the same order on every page. Agent endpoints Read /llms.txt for the index and /llms-full.txt for the corpus. Corpus gate check:wiki rejects broken links, missing titles, and em dashes.
## Products ## Quick start The public site is the contract agents read. HTML is for people. The Markdown twin beside each route is for agents.

  1. Open the product

    Pick a product from the header. The sidebar keeps the four-part spine for that product, and the other five stay one click away.

  2. Read the spine in order

    Strategy records settled decisions. Domain rules state what must be true. Architecture describes the system. Runbooks say how to operate it.

  3. Fetch the agent index

    Agents start at /llms.txt, then open a page's raw twin. The full corpus is /llms-full.txt.

  4. Run the corpus gate

    Before a documentation change merges, the gate has to pass with an empty error list.

    npm run check:wiki
> Source: github.com/abdulbaruwa/BrokerIQ@74565527721155bbf2c0b45a26f85116813f4194 # BrokerIQ BrokerIQ is catalogue order 06. It supports broker placement and the Pippa advisory copilot. ## Role Broker placement and the Pippa advisory copilot. The vocabulary and the flows are settled with brokers, and every page has an owner. ## Documentation spine - [Placement decisions](/brokeriq/strategy-and-decisions/placement/) - [Domain glossary](/brokeriq/domain-rules/domain-glossary/) - [Pippa](/brokeriq/architecture/pippa/) - [Runbook](/brokeriq/runbooks/documentation/) [Platform home](/) > Source: github.com/abdulbaruwa/BrokerIQ@74565527721155bbf2c0b45a26f85116813f4194 # Pippa Pippa reads the placement and the glossary. It writes advice back onto the placement as a suggestion the broker can accept or ignore. ## Boundary - Pippa does not write to [Context Claims](/claims/) or move money in [RemitIQ](/remitiq/). - A suggestion stores the glossary terms it used. - The placement remains readable if Pippa is unavailable. [Back to BrokerIQ](/brokeriq/) > Source: github.com/abdulbaruwa/BrokerIQ@74565527721155bbf2c0b45a26f85116813f4194 # BrokerIQ domain glossary Pippa uses the same words the placement record uses. This glossary is the placement vocabulary, synced later from `CONTEXT.md`. ## Terms | Term | Meaning in BrokerIQ | | --- | --- | | Placement | The broker's record of putting a risk with a carrier | | Slip | The submission document that states the risk | | Binder | The authority under which a risk can be written | | Pippa | The advisory copilot. Pippa suggests. A person binds | | Bordereau | The periodic statement of written items, reconciled in RemitIQ | If a word is not in this table, Pippa should ask, not invent a synonym. [Back to BrokerIQ](/brokeriq/) > Source: github.com/abdulbaruwa/BrokerIQ@74565527721155bbf2c0b45a26f85116813f4194 # BrokerIQ runbook BrokerIQ pages follow the house rules: British spelling, no em dashes, and links that resolve. ## Before you add a term 1. Add the new term to the [domain glossary](/brokeriq/domain-rules/domain-glossary/) first. 2. Update the placement page if the record shape changes. 3. Keep internal notes and agent instruction files out of this site. [Back to BrokerIQ](/brokeriq/) > Source: github.com/abdulbaruwa/BrokerIQ@74565527721155bbf2c0b45a26f85116813f4194 # Placement decisions Placement is the broker's work to put a risk with a carrier. BrokerIQ records that work. Pippa advises. Pippa does not bind. ## Settled - The placement record is the source of truth, not the chat transcript. - Advice from Pippa cites the glossary and the placement, so a reader can check it. - Navigation names the product BrokerIQ, with no status suffix. [Back to BrokerIQ](/brokeriq/) > Source: github.com/abdulbaruwa/contextclaims.ai@88ee17efdbaf7c0475acbbfb4a5a2ed310cb6985 # Context Claims Context Claims is catalogue order 04. It adjudicates a claim inside the authority the carrier has actually granted. ## Role Claims adjudication and authority engine. A payment that exceeds authority does not become valid because the screen allowed it. ## Documentation spine - [Adjudication decisions](/claims/strategy-and-decisions/adjudication/) - [Authority rule seeding](/claims/domain-rules/authority-rule-seeding/) - [Authority engine](/claims/architecture/authority-engine/) - [Admin user seeding](/claims/runbooks/admin-user-seeding/) [Platform home](/) > Source: github.com/abdulbaruwa/contextclaims.ai@88ee17efdbaf7c0475acbbfb4a5a2ed310cb6985 # Authority engine The engine reads the seeded rules and the user's role at the moment of the decision. It does not cache a "yes" from an earlier amount. ## Evaluation 1. Load the rule in force on the decision date. 2. Compare the settlement amount with the role threshold. 3. Record the rule identity on the claim, so the decision can be explained later. [Back to Context Claims](/claims/) > Source: github.com/abdulbaruwa/contextclaims.ai@88ee17efdbaf7c0475acbbfb4a5a2ed310cb6985 # Authority rule seeding Authority rules are seeded before any user can settle a claim. A role without a rule cannot approve a payment, even if the user exists. ## Authority model Each rule names a role, a threshold, and the date it becomes effective. Later rules do not erase earlier ones. They supersede them from the effective date. ## Seeding inputs | Input | Purpose | | --- | --- | | Authority rule set | Decides which roles may settle a claim | | Threshold | Bounds the amount a role may approve | | Effective date | Marks when the rule set becomes live | ## Validation Reject a seed file when two rules for the same role share an effective date, or when a threshold is blank. [Validation](#validation) is a hard stop, not a warning the operator can click through. ## Rollback To roll back, seed a new rule set with a later effective date. Do not delete the previous rows. The claim that settled yesterday must still show the rule that allowed it. [Back to Context Claims](/claims/) > Source: github.com/abdulbaruwa/contextclaims.ai@88ee17efdbaf7c0475acbbfb4a5a2ed310cb6985 # Admin user seeding Admin users are seeded separately from authority rules. An admin can manage users. An admin cannot settle a claim unless an authority rule says so. ## Steps 1. Seed the authority rules in [Authority rule seeding](/claims/domain-rules/authority-rule-seeding/). 2. Create the admin identity. 3. Confirm the admin has no settlement authority unless a rule grants it. ## After seeding Sign in as the admin and open a claim above every threshold. The correct result is a referral, not a payment. [Back to Context Claims](/claims/) > Source: github.com/abdulbaruwa/contextclaims.ai@88ee17efdbaf7c0475acbbfb4a5a2ed310cb6985 # Adjudication decisions Adjudication answers two questions in order: is the claim covered, and is this person allowed to settle it for this amount? ## Settled decisions - Authority is data, seeded and versioned, not a hard-coded role name. - A referral is a successful outcome when the amount is above the role. - The claim file links to [Context DMS](/dms/) evidence instead of pasting it. [Back to Context Claims](/claims/) > Source: github.com/abdulbaruwa/context.dms.ai@bc70167b32bcea50c9ca1dba545083a38a4f00ed # Context DMS Context DMS is catalogue order 02. It keeps the original document and the evidence extracted from it in one store, so later products do not invent a second copy. ## Role Document intelligence and evidence store. DMS is the system of record for documents that enter through [PorterIQ](/porteriq/) and the evidence other products cite. ## Documentation spine - [Evidence store decisions](/dms/strategy-and-decisions/evidence-store/) - [Document rules](/dms/domain-rules/documents/) - [Pipeline overview](/dms/architecture/pipeline-overview/) - [Operations](/dms/runbooks/operations/) [Platform home](/) > Source: github.com/abdulbaruwa/context.dms.ai@bc70167b32bcea50c9ca1dba545083a38a4f00ed # Context DMS pipeline overview The pipeline is deliberately short. Ingest accepts bytes, extract pulls structured evidence, and the evidence store keeps both. ## Pipeline ```mermaid flowchart LR ingest[Ingest] extract[Extract] evidence[Evidence store] ingest --> extract --> evidence ``` ## Handoff [PorterIQ](/porteriq/architecture/overview/) is the usual source of new documents. [RemitIQ](/remitiq/domain-rules/evidence-stack/) cites the evidence store when a settlement needs proof. [Back to Context DMS](/dms/) > Source: github.com/abdulbaruwa/context.dms.ai@bc70167b32bcea50c9ca1dba545083a38a4f00ed # Document rules A document in DMS has an identity, a source product, and a type. The type is a classification, not a filename guess. ## Rules - Every document names the product that accepted it. - Retention follows the class of business, not the folder the file arrived in. - A deleted document is a recorded decision, not a missing blob. [Back to Context DMS](/dms/) > Source: github.com/abdulbaruwa/context.dms.ai@bc70167b32bcea50c9ca1dba545083a38a4f00ed # Context DMS operations When a document looks missing, check ingest before you check the evidence store. A file that never ingested cannot have evidence. ## Checks 1. Confirm the source product recorded an acceptance. 2. Confirm ingest stored the original bytes. 3. Confirm extract wrote a versioned evidence record. Do not re-upload the same bytes under a new identity to "fix" a gap. That splits the history. [Back to Context DMS](/dms/) > Source: github.com/abdulbaruwa/context.dms.ai@bc70167b32bcea50c9ca1dba545083a38a4f00ed # Evidence store decisions Evidence is not a side file. If a later product cites a fact, the citation has to resolve to the document DMS stored and the extraction that produced the fact. ## Settled decisions - The original bytes are immutable once accepted. - Extractions are versioned. A new model run does not overwrite the previous evidence. - Other products link to DMS. They do not keep a private copy of the pack. [Back to Context DMS](/dms/) > Source: github.com/abdulbaruwa/PorterIQ@0a66728fe5a2c18c5dd48d9eeac01e1082b2b325 # PorterIQ PorterIQ is catalogue order 01. It is the front door for new business: submissions arrive, get classified, and leave as a pack an underwriter can actually read. ## Role Submission triage and intake automation. PorterIQ does not decide the risk. It makes the submission complete enough for Context Workbench to open a case. ## Documentation spine - [Product vision](/porteriq/strategy-and-decisions/vision/) records the decisions that are already settled. - [Submission intake rules](/porteriq/domain-rules/intake/) states what a complete submission contains. - [Architecture](/porteriq/architecture/overview/) describes how intake hands work to the rest of the platform. - [Local preview](/porteriq/runbooks/local-preview/) explains how to read this baseline before the upstream sync lands. [Platform home](/) lists every product in the same order. > Source: github.com/abdulbaruwa/PorterIQ@0a66728fe5a2c18c5dd48d9eeac01e1082b2b325 # PorterIQ architecture PorterIQ receives a submission, stores the original documents in [Context DMS](/dms/), and publishes an intake result the rest of the platform can trust. ## Flow 1. Accept the submission and its documents. 2. Classify each document and record gaps. 3. Hand the pack to Context Workbench as a case the underwriter can open. ## Boundary Pricing, authority, and settlement do not live in this service. Those belong to Workbench, Claims, and RemitIQ. [Back to PorterIQ](/porteriq/) > Source: github.com/abdulbaruwa/PorterIQ@0a66728fe5a2c18c5dd48d9eeac01e1082b2b325 # Submission intake rules A submission is a set of documents plus the broker's covering note. Intake accepts it only when the rules below hold. ## Required pack - The slip, or an explicit waiver recorded on the submission. - Schedule information the binder expects for the class of business. - A named broker contact. ## Gaps Missing items stay visible. PorterIQ does not invent a document to close a gap. The underwriter sees the gap in [Context Workbench](/workbench/domain-rules/underwriting/). [Back to PorterIQ](/porteriq/) > Source: github.com/abdulbaruwa/PorterIQ@0a66728fe5a2c18c5dd48d9eeac01e1082b2b325 # PorterIQ local preview This baseline is the scaffold for PorterIQ. The upstream repository `abdulbaruwa/PorterIQ` will later sync `Vision.md` into the strategy section. ## Read this first 1. Open the [product vision](/porteriq/strategy-and-decisions/vision/). 2. Check the [intake rules](/porteriq/domain-rules/intake/) before changing a submission field. 3. Use the raw Markdown twin at `/porteriq/index.md` when an agent needs the page without HTML. [Back to PorterIQ](/porteriq/) > Source: github.com/abdulbaruwa/PorterIQ@0a66728fe5a2c18c5dd48d9eeac01e1082b2b325 # PorterIQ product vision PorterIQ exists so a submission is triaged before an underwriter spends time on it. The product vision is narrow on purpose. ## Settled decisions - Intake classifies the submission. It does not price it. - A submission is not "in the platform" until the required documents are present or explicitly waived. - Human reviewers see the classification and the gaps, not a hidden score. ## What this page is for Use this page when a change would move PorterIQ from intake into underwriting judgement. That move belongs in [Context Workbench](/workbench/), not here. [Back to PorterIQ](/porteriq/) > Source: github.com/abdulbaruwa/context.remitiq@8707f87eb755319e044186eb7476d8abcf4b8e04 # RemitIQ RemitIQ is catalogue order 05. It reconciles premium bordereaux with the cash and settlement evidence the carrier actually holds. ## Role Premium bordereaux and settlement reconciliation. RemitIQ closes the loop between what was written and what was paid. ## Documentation spine - [Settlement decisions](/remitiq/strategy-and-decisions/settlement/) - [Evidence stack](/remitiq/domain-rules/evidence-stack/) - [Canonical architecture](/remitiq/architecture/canonical-architecture/) - [Infrastructure runbook](/remitiq/runbooks/infrastructure/) [Platform home](/) > Source: github.com/abdulbaruwa/context.remitiq@8707f87eb755319e044186eb7476d8abcf4b8e04 # RemitIQ canonical architecture The canonical architecture separates the bordereau, the cash book, and the allocation that joins them. Upstream notes land here from `CANONICAL_ARCHITECTURE.md`. ## Parts - Bordereau intake, versioned by period. - Cash and settlement records. - Allocations that cite both, plus the [evidence stack](/remitiq/domain-rules/evidence-stack/). No part is allowed to overwrite another part's history. [Back to RemitIQ](/remitiq/) > Source: github.com/abdulbaruwa/context.remitiq@8707f87eb755319e044186eb7476d8abcf4b8e04 # RemitIQ evidence stack The evidence stack is the minimum proof for a reconciled line. ## Required evidence - The bordereau line, with contract and period. - The cash or settlement record it is allocated to. - The document in Context DMS that supports the figure, when the figure did not originate inside the platform. A line can stay unreconciled. That is an honest state. It is not a failure of the screen. [Back to RemitIQ](/remitiq/) > Source: github.com/abdulbaruwa/context.remitiq@8707f87eb755319e044186eb7476d8abcf4b8e04 # RemitIQ infrastructure runbook Infrastructure for RemitIQ is documented with the product, not in a private channel. The upstream `infra/README.md` maps to this runbook. ## When you change infrastructure 1. Update the runbook in the same change as the infrastructure. 2. Name the environment and the resource in plain language. 3. Keep secrets out of the page. Point to the secret store, not the secret. [Back to RemitIQ](/remitiq/) > Source: github.com/abdulbaruwa/context.remitiq@8707f87eb755319e044186eb7476d8abcf4b8e04 # Settlement decisions A bordereau line without cash is not settled. Cash without a bordereau line is not allocated. RemitIQ keeps both sides in one reconciliation. ## Settled decisions - Allocation is explicit. A matching amount is not enough on its own. - Evidence for the allocation lives in [Context DMS](/dms/architecture/pipeline-overview/). - A correction is a new allocation, not an edit that hides the first one. [Back to RemitIQ](/remitiq/) > Source: github.com/abdulbaruwa/contextbench.ai@9a896e72a97a8ad8ef1333ed24b74dff5ad1ffd0 # Context Workbench Context Workbench is catalogue order 03. It is where an underwriter or actuary works a case that [PorterIQ](/porteriq/) has already made readable. ## Role Underwriting and actuarial decision workspace. The workspace records the decision. It does not replace the authority engine in [Context Claims](/claims/) or the settlement book in [RemitIQ](/remitiq/). ## Documentation spine - [Workspace decisions](/workbench/strategy-and-decisions/workspace/) - [Underwriting case rules](/workbench/domain-rules/underwriting/) - [Event store](/workbench/architecture/event-store/) - [Projection runbook](/workbench/runbooks/projections/) [Platform home](/) > Source: github.com/abdulbaruwa/contextbench.ai@9a896e72a97a8ad8ef1333ed24b74dff5ad1ffd0 # Workbench event store Workbench treats the case as an append-only stream. The current screen is a projection of that stream, not the source of truth. ## Shape - Events are appended. They are not updated in place. - A change feed builds the projections the workspace reads. - A projection can be rebuilt from the stream. The stream cannot be rebuilt from a projection. This is the architecture the engineering notes describe: an event store with change-feed projections, so a lagging screen is a projection problem, not a lost decision. [Back to Context Workbench](/workbench/) > Source: github.com/abdulbaruwa/contextbench.ai@9a896e72a97a8ad8ef1333ed24b74dff5ad1ffd0 # Underwriting case rules The case opens when intake says the submission is complete enough to review. It does not open on a partial pack unless a waiver is recorded. ## Case contents - The submission identity from PorterIQ. - Document links into [Context DMS](/dms/domain-rules/documents/), not copies. - The decision, the referral, or the decline, each with a reason. [Back to Context Workbench](/workbench/) > Source: github.com/abdulbaruwa/contextbench.ai@9a896e72a97a8ad8ef1333ed24b74dff5ad1ffd0 # Projection runbook If the case screen disagrees with the latest decision, treat the screen as stale before you treat the decision as wrong. ## Steps 1. Read the latest event on the case stream. 2. Compare it with the projection the screen is showing. 3. Rebuild the projection from the stream if the event is newer. Do not write a correcting event just to repaint the screen. That adds a decision that never happened. [Back to Context Workbench](/workbench/) > Source: github.com/abdulbaruwa/contextbench.ai@9a896e72a97a8ad8ef1333ed24b74dff5ad1ffd0 # Workbench decisions A case is the underwriter's record of what was considered and what was decided. The workspace keeps that record attached to the submission, not in a side spreadsheet. ## Settled decisions - One open case per submission. - Notes that change the decision are events, not edits that erase the previous note. - Actuarial referral is a state of the case, not a second product. [Back to Context Workbench](/workbench/)