Complete architecture reference for the A3 insurance platform — file locations, data flow, conventions, microservice map, and fullstack patterns
日本語の概要は準備中です。原文の説明を表示しています。
Interactive demo: Generate pseudo-labels from a strong teacher model, build a cheap student function, and evaluate accuracy. Showcases pseudo-labeling and teacher-student distillation.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Build an AI function that routes insurance claims using pseudo-labeled training data.
Seed input-only data → pseudo-label with a strong teacher → build a cheap student function → evaluate. Estimated time: ~10 minutes.
Explain to user:
Welcome to the Pseudo-Labeling & Teacher-Student Distillation Demo!
At the end of this demo, you will witness the Cortex AI Function Studio's ability to:
- Generate pseudo-labels using a strong teacher model (no labeled data needed!)
- Build a cheap student model that reproduces teacher-quality decisions
- Evaluate how closely the student matches the teacher using the exact_match metric
This demo starts with unlabeled claim intake records. We will use a strong
teacher model to create routing labels, then build a cheaper student model
and measure how closely it reproduces those decisions.
Claim routes:
- fast_track_auto
- property_damage
- injury_review
- fraud_review
- documentation_needed
- manual_specialist_review
Objects created: all prefixed with DEMO_ for easy cleanup.
If {database} and {schema} are already known from the prerequisite flow, accept them silently and skip the prompt.
Otherwise, ask user:
Where would you like to create the demo objects?
Database: [e.g., TEMP]
Schema: [e.g., PUBLIC]
Store the database and schema for use throughout the demo.
Explain to user:
I'll load 80 realistic insurance claim intake records from a pre-generated set:
auto collisions, property damage, theft, injury, fraud, and documentation cases.
Columns:
- CLAIM_SUMMARY (pre-generated, unique per row)
- INCIDENT_CHANNEL
- CUSTOMER_SEGMENT
I'll create:
- {database}.{schema}.DEMO_CLAIMS_UNLABELED
Run the data generation script:
PYTHONPATH=<SKILL_DIRECTORY>/src uv run --project <SKILL_DIRECTORY> python <SKILL_DIRECTORY>/src/generate_claims_data.py load \
--connection <CONNECTION_NAME> \
--database {database} \
--schema {schema}
Note: Replace <SKILL_DIRECTORY> with the absolute path to the cortex-ai-function-studio skill directory, and <CONNECTION_NAME> with the active Snowflake connection.
Verify creation and confirm summaries are diverse:
SELECT COUNT(*) FROM {database}.{schema}.DEMO_CLAIMS_UNLABELED;
SELECT LEFT(CLAIM_SUMMARY, 150) AS SUMMARY_PREVIEW, INCIDENT_CHANNEL, CUSTOMER_SEGMENT
FROM {database}.{schema}.DEMO_CLAIMS_UNLABELED
LIMIT 5;
Present the pseudo-label configuration:
Now we'll use a strong teacher model to label each claim intake row.
Default teacher model: claude-opus-4-6 (or the strongest available Claude Opus variant)
Fallback: use the strongest available Claude-family model in the account
Source table: {database}.{schema}.DEMO_CLAIMS_UNLABELED
Input columns: CLAIM_SUMMARY, INCIDENT_CHANNEL, CUSTOMER_SEGMENT
Output fields:
- claim_route (string) — routing category
Destination table: {database}.{schema}.DEMO_CLAIMS_DATA
If the default teacher model is unavailable, load references/model_selection.md and choose the strongest Claude-family option.
MANDATORY: Do not synthesize labels ad hoc in this demo. Load synthetic-data/SKILL.md and follow the Pseudo-Label Input-Only Tables workflow.
Pass this context into that workflow:
source_table: {database}.{schema}.DEMO_CLAIMS_UNLABELEDinput_columns: ['CLAIM_SUMMARY', 'INCIDENT_CHANNEL', 'CUSTOMER_SEGMENT']output_table: {database}.{schema}.DEMO_CLAIMS_DATAmodel: {teacher_model}task_description: Classify each claim intake row into exactly one routing category: fast_track_auto, property_damage, injury_review, fraud_review, documentation_needed, or manual_specialist_review.output_schema: {"properties": {"claim_route": {"type": "string", "description": "One of: fast_track_auto, property_damage, injury_review, fraud_review, documentation_needed, manual_specialist_review"}}}preview_rows: 0The label-synthesis workflow must:
EXPECTED as the default label columnShow the label distribution after labeling completes:
SELECT EXPECTED:claim_route::STRING AS CLAIM_ROUTE, COUNT(*) AS ROWS
FROM {database}.{schema}.DEMO_CLAIMS_DATA
GROUP BY 1
ORDER BY ROWS DESC;
The pseudo-label workflow stores labels as a VARIANT column (EXPECTED). Since our output has a single field, convert it to a plain string column for evaluation:
ALTER TABLE {database}.{schema}.DEMO_CLAIMS_DATA ADD COLUMN EXPECTED_OUTPUT VARCHAR;
UPDATE {database}.{schema}.DEMO_CLAIMS_DATA SET EXPECTED_OUTPUT = EXPECTED:claim_route::STRING;
ALTER TABLE {database}.{schema}.DEMO_CLAIMS_DATA DROP COLUMN EXPECTED;
Present the function configuration:
Now we'll create a cheaper student model for claim routing.
Default student model: llama3.1-8b
Function name: DEMO_ROUTE_CLAIM
Inputs: CLAIM_SUMMARY, INCIDENT_CHANNEL, CUSTOMER_SEGMENT
Outputs:
- claim_route (string) — routing category
System prompt:
"You are an insurance claim routing system. Given a claim summary, incident
channel, and customer segment, classify the claim into exactly one route:
fast_track_auto, property_damage, injury_review, fraud_review,
documentation_needed, or manual_specialist_review."
User prompt template:
"Claim summary: {CLAIM_SUMMARY}\nIncident channel: {INCIDENT_CHANNEL}\nCustomer segment: {CUSTOMER_SEGMENT}"
⚠️ STOP: Wait for user confirmation before creating the function.
Load create/SKILL.md and follow it from Step 7 onward, passing:
database, schemafunction_name: DEMO_ROUTE_CLAIMfunction_intention: Route insurance claims to the correct processing track.model: chosen student modelinputs: [{"name": "CLAIM_SUMMARY", "sql_type": "VARCHAR"}, {"name": "INCIDENT_CHANNEL", "sql_type": "VARCHAR"}, {"name": "CUSTOMER_SEGMENT", "sql_type": "VARCHAR"}]outputs: [{"name": "claim_route", "json_type": "string", "description": "One of: fast_track_auto, property_damage, injury_review, fraud_review, documentation_needed, manual_specialist_review"}]system_prompt: confirmed promptuser_prompt_template: Claim summary: {CLAIM_SUMMARY}\nIncident channel: {INCIDENT_CHANNEL}\nCustomer segment: {CUSTOMER_SEGMENT}Return here after the smoke test succeeds.
Present the evaluation configuration:
Let's evaluate how well the student model routes claims.
Since the function returns a single claim_route string, the built-in
exact_match metric works perfectly — it compares the predicted route
directly against the teacher-labeled EXPECTED_OUTPUT.
Default metric: exact_match
Results table: DEMO_ROUTE_CLAIM_EVAL_RESULTS
⚠️ STOP: Wait for user confirmation before running evaluation.
Load evaluate/SKILL.md and follow it from Step 5 onward, passing:
function_name: {database}.{schema}.DEMO_ROUTE_CLAIMfunction_model: chosen student modeltest_table: {database}.{schema}.DEMO_CLAIMS_DATAinput_columns: ['CLAIM_SUMMARY', 'INCIDENT_CHANNEL', 'CUSTOMER_SEGMENT']label_column: EXPECTED_OUTPUTmetric: exact_matchresults_table: {database}.{schema}.DEMO_ROUTE_CLAIM_EVAL_RESULTSAsync by default: When the evaluate workflow reaches the execution mode selection, choose async (EVALUATE_AI_FUNCTION_ASYNC) without asking the user. If the async SPROC returns an error string (e.g., warehouse permission issue), inform the user and fall back to sync execution (EVALUATE_AI_FUNCTION) instead. After kicking off the async job, poll TASK_HISTORY() for completion within this session rather than asking the user to return later — this is a guided demo. Load references/async_status.md for polling patterns.
Skip Step 6 (next steps) in the evaluate workflow — return here after results are presented.
Once evaluation is done, review the results. Show the scores to the user. Offer to see what cases did not match:
Would you like to see which claims the function routed incorrectly?
If yes, query the results table:
SELECT
LEFT(INPUT_TEXT, 150) AS SUMMARY_PREVIEW,
EXPECTED AS EXPECTED_ROUTE,
PREDICTED AS PREDICTED_ROUTE,
SCORE,
FEEDBACK
FROM {database}.{schema}.DEMO_ROUTE_CLAIM_EVAL_RESULTS
WHERE SCORE < 1.0
ORDER BY SCORE
LIMIT 20;
Discuss common failure patterns. Explain that labels are teacher-generated (pseudo-labels), not human ground truth.
After reviewing results, continue to Step 7.
Ask user:
The Insurance Claim Routing demo is complete!
Would you like to clean up the demo objects?
This will drop:
- {database}.{schema}.DEMO_CLAIMS_UNLABELED
- {database}.{schema}.DEMO_CLAIMS_DATA
- {database}.{schema}.DEMO_ROUTE_CLAIM
- {database}.{schema}.DEMO_ROUTE_CLAIM_EVAL_RESULTS
⚠️ STOP: Wait for user confirmation before cleanup.
If yes, execute:
DROP TABLE IF EXISTS {database}.{schema}.DEMO_CLAIMS_UNLABELED;
DROP TABLE IF EXISTS {database}.{schema}.DEMO_CLAIMS_DATA;
DROP FUNCTION IF EXISTS {database}.{schema}.DEMO_ROUTE_CLAIM(VARCHAR, VARCHAR, VARCHAR);
DROP TABLE IF EXISTS {database}.{schema}.DEMO_ROUTE_CLAIM_EVAL_RESULTS;
Summarize the workflow: unlabeled data → teacher pseudo-labels → cheap student function → evaluation.
Explain to user:
You completed the pseudo-labeling and teacher-student distillation workflow:
1. Loaded unlabeled insurance claim intake records
2. Used a strong teacher model (Claude Opus) to generate routing labels
3. Built a cheaper student model to reproduce teacher routing decisions
4. Evaluated the student against teacher labels using exact_match
Key takeaways:
Pseudo-labeling: When you don't have labeled data, a strong teacher model
can generate high-quality training labels from your unlabeled data. This
is dramatically faster than manual annotation.
Teacher-student distillation: Once you have labels, you can train a cheap
student model that approaches teacher quality at a fraction of the cost.
Want to build richer evaluation metrics? Try the "Custom Evaluation Metrics" demo.
Want to optimize the student's prompt? Try the "Prompt Optimization" demo.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Complete architecture reference for the A3 insurance platform — file locations, data flow, conventions, microservice map, and fullstack patterns
日本語の概要は準備中です。原文の説明を表示しています。
Drafts U.S. commercial real estate access and indemnity (right-of-entry) agreements for pre-closing due diligence. Covers license grants, non-invasive vs invasive testing gates, insurance/endorsement requirements, indemnity with discovery carve-outs, restoration and lien remedies, confidentiality, and anti-indemnity guardrails. Trigger: access agreement, right of entry, due diligence access, Phase I/II, invasive testing, pre-PSA site inspection.
日本語の概要は準備中です。原文の説明を表示しています。
当用户需要对意外险投保问卷进行专业、结构化的核保审查,提取职业类别、工作环境、作业内容、危险活动参与情况、交通出行习惯、特殊工作暴露及其他可能影响意外险承保判断的高风险信息,并生成适合意外险核保、补问流转和风险分层处理的结构化分析结果时使用本 skill。
日本語の概要は準備中です。原文の説明を表示しています。
Inspect, schema, and fill true AcroForm PDFs using sciClaw's pdf_form_inspect, pdf_form_schema, and pdf_form_fill tools. Use when: (1) checking whether a PDF is a real fillable AcroForm, (2) listing form field names, types, and choices, (3) filling a supported form from structured values, (4) preparing reviewable insurance, legal, administrative, or clinical form drafts, (5) reporting skipped fields or unused input keys after a fill. Do not use for scanned PDFs, OCR tasks, or XFA-only forms.
日本語の概要は準備中です。原文の説明を表示しています。
Guide actuarial analysis for insurance pricing. TRIGGERS - Use when user needs help with actuarial-analysis related tasks.
日本語の概要は準備中です。原文の説明を表示しています。
Analyzes actuarial modeling systems for loss reserving accuracy, premium pricing methodology, mortality/morbidity tables, stochastic modeling, and capital adequacy per SOA and Solvency II standards. USE THIS SKILL WHEN: - You need to review or audit actuarial models (reserving, pricing, capital) - Someone asks about loss triangle analysis or reserve adequacy - You are evaluating IBNR calculations, chain ladder methods, or Bornhuetter-Ferguson - A project involves insurance pricing, GLM rating models, or ratemaking - You need to assess Solvency II SCR calculations or RBC compliance - Someone mentions actuarial opinions, ASOP compliance, or SOA standards - You are reviewing stochastic models, ESG configurations, or DFA frameworks - A codebase uses actuarial libraries (chainladder, lifetables, ChainLadder R package) TRIGGER PHRASES: "actuarial", "loss reserving", "IBNR", "chain ladder", "premium pricing", "mortality table", "Solvency II", "capital adequacy", "ratemaking", "GLM pricing", "risk-based capital", "reserve analysis", "actuarial opinion"
日本語の概要は準備中です。原文の説明を表示しています。