# Methodology

## 1. Purpose

LLM Ambiguity Lab v2 demonstrates a **two-layer control architecture**:

1. **DCRL Task Resolution** identifies the requested task and whether the task is sufficiently grounded.
2. **SANA Premise Alignment** maps the premises carried into that resolved task before a downstream execution layer would act.

Canonical URL: https://sana-os.org/llm-ambiguity-lab/

**Creator and responsible maintainer:** Deshimaru Sakaguchi

The public simulator is deterministic. It does not call an LLM API, inspect hidden model reasoning, or implement an objective truth engine.

## 2. Layer ordering

The canonical processing order is:

```text
User instruction
      ↓
DCRL Task Resolution
      ↓
Resolved task
      ↓
Premise mapping
      ↓
Premise Alignment policy
      ↓
Premise-aware execution handoff
```

Premise analysis is not a substitute for task resolution.

If Layer 1 produces either:

- `CLARIFICATION_REQUIRED`, or
- `PENDING_SPECIFICATION`,

Layer 2 is deferred until the operational task is sufficiently resolved.

## 3. Layer 1: DCRL Task Resolution

v2 keeps the following v1 output fields visible:

| Field | Meaning in the simulator |
|---|---|
| `context_resolution_score` | Illustrative operational score used by the deterministic task-resolution layer. |
| `resolution_state` | Current Layer 1 state. |
| `target_task` | Requested operation. |
| `target_object` | Object, artifact, topic, or process acted upon. |
| `context_grounding` | `grounded`, `partial`, or `ungrounded`. |
| `ambiguity_type` | `none`, `lexical`, `referential`, `intent_task`, or `mixed`. |

The Layer 1 score retains the v1 interpretation: it is not model confidence, a calibrated probability, or hidden reasoning.

## 4. Layer 2: Premise Alignment

Layer 2 asks a different question:

> What premises travel with the identified task?

It does not ask whether all premises are true, nor does it require participants to agree.

### 4.1 `FACT`

A proposition functioning as a claim about what is, was, or happened.

The classification is about the proposition's role in the task.

**Critical rule:** `FACT` does not mean independently verified truth.

### 4.2 `VIEW`

An interpretation, evaluation, causal framing, judgment, or explanatory perspective.

### 4.3 `CARE`

A concern, priority, protected interest, value, or outcome that matters within the task.

`CARE` is not treated as a factual proposition requiring proof.

## 5. Premise unit fields

The public v2 implementation uses the following premise representation:

| Field | Public values / role |
|---|---|
| `premise_id` | Local identifier such as `P1`. |
| `text` | Human-readable premise text. |
| `category` | `FACT`, `VIEW`, or `CARE`. |
| `source` | Where the premise entered the task. |
| `status` | How directly it is represented. |
| `materiality` | How much changing the premise could alter execution. |
| `support_state` | Current representational support status, not a truth probability. |
| `execution_effect` | How the premise changes the downstream task. |

### 5.1 Source values

The public vocabulary supports:

- `user_explicit`
- `user_implied`
- `provided_source`
- `system_default`
- `agent_inference`
- `unknown`

The current deterministic presets use a subset of these values. Free-text heuristics primarily distinguish explicit user wording from recognized source markers.

### 5.2 Status values

- `explicit`
- `inferred`
- `unclear`

### 5.3 Materiality values

- `low`
- `medium`
- `high`

Materiality is qualitative. v2 deliberately does not introduce a numeric premise-confidence score.

### 5.4 Support-state values

- `provided`
- `unsupported`
- `disputed`
- `unknown`
- `not_applicable`

These are representational labels used by the simulator. They are not universal truth verdicts.

### 5.5 Execution-effect values

The structured vocabulary includes:

- `none`
- `changes_scope`
- `changes_framing`
- `changes_output`
- `changes_recommendation`
- `requires_clarification`

The current presets primarily demonstrate `changes_framing` and `changes_recommendation`.

## 6. Premise alignment states

### `MAPPED`

Relevant premises are sufficiently represented for the simulated handoff.

This state does not imply that all premises are true, verified, or agreed upon.

