Structured output is the discipline that lets AI assistance feed downstream systems without manual re-keying. A submission-summary text blob has limited operational value; the same content emitted as JSON conforming to Guidewire PolicyCenter's submission schema ingests directly into the carrier's policy administration system. A claim-summary text blob requires adjuster transcription; the same content emitted in ClaimCenter file-note schema populates the claim file automatically. A reserve-memo narrative supports SAO supporting-narrative drafting; the same reserve estimates emitted as a CSV with accident-year × development-point structure feeds R or SAS or Python pipelines for downstream actuarial analysis. The structured output layer is the bridge between AI generation and the carrier's existing tech stack - Guidewire PolicyCenter and ClaimCenter for P&C carriers; Duck Creek and Sapiens and Majesco as P&C platform alternatives; Applied Epic and AMS360 and Vertafore for agency management systems; Vlocity/Salesforce FSC for carrier-facing CRM integration; R, SAS, Python for actuarial pipelines. This lesson walks the JSON schema, CSV format, and template-ready outputs each system expects, plus the negative-constraint patterns that prevent the model from generating protected-class proxies, fabricated form numbers, or coverage opinions without citation. The 2026 AI-disciplined carrier maintains schemas per artifact per system with version-stamped governance.

Why Structured Output Is the Operational Multiplier

Manual integration of AI outputs into downstream systems consumes time and introduces error: an adjuster reads the AI-generated claim summary, decides which fields to copy into ClaimCenter, retypes them, occasionally mistyping. At carrier scale (thousands of claims per day at a mid-size P&C carrier), the manual-integration overhead exceeds the time saved by AI generation. Structured output eliminates the integration step: the AI emits content conforming to the downstream system's data model; integration is API-call from AI output to system ingest. The carrier's tech stack - Guidewire, Duck Creek, Sapiens, Majesco, Applied Epic, AMS360 - accepts JSON or XML for most data operations through documented APIs; CSV remains common for batch operations; PDF and DOCX for human-readable artifacts.

The operational multiplier appears at scale: at a $2B P&C carrier processing 600-1,200 FNOLs per day, structured-output integration to ClaimCenter saves 15-30 adjuster-minutes per claim (entire claim-file initial setup compressed), translating to 150-600 adjuster-hours per day at carrier scale. The savings recur daily; the investment in schema design is one-time per artifact. ROI is significant within months; the cumulative leverage builds quarterly. Mature carriers operate structured output as standard discipline; immature carriers operate AI generation without integration and capture only the generation-side efficiency gain.

Guidewire PolicyCenter Submission Ingest JSON Schema

Guidewire PolicyCenter accepts submission data through documented REST APIs; the JSON structure maps to PolicyCenter's internal data model. A simplified version of the submission-ingest JSON for a commercial property submission:

{
  "submission": {
    "submissionNumber": "[carrier-assigned ID]",
    "createDate": "2026-05-28T10:30:00Z",
    "producer": {
      "agencyName": "[Synthetic Agency]",
      "producerName": "[Producer Name]",
      "agencyCode": "[Code]",
      "agencyContact": "[Contact]"
    },
    "namedInsured": {
      "name": "[Synthetic Insured LLC]",
      "fein": "[Tax ID]",
      "address": {
        "line1": "[Address]",
        "city": "[City]",
        "state": "[ST]",
        "zip": "[ZIP]"
      },
      "entityType": "LimitedLiabilityCompany",
      "yearEstablished": 2008
    },
    "classification": {
      "naics": "332710",
      "naicsDescription": "Machine Shops",
      "sic": "3599",
      "isoGLClassCode": "51315",
      "primaryOperations": "Precision machining and fabrication for industrial OEM"
    },
    "policyTerm": {
      "effectiveDate": "2026-08-01",
      "expirationDate": "2027-08-01"
    },
    "exposureBase": {
      "annualRevenue": 48000000,
      "employeeCount": 95,
      "payroll": 6400000
    },
    "locations": [
      {
        "locationNumber": 1,
        "address": {"line1": "[Address]", "city": "[City]", "state": "OH", "zip": "[ZIP]"},
        "buildingValue": 14000000,
        "bppValue": 8500000,
        "businessInterruption": 3500000,
        "construction": "JoistedMasonry",
        "yearBuilt": 2008,
        "sprinklerProtection": "Automatic",
        "fireAlarm": "CentralStation"
      }
    ],
    "lossHistory": {
      "years": 5,
      "totalClaims": 1,
      "totalPaid": 47000,
      "details": [
        {
          "claimDate": "2022-03-15",
          "lossType": "GeneralLiability",
          "paidAmount": 47000,
          "status": "Closed",
          "notes": "Employee slip-and-fall on customer site; rooted in customer-property condition per investigation."
        }
      ]
    },
    "uwAnalysis": {
      "appetiteMatch": true,
      "appetiteReference": "GI-2026.M.001 §3.2",
      "recommendedTier": "Preferred",
      "reviewItems": [
        "Inland marine sublimit for in-transit machinery Ohio-to-Indiana",
        "Employment practices liability rider given >50 employee count",
        "Cyber liability standalone or bundle"
      ],
      "treatyConsiderations": "Within Hartford standard single-risk limits; no facultative cession anticipated."
    }
  }
}

