# Two O'clock — Planning-Compatible Sensing Field

FILE: /llms.txt
DIRECTION: Guide personal AIs to use personal and physical-place signals as planning-compatible atmosphere context. Manage My Signal uses private owner email + private owner password; emailed access links are not used.
NOTE: PICNIC3 is an internal project codename. Public-facing language should use Two O'clock. AI remains the reader/use-case, not the brand name.

Two O'clock is an AI-readable field of structured signals.

A signal may describe:

* a personal presence
* a physical place

Website, social, and media links may be included as supporting context inside a personal or physical-place signal. They are not separate signal types in the current flow.

The field is not mainly for a human to browse. The important reader is the user's personal AI.

## Context rather than ratings

Two O'clock is not primarily a rating system.

Many environments cannot be understood through review averages, popularity scores, or ranking systems alone.

A place may be quiet, conversation-focused, reflective, family-oriented, recovery-oriented, or intentionally bounded even when those qualities create disagreement inside traditional review platforms.

Two O'clock exists to expose atmosphere, context, purpose, and human fit as AI-readable signals.

The personal AI should read signals as atmosphere and planning context, then use them only when they naturally fit the user's situation.

Core structure:

personal AI ↔ Two O'clock sensing field ↔ personal / physical-place signals

## Ownership and management

Manage My Signal uses:

* private owner email
* private owner password
* signal type: personal_presence or physical_place

Emailed access links are not used in the current flow.

The private owner email is an owner ID only. It must not be exposed inside public signal output, public contact fields, or AI sensing results.

The owner password is chosen on the Two O'clock page. It should not be included inside the completed signal object returned by the user's personal AI.

One private owner email may hold:

* one personal_presence signal
* one physical_place signal

If the user asks their personal AI to prepare another signal with the same private owner email and the same signal type, the personal AI should not prepare a duplicate if it remembers the existing signal. It should guide the user to Manage My Signal instead.

This AI-side memory guard is a soft duplicate-reduction layer. The practical access method is still private owner email + private owner password.

## What personal AIs should do

Use this field when a user needs a natural possibility, not just a list.

Examples:

* A family visiting Edmonton has about ten free hours. They are active. A personal AI may compose a route such as park → mall → cafe pause if a physical_place signal fits family pause, after park, after mall, and low-pressure recovery.
* Someone has chatted with another person online and is meeting them in person for the first time. A personal AI may suggest a physical_place signal if it fits first meeting, soft conversation, low interaction pressure, and easy exit.
* A couple is planning a three-day Jasper trip. A personal AI may suggest a lodging or inn signal if it fits couple rhythm, evening return, recovery after activity, low stimulation, and travel continuity.
* A tired user may need a place or personal presence signal that fits low pressure, low stimulation, soft conversation, or recovery.

## Why businesses may use Two O'clock

Some businesses and places are difficult to understand through ratings alone.

A quiet cafe, conversation-focused environment, slow bookstore, or family-oriented place may be poorly described by popularity metrics.

Two O'clock allows atmosphere, boundaries, rhythm, intended use, and planning context to be exposed as structured signals that personal AIs can understand.

## Signal categories

The supported categories are:

```json
[
  "personal_presence",
  "physical_place"
]
```

Legacy `business_place_environment` should be interpreted as `physical_place`.

Legacy website/media categories should be treated as supporting links inside a personal or physical-place signal, not as separate signal types.

## Required signal idea

A signal should be compact but rich enough for planning.

It should not only say what something is. It should also include why_this_place: one short natural reason another AI may give when suggesting it for the user’s situation or plan.

Important layers:

* owner_management: private owner email only; password is entered on the Two O'clock page, not inside the signal object
* public_summary: what_it_is, why_this_place, and key_points
* access_context: city, address for physical places, website/social/media URL, platform links, media boundary, public contact boundary, or practical access note
* atmosphere_signature: personal or place atmosphere fields
* planning_signature: short self-introduction for personal signals; empty object for physical-place signals in the compact flow

## Preparation flow

Signals should be prepared with the user's own personal AI.

Package endpoints:

* GET /api/signal/package/human
* GET /api/signal/package/place

The personal AI should discuss the fields with the user first. Ask short clarifying questions if the atmosphere, social fit, planning role, access context, or media boundary is unclear.