### `MAPPED_WITH_DIVERGENCE`

Different framings or positions remain explicit, but the requested task can proceed while preserving and attributing them.

The default behavior is not to collapse them into synthetic consensus.

### `PREMISE_CLARIFICATION_REQUIRED`

A materially important premise is ambiguous, unsupported, or unclear in a way that changes how the requested output should be framed.

The simulator pauses the downstream handoff and generates a bounded clarification question.

### `PREMISE_CONTEXT_INSUFFICIENT`

A premise required to perform the task responsibly cannot be recovered from the available context.

The simulator requests the missing premise instead of inventing it.

## 7. Divergence

A `preserved_divergence` records two materially different framings plus the behavior the downstream layer should follow.

The canonical preset demonstrates:

```text
User framing: “The policy failed.”
Report framing: “The policy produced mixed outcomes.”
```

The prescribed behavior is to preserve and attribute both positions rather than merge them.

Divergence is not itself an error state.

## 8. Clarification policy

The simulator prefers a bounded question when a high-materiality premise treatment changes the output.

Canonical example:

> Should I present “leadership ignored the warnings” as an established fact, as the report's position, or as a claim attributed to the user?

The purpose is not to settle reality through wording. It is to determine how the downstream output should represent the premise.

## 9. Preset mode

The six presets are deterministic reference cases stored directly in the JavaScript implementation.

Exact-match preset input bypasses the free-text premise heuristic and returns its predefined result.

This makes the teaching cases reproducible.

## 10. Free-text mode

Free-text analysis is intentionally limited and illustrative.

### 10.1 Task-resolution signals

The current implementation recognizes a small set of task verbs including:

- summarize
- rewrite
- revise
- translate
- compare
- explain
- extract
- convert
- list
- analyze
- recommend

It also uses simple object and referential-expression patterns inherited from the v1-style task-resolution heuristic.

### 10.2 Premise signals

The current implementation uses limited lexical and structural patterns including:

- causal connectors such as `because`, `caused by`, and `therefore`;
- evaluative terms including `failed`, `unfair`, `ignored`, `successful`, `poor`, and `biased`;
- care-oriented expressions including `prevent`, `protect`, `avoid`, `accountability`, and `reduce risk`;
- source markers such as `the report says`, `according to the report`, `the user says`, and `according to the user`;
- contrast markers such as `while`, `whereas`, or `but` when an explicit source term is also present.

These patterns are demonstrations, not comprehensive linguistic rules.

## 11. Free-text premise-state rules

After Layer 1 resolves sufficiently, the illustrative premise layer follows this order:

1. If a referenced earlier assumption is unavailable under partial context grounding, return `PREMISE_CONTEXT_INSUFFICIENT`.
2. If contrasting attributed framings are detected, return `MAPPED_WITH_DIVERGENCE`.
3. If a high-materiality premise is `unsupported` or `unknown`, return `PREMISE_CLARIFICATION_REQUIRED`.
4. Otherwise return `MAPPED`.

The public implementation does not calculate a numeric premise score.

## 12. Premise-aware execution handoff

The displayed handoff object contains:

```json
{
  "resolved_task": {},
  "premise_map": [],
  "premise_alignment_state": "MAPPED",
  "unresolved_premises": [],
  "preserved_divergences": [],
  "assumption_disclosures": [],
  "execution_instructions": ""
}
```

The public simulator stops here. It does not execute the requested downstream task.

The machine-readable schema is published at [data/execution-handoff-schema.json](data/execution-handoff-schema.json).

## 13. No hidden truth or mind-reading layer

v2 does not provide:

- hidden chain-of-thought access;
- hidden motive inference;
- objective truth verification;
- a probability that a premise is true;
- a probability that a participant's interpretation is correct.

A premise map is a structured representation of the current instruction and supplied context, not a final judgment about reality.

## 14. Relationship to SANA OS

The Layer 2 design implements the SANA OS principle that premise alignment precedes analysis and that understanding is not agreement.

This public Lab is a reference implementation of that premise-mapping layer, not a complete implementation of every SANA OS component, persona, or structural framework.