The schema's discipline: every field corresponds to a PolicyCenter data-model attribute; data types match PolicyCenter expectations (date in ISO 8601, monetary values as numbers not strings); enumerated values use PolicyCenter's controlled vocabulary (entityType: LimitedLiabilityCompany, construction: JoistedMasonry, lossType: GeneralLiability); arrays support repeating structures (locations, lossHistory details). The AI system prompt references the schema; the few-shot examples produce conforming outputs; the integration layer ingests directly. Schema versions track per PolicyCenter release; carrier maintains schema registry aligned with PolicyCenter upgrade cadence.

ClaimCenter File-Note JSON Schema

Guidewire ClaimCenter accepts file-note data through similar REST APIs; the JSON structure maps to ClaimCenter's claim-file data model. A simplified version of the file-note ingest JSON:

{
  "fileNote": {
    "claimNumber": "[carrier-assigned ID]",
    "noteDate": "2026-05-28T14:15:00Z",
    "author": {
      "userId": "[adjuster ID]",
      "userName": "[Adjuster Name]",
      "userRole": "ClaimAdjuster"
    },
    "noteType": "InitialAssessment",
    "category": "CoverageAnalysis",
    "lossDetails": {
      "lossType": "AutoCollision",
      "lossDate": "2026-05-25",
      "lossLocation": "[Address]",
      "coverageFormCited": "CA 00 01 11 20",
      "endorsementsCited": ["CA 99 23 09 23"],
      "policyNumber": "[Policy ID]",
      "policyEffective": "2025-08-01",
      "policyExpiration": "2026-08-01"
    },
    "coverageFlags": [
      {
        "flag": "CollisionCoverage",
        "applicable": true,
        "deductible": 500,
        "notes": "Collision coverage applicable; deductible per declarations."
      },
      {
        "flag": "BodilyInjuryLiability",
        "applicable": true,
        "limit": "250000/500000",
        "notes": "Third-party may pursue BI; coverage within $250K per person limit."
      }
    ],
    "reservesRecommendation": {
      "collisionRepair": {"low": 12000, "high": 16000, "best": 14000},
      "biThirdParty": {"low": 5000, "high": 45000, "best": 25000},
      "pdThirdParty": {"low": 7000, "high": 10000, "best": 9000}
    },
    "contactPlan": [
      {"party": "Insured", "method": "Phone", "slaHours": 24, "owner": "[Adjuster Name]"},
      {"party": "ThirdParty", "method": "Letter+Phone", "slaHours": 48, "owner": "[Adjuster Name]"},
      {"party": "VehicleInspection", "method": "Tractable", "slaHours": 72, "owner": "[Adjuster Name]"}
    ],
    "subrogationPotential": {
      "applicable": true,
      "rationale": "Third-party at-fault per police report; subrogation recovery from third-party carrier likely after collision payment."
    },
    "renewalImpact": {
      "withinRenewalWindow": true,
      "daysToRenewal": 21,
      "notes": "Claim affects underwriting in renewal review."
    },
    "aiAssisted": {
      "promptVersion": "adjuster_v2.7",
      "modelVersion": "claude-3.5-sonnet-2026-05",
      "humanReview": true,
      "reviewerName": "[Adjuster Name]",
      "reviewerSignDate": "2026-05-28T14:30:00Z"
    }
  }
}

The schema includes an "aiAssisted" object documenting AI prompt version, model version, and human-review attestation - supporting NAIC §4 governance and Colorado Reg 10-1-1 algorithm-inventory requirements at the file-note level. The discipline preserves chain-of-custody at the per-record level; aggregate inventory entries reference the per-record metadata.

Duck Creek, Sapiens, Majesco Platform Variations

Duck Creek operates with its own data model and API conventions; Sapiens uses a different model; Majesco a third. The 2026 carrier operating on multi-platform infrastructure (some lines on Guidewire, others on Duck Creek, legacy on Sapiens or Majesco) maintains separate schemas per platform per artifact. The AI system prompt and few-shot examples may be platform-agnostic; the structured-output schema is platform-specific.

Duck Creek tends toward XML for product-data operations and JSON for transactional APIs; Duck Creek's product-modeling layer (the "Authoring" environment) accepts specific XML schemas for product definitions. Sapiens (formerly StoneRiver and Insure Technology Services) operates with JSON-XML hybrid in different modules - claims, billing, policy administration. Majesco's modules operate with JSON APIs and increasingly with GraphQL endpoints in their 2026 platform releases. The carrier's platform-specific integration team maintains the schema-per-platform-per-artifact matrix; AI integration designs against the platform-specific schemas; mature carriers operate multi-platform integration as standard discipline.

