Built with Claude · design in development

How AI Date uses Claude

This page describes the system we are building. AI Date is in development and has not launched; place-data integrations are planned and not live. Details may change.

Claude API 활용 방식(설계 기준)입니다. 앱은 개발 중이며 외부 장소 데이터 연동은 계획 단계입니다.

Architecture

System overview

1 · Planning request

Chat requestArea, time window, budget, preferences, mood
Planner serviceModel router, cached prompt prefix, tool allowlist
Claude · Messages APITool use; smaller model for parsing and swaps, larger model for full courses
Place toolssearch_places, get_place_details, get_alternatives, estimate_travel_time
Licensed place dataThird-party place-data APIs (planned, not live)

2 · Response

Course JSONStops, times, costs, reasons, alternatives
ValidationJSON schema, place IDs from tool results only, budget and opening-hours checks
AppRenders the timeline; swap a stop, open candidate details
Course-quality evalsOffline test set run on every prompt or model change
Grounding rule: every place shown must have a place_id that came from a tool result in the same session. Claude ranks, sequences and explains; it cannot add a venue that the tools did not return.
Claude APIOur codePlanned / not live yet

One planning request

What happens when you ask for a course

  1. Understand the request

    The planner sends the chat to Claude through the Messages API with a versioned system prompt (task, Korean dating context, constraints, output contract) and the tool definitions. A smaller Claude model can first turn free text into structured constraints: area, time window, budget, food preferences, mood.

  2. Search with tools

    Claude calls tools such as search_places (category, area, open-at time, price band), get_place_details and estimate_travel_time. Our server checks each call against an allowlist, queries the place-data source and returns a tool_result. The loop is capped.

  3. Build the course

    Claude picks and orders stops and returns JSON that must match the course schema: time, category, place_id, estimated cost, travel time and a one-line reason for each stop, plus alternatives.

  4. Validate

    The server validates the JSON against the schema, confirms every place_id came from a tool result in this session, and checks budget and opening hours. Failures are retried or flagged instead of shown.

  5. Swap and refine

    When a user swaps a stop, Claude receives the current course with the cached context and returns an updated course, re-checking timing, distance and budget. Candidate details (menu, price, reviews) are rendered from place data, not from model text.

Claude API design

The building blocks

Messages API

Understanding, planning and explanation all run through the Claude Messages API, with a versioned system prompt and a JSON output contract.

Tool use

Typed tools defined with JSON Schema let Claude query place data during planning. Tools are read-only and run on our server against licensed place-data APIs (planned).

Structured JSON

Every course follows a fixed schema and is validated server-side before the app renders it.

Prompt caching

System prompt, tool definitions and reusable reference text sit in a cacheable prefix, which lowers latency and cost for follow-up swaps.

Model routing

A smaller, faster Claude model (e.g. Haiku) handles parsing and single-stop swaps; a larger model (e.g. Sonnet) plans full courses and retries hard cases.

Course-quality evals

Sample requests across areas, budgets, times and moods, scored on schema validity, budget fit, hours, travel distance, preference match, grounding, and cost and latency per course.

search_places.json · illustrative
{
  "name": "search_places",
  "description": "Read-only search over licensed place data.",
  "input_schema": {
    "type": "object",
    "properties": {
      "area":     { "type": "string" },
      "category": { "enum": ["restaurant","cafe","activity","walk"] },
      "open_at":  { "type": "string", "format": "date-time" },
      "max_price_per_person": { "type": "integer" }
    },
    "required": ["area", "category"]
  }
}
course.json · fictional sample
// sample only; IDs and values are fictional
{
  "area": "Seongsu-dong",
  "window": "14:00-21:00",
  "budget_krw": 100000,
  "stops": [
    { "time": "14:00", "category": "activity",
      "place_id": "sample-001", "est_cost_krw": 40000 },
    { "time": "18:00", "category": "restaurant",
      "place_id": "sample-003", "est_cost_krw": 42000,
      "alternatives": ["sample-007", "sample-009"] }
  ],
  "total_est_krw": 96000
}

Quality, safety and data

Design principles

No invented places or reviews

Names, prices, menus and reviews shown in the app are designed to come from place-data sources with attribution, never generated by the model.

Licensed data only

We plan to use third-party place-data APIs under their terms and display attribution as required. We don’t plan to scrape sites that don’t allow it.

Data minimization

Planning needs an area and a time, not your identity. Precise location is optional, and chat history is kept only as long as the feature needs. See the privacy policy.

Content safety

User text is treated as a request and place data as untrusted input. Use stays within Anthropic’s Usage Policy, and age-restricted venues are only suggested to adults.

Built with Claude Code. Beyond the product runtime, our team uses Claude Code to write and refactor code, write tests and review changes, and Claude to draft prompts, eval cases and documentation. Every change is reviewed by a person before it ships.

Want to try it when a beta opens?

Email us and we’ll reply when there’s something to test. We won’t add you to a list without asking.

Email ushello@purifysec.com