> For the complete documentation index, see [llms.txt](https://docs.lpp-minduniverse.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lpp-minduniverse.org/lingua-pactum-protocol-lpp-documentation/5.-lpp-admission-kernel/5.2-admission-request.md).

# 5.2 Admission Request

An **Admission Request (AR)** is the structured request submitted to Layer 0 for evaluation.

It represents an AI-triggered statement or Action Candidate that has reached the point where constitutional admissibility must be determined.

The published formal operational semantics define the baseline Admission Request as:

```
AR = {
    subject,
    model_id,
    agent_id,
    intent,
    target,
    action_type,
    requested_scope,
    context_hash,
    source_refs,
    timestamp,
    environment,
    risk_claim
}
```

These fields serve different governance purposes.

#### subject

Identifies the principal associated with the request.

This may correspond to a:

* user,
* service,
* organization,
* workload,
* or agent.

Identity alone does not establish authority.

#### model\_id

Identifies the model that generated or materially contributed to the Action Candidate.

This supports responsibility reconstruction.

#### agent\_id

Identifies the agentic process, where applicable.

In multi-agent systems, model identity and agent identity may not be identical.

#### intent

Represents the stated purpose associated with the request.

In GitBook v2.0, this baseline field must be interpreted together with the more explicit upstream model introduced in Chapters 3 and 4:

```
Human-Authorized Intent
        ↓
Authority–Intent Binding
        ↓
Canonical Intent Commitment
        ↓
Execution Intent
```

The raw `intent` field alone must therefore not be treated as equivalent to authoritative human intent.

#### target

Identifies the system, object, resource, account, environment, device, or other target affected by execution.

#### action\_type

Defines the type of consequential operation proposed.

Examples may include:

* writing data,
* modifying configuration,
* transferring assets,
* invoking privileged tools,
* sending an official communication,
* or controlling a physical system.

#### requested\_scope

Defines the authority boundary requested by the Action Candidate.

The kernel compares this against the legitimate scope carried by the applicable Authority Object.

#### context\_hash

Binds the request to its relevant context.

This helps prevent the same request representation from being silently detached from the context under which it was evaluated.

#### source\_refs

References relevant evidence or source material.

Source provenance may come from systems such as SourceMind or other external evidence infrastructure.

#### timestamp

Establishes the admission-request time.

Time matters because authority and Permits are lifecycle-bound.

#### environment

Identifies the execution or deployment environment.

An action admitted for:

```
sandbox
```

must not silently become:

```
production
```

without satisfying the corresponding governance requirements.

#### risk\_claim

Represents the upstream declared risk or consequence characterization.

The kernel does not permit an action-producing model to lower its own mandatory governance floor.

#### v2.0 Admission Input Model

GitBook v2.0 therefore treats the Admission Request as the structured carrier into the kernel, while the complete admission state may reference additional governance objects such as:

* Authority Object,
* Human-Authorized Intent,
* Authority–Intent Binding,
* Canonical Intent Commitment,
* Semantic Verification evidence,
* SVNN evidence where required,
* and applicable policy / constitutional state.

The final public interface schema is defined separately in the Appendix.

***

###