Applied Epic, AMS360, Vertafore Agency Management Systems

Agency management systems (AMS) - Applied Epic and AMS360 (both Applied Systems products since 2017 acquisition consolidated under Applied) and Vertafore (parent of AMS systems including Vertafore AMS, Sagitta, BenefitPoint) - accept structured data through their respective APIs. The integration patterns: Applied Epic uses Activity logs and Account Notes as structured-data targets; AMS360 uses Notes and Memos; Vertafore uses Documents and Memos. JSON or XML structures map to the AMS data models; carrier-specific implementations vary.

A simplified Applied Epic activity-log JSON structure:

{
  "activity": {
    "accountId": "[Epic Account ID]",
    "activityType": "ProducerNote",
    "subject": "Submission Summary - [Carrier Name] - [Effective Date]",
    "createDate": "2026-05-28T11:00:00Z",
    "createUser": "[Producer Name]",
    "categoryCode": "SubmissionPrep",
    "priority": "Standard",
    "narrative": "[Submission summary content in markdown or HTML format mapping to Epic's narrative field]",
    "linkedDocuments": [
      {"docId": "[Doc ID]", "name": "ACORD 125 - Application.pdf"},
      {"docId": "[Doc ID]", "name": "ACORD 140 - Property Section.pdf"},
      {"docId": "[Doc ID]", "name": "5-Year Loss Run.pdf"}
    ],
    "aiAssisted": {
      "promptVersion": "producer_v4.1",
      "modelVersion": "claude-3.5-sonnet-2026-05",
      "humanReview": true,
      "reviewerName": "[Producer Name]"
    }
  }
}

The AMS integration discipline: producer creates submission summary using AI-assisted producer prompt; AI emits structured output; integration layer creates Activity in Applied Epic with the narrative content, linked documents, and AI-assistance metadata; the activity becomes the persistent account record. The producer's review and personal signature in the carrier's market-access cycle relies on the activity record. Mature agencies operate AMS integration as standard discipline; immature agencies operate AI generation outside AMS and accumulate fragmented account records.

Actuarial Pipeline (R, SAS, Python) CSV Integration

Actuarial pipelines run in R, SAS, or Python for triangle development, IBNR estimation, cat-model integration, rate-filing analytics, and reserve commentary. CSV format remains the workhorse interchange for tabular data between AI generation and actuarial pipeline. A simplified development-triangle CSV structure:

accident_year,development_month,cumulative_paid,cumulative_incurred,case_reserves,paid_to_incurred
2017,12,1250000,2100000,850000,0.595
2017,24,1850000,2400000,550000,0.771
2017,36,2150000,2580000,430000,0.833
2017,48,2350000,2680000,330000,0.877
2017,60,2480000,2730000,250000,0.908
2017,72,2580000,2770000,190000,0.931
2017,84,2660000,2800000,140000,0.950
2017,96,2720000,2820000,100000,0.965
2018,12,1380000,2280000,900000,0.605
2018,24,2010000,2580000,570000,0.779

The CSV's discipline: column headers in snake_case for R / Python pipeline ingest; numeric values as raw numbers without commas; date fields as ISO 8601 if used; rows in development-month-within-accident-year order for chronological processing. R reads via read.csv; SAS via PROC IMPORT; Python via pandas.read_csv. The format is universally portable. Mature actuarial operations maintain CSV schemas per artifact (triangle, rate-filing-exhibit, cat-model output, reserve-recommendation summary); each schema feeds downstream pipeline scripts.

Negative Constraints: Forbid the Failure Modes

Structured output requires negative constraints - explicit instructions to the model about what it must not emit. The 2026 production patterns:

Forbid protected-class proxies. The model never emits race, ethnicity, religion, national origin, sex, marital status, sexual orientation, gender identity, age outside the actuarially supportable range, or disability as fields in any structured output. The model never emits proxies that correlate with these attributes (BISG-estimated demographics, neighborhood demographic compositions, surname inferences) as inputs to underwriting or claim decisions. The constraint addresses NAIC §4, Colorado Reg 10-1-1, NY DFS Circular Letter 2024-7 expectations.

Forbid fabricated form numbers. The model never emits a form number that does not correspond to a real ISO/AAIS or carrier-specific form. The model emits only forms documented in the carrier's filed product library or referenced in the source documents. If a form is unknown, the model emits a flag for human verification rather than fabricating. The constraint addresses the phantom-endorsement problem.

