← Files Date App PluginARCHIVED FILE
skills/interpret-property-map/references/property-map-schema.md
4.01 KB · Oct 4, 2026 · 12:31 UTC
# Property Map Contract
## Supplied payloads
The application supplies two labeled JSON blocks:
```text
Match record:
{ ... }
Schema interpretation Wiki:
{ ... }
```
The Match record is canonical raw application data. The Wiki is a reduced map
containing only non-empty explanations relevant to the current Match.
## Wiki shape
```json
{
"fields": {
"details.communicationStyle": {
"description": "How I interpret communication style.",
"values": {
"big_time_texter": "Good for me because I prefer frequent texting."
}
}
},
"checklist": {
"checklist.family-plans": {
"label": "Family plans",
"description": "Different family plans are a deal breaker for me."
}
}
}
```
### Fields
Each `fields` key is a JSON-style path into Match:
- ordinary segments address object properties, such as `details.job`;
- a segment ending in `[]` addresses every array item, such as
`messages[].kind`;
- `description` explains the property in general;
- `values` maps exact raw option values to value-specific explanations.
The application already removes value explanations for options not observed in
the current Match. The skill must still require exact equality and must not use
a sibling option's explanation.
`details` values are strings. A list-like form value such as interests may be
serialized into one comma-separated string; do not split it into independently
assessed values unless the Wiki or current task explicitly defines that
interpretation.
### Checklist
Each Wiki checklist key is `checklist.<id>`. Resolve `<id>` against the exact
`id` in `match.check_list[]`:
```json
{
"id": "family-plans",
"label": "Family plans",
"answer": "Does not want children"
}
```
The resulting interpretation keeps the answer as raw data and the Wiki text as
the user's assessment. A checklist explanation never supplies a missing answer.
## Reading assessment language
Wiki input is free text rather than a structured rating. Extract an assessment
only from explicit wording and preserve its reason and scope.
Examples:
| Wiki explanation | Assessment | Correct reading |
| ---------------------------------------------------- | ------------- | ------------------------------------------------------------------- |
| “Good for me because I prefer frequent texting.” | `positive` | Private user preference with a stated reason. |
| “Bad fit if she expects daily calls.” | `negative` | Conditional negative assessment, not a fact about her expectations. |
| “This is neutral; it does not affect compatibility.” | `neutral` | No directional weight. |
| “Fun socially, but incompatible with my routine.” | `mixed` | Preserve both sides; do not collapse to positive or negative. |
| “This is a deal breaker for me.” | `blocker` | Explicit hard constraint for the user. |
| “Shows the app where we matched.” | `unspecified` | Semantic explanation only; no preference stated. |
Words such as “good” and “bad” describe fit with the user's preferences. They
do not establish morality, quality as a person, diagnosis, future behavior, or
certainty about relationship outcomes.
## Resolution examples
Given:
```json
{
"details": { "communicationStyle": "big_time_texter" }
}
```
and the Wiki example above, the interpreted entry is conceptually:
```json
{
"path": "details.communicationStyle",
"rawValue": "big_time_texter",
"meaning": "How I interpret communication style. Good for me because I prefer frequent texting.",
"assessment": "positive",
"reason": "I prefer frequent texting.",
"confidence": "explicit",
"disclosure": "private"
}
```
Do not replace `big_time_texter` in the Match record, claim that frequent
texting is objectively good, or tell the match about this assessment by default.
SHA-256: fc5ec9cfd831ebd1b84a576daf7c5ec7952fc61bd977b55b344d6fd56c5a4546