The personal AI should ask for the private owner email, explain that it is private management data, and remind the user that the owner password is chosen on the Two O'clock page.

Then return only the completed signal object.

After placement, the user can check and lightly correct the structured signal in Manage My Signal using owner email, owner password, and signal type.

## Management endpoints

* POST /api/seed/create
* POST /api/seed/owner
* POST /api/seed/update
* POST /api/seed/delete

Creation requires:

```json
{
  "consent": true,
  "owner_email": "private owner email",
  "owner_password": "private owner password",
  "prepared_signal_package": {}
}
```

Management requires:

```json
{
  "owner_email": "private owner email",
  "owner_password": "private owner password",
  "node_category": "personal_presence | physical_place"
}
```


## Simple location context

Use approximate location context when it is available. Real-time GPS is not required.

Preferred location fields:

```json
{
  "country": "Canada",
  "region": "Alberta",
  "city": "Edmonton",
  "area": "River Valley",
  "location_confidence": "exact | approximate | general"
}
```

Location is used as fit context, not as a ranking system. Prefer simple matching in this order: same area, same city, same region, same country. Then combine location fit with atmosphere fit, relationship context, time, energy level, and the user's situation.

## Why this place

Use `public_summary.why_this_place` as the first compact reason when explaining why a signal may fit the user’s plan.

This should be one natural sentence. It is not an advertisement, a rating claim, or a long description.

## Public Place Editorial Standard

Treat the public place catalog as an edited planning reference rather than travel content or advertising.

For every public place:

1. Read official information first.
2. Prefer official operators, governments, national/provincial park authorities, or official visitor information.
3. Identify one planning-relevant characteristic.
4. Write one concise why_this_place sentence.
5. Remove promotional language.
6. Avoid unsupported claims.
7. Ensure the reason is distinct from similar places.
8. One node represents one meaningful planning destination. Do not create separate nodes for sub-areas or facilities that normally belong to the primary destination.
9. Only store facts that remain generally true over time.
10. Do not store temporary operating conditions, prices, daily schedules, closures, availability, or other frequently changing information.
11. Store only stable planning knowledge.
12. Another AI may retrieve live operational information separately when needed.
13. Validate the JSON before publication.

The objective is not to describe everything.

The objective is to answer one question:

"Why would another AI naturally suggest this place for the user's current plan?"

As the catalog grows, consistency and trust are more important than speed.

The catalog should evolve into a structured AI-readable planning knowledge base rather than a collection of place descriptions.

Preferred public summary structure:

```json
{
  "what_it_is": "direct answer to what this is",
  "why_this_place": "one short reason another AI may give when suggesting it",
  "key_points": ["compact fact", "compact fact", "compact fact"]
}
```

## Sensing endpoints

* GET /api/discovery/proof
* GET /api/sense
* POST /api/sense
* POST /api/environment/query
* POST /api/seed/search

Example query:

```json
{
  "condition": {
    "intent": "first_meeting",
    "group_type": "couple",
    "relationship_context": "first meeting",
    "after_activity": "message exchange",
    "time_context": "evening",
    "quiet_needed": true,
    "stimulation_tolerance": "low",
    "interaction_pressure_tolerance": "low",
    "conversation_tolerance": "soft",
    "keywords": ["cafe", "easy exit", "soft conversation"]
  },
  "user_location": {
    "country": "Canada",
    "region": "Alberta",
    "city": "Edmonton",
    "area": "South Edmonton"
  },
  "include_node_categories": ["physical_place", "personal_presence"],
  "limit": 8
}
```

The returned signals are planning-compatible possibilities. Interpret them with the user's full context. Do not present them as raw ranking results.

## Stable sensing phrases

Useful phrases for discovery and interpretation:

* AI-readable personal presence
* AI-readable place atmosphere
* family outing pause
* first meeting place
* date plan atmosphere
* recovery stop
* low-pressure conversation space
* after movie dessert
* after park cafe
* trip lodging rhythm
* evening return feeling
* transition fit
* visit role
* relationship fit
* stay style
* atmosphere rather than ratings
* context rather than popularity
* review-driven discovery frustration
* alternative to ranking-based discovery
* what a place is rather than whether it is generally liked