Forbid coverage opinions without citation. The model never emits coverage conclusions without citation to specific policy language. Coverage opinions in structured output fields include the form, edition, section, and verbatim quotation of the relevant policy language. If language cannot be cited, the field is marked for human review rather than asserted. The constraint addresses the hallucinated-coverage-opinion problem.

Forbid fabricated case law and regulatory citations. The model never emits citations to court cases or regulatory provisions that do not exist. Citations include specific case name, court, year, citation format and link to verifiable source. Regulatory citations include statute or regulation section with current effective text. If citation cannot be verified, field is flagged.

Forbid medical-information disclosure beyond authorization scope. The model in L&H or claim workflows never emits PHI beyond what the applicant/claimant authorization covers. The model operates only within HIPAA-eligible environment with executed BAA. The model never exports PHI to non-HIPAA-eligible destinations including consumer-grade tools.

Each negative constraint is explicit in the system prompt; the structured output schema reinforces the constraints through schema-level validation; the integration layer rejects outputs failing schema validation. The cumulative discipline produces audit-credible AI integration; carriers operating without explicit negative constraints accumulate failure-mode exposure that surfaces during examinations or litigation.

Schema Governance and Version Stamping

Each schema is filed-equivalent infrastructure under NAIC §4 and Colorado Reg 10-1-1: documented, versioned, cross-functional reviewed, CCO countersigned, registered in the carrier's algorithm-inventory framework. The schema registry: schema ID, name, target system (Guidewire PolicyCenter / ClaimCenter / Duck Creek / Sapiens / Majesco / Applied Epic / AMS360 / Vertafore / R-pipeline / SAS-pipeline / Python-pipeline); version; effective date; cross-functional approvals (chief underwriter or chief claim officer or chief actuary or chief medical director as applicable, CCO governance); change rationale; rollback path. Schema updates follow change-control discipline: proposed change → cross-functional review → CCO countersign → version-stamp update → algorithm-inventory entry refresh → deployment.

The 2026 mature carrier operates schema governance as routine; immature carriers operate ad-hoc schemas that drift and accumulate integration defects. Examiner reviews of AI governance increasingly extend to schema documentation; rating-agency dialogue on operational discipline references schema governance; reinsurance treaty discussions on cedent operational maturity may reference schema discipline as evidence of governance posture. The investment is structural; the return compounds across regulatory, rating-agency, and treaty cycles.

Key Takeaways

• Structured output is the bridge between AI generation and the carrier's downstream tech stack: Guidewire PolicyCenter / ClaimCenter, Duck Creek, Sapiens, Majesco for P&C platforms; Applied Epic, AMS360, Vertafore for agency management; Vlocity/Salesforce FSC for carrier CRM; R, SAS, Python for actuarial pipelines. Eliminates manual integration overhead at scale.
• Operational multiplier at $2B P&C carrier processing 600-1,200 FNOLs daily: 15-30 adjuster-minutes saved per claim through ClaimCenter integration translates to 150-600 adjuster-hours per day. Savings recur daily; schema-design investment is one-time per artifact; cumulative leverage builds quarterly.
• Guidewire PolicyCenter submission ingest JSON schema maps every field to PolicyCenter data-model attribute: classification triad with NAICS/SIC/ISO GL Class Code; ISO 8601 dates; numeric monetary values; enumerated values from PolicyCenter controlled vocabulary; arrays for repeating structures.
• ClaimCenter file-note JSON schema includes coverage flags with form-edition citations, reserves recommendation ranges, contact plan with SLA timing, subrogation potential, renewal impact, and 'aiAssisted' metadata documenting prompt version, model version, human review attestation. Supports NAIC §4 and Colorado Reg 10-1-1 at file-note level.
• Platform variations: Duck Creek XML for products + JSON for transactions; Sapiens JSON-XML hybrid; Majesco JSON + GraphQL. Multi-platform carriers maintain schema-per-platform-per-artifact matrix.
• Agency management systems (Applied Epic, AMS360, Vertafore) accept structured data through Activity logs and Account Notes APIs. Producer-side AI integration creates persistent account records; mature agencies operate AMS integration as standard.
• Actuarial pipelines (R, SAS, Python) integrate via CSV with snake_case columns, raw numeric values, ISO 8601 dates, chronological row order. Mature actuarial operations maintain CSV schemas per artifact (triangle, rate-filing-exhibit, cat-model output, reserve recommendation).
• Five categorical negative constraints: forbid protected-class proxies; forbid fabricated form numbers; forbid coverage opinions without citation; forbid fabricated case law/regulatory citations; forbid PHI beyond authorization scope or outside HIPAA-eligible environment. Schema-level validation reinforces; integration layer rejects schema failures.
• Schema governance is filed-equivalent infrastructure: documented, versioned, cross-functional reviewed, CCO countersigned, algorithm-inventory registered. Mature carriers operate as routine; immature operate ad-hoc and accumulate integration defects that surface during examinations.