# Trust is a flag on text, and plain `String` means trusted

## Decision

Untrusted text is written as `Untrusted<String>`. Despite the syntax, it is **not** a generic wrapper type. The checker tracks it as a trust flag on text types, using one-way flow (the same mechanism that stops a `cap fn` from flowing into a `fn`):

- Trusted text may flow into any slot that accepts untrusted text. Untrusted text may never flow into a trusted slot.
- Prelude text operations follow trust automatically. If any text input is untrusted, every text type in the result is untrusted. Results that are not text (`Int`, `Bool`, …) are trusted.
- In user code, a `String` parameter, field, or return type means **trusted**. Code that accepts raw input must say so by declaring `Untrusted<String>`. User functions are explicit about trust: they cannot be generic over it.

## Why

A real `Untrusted<T>` wrapper type would have two costs:

- every text method declared twice
- a way to accept trusted `String` wherever untrusted text is allowed

Oska has no subtyping and no overloading, so the second cost alone would rule it out: `Path.from` could not accept both kinds of text.

A trust flag gives the behavior the design describes ("converting to a non-text type makes it trusted") directly, with nothing duplicated. Treating plain `String` as trusted makes every ordinary text slot a **structural position** by default. Accepting raw input becomes visible in the signature, as principle 3 requires.

## Considered options

- **A generic wrapper type.** Rejected because it duplicates the text API and needs subtyping.
- **`String` means untrusted by default.** Rejected because it would be secure only if every structural parameter were annotated, and a single forgotten annotation would let untrusted text through.

## Consequences

- **Trust assertions.** A validator turns untrusted text into trusted text by calling `.assume_trusted()`. This is a **trust assertion**: it is listed as an **audit site**, alongside `Secret.expose()`.
- **Inspection is free.** Checks that produce non-text results (`len`, `contains`, `parse_int`, matching against literals) need no trust assertion.
- **Some functions need two versions.** A user function that works on text may need both a trusted and an untrusted version. If that becomes painful, a trust-generic parameter could be added later, and adding it would not break existing code.