---
id: LSN-0020
ticket: pbs-learn-to-discussion-lessons-migration
title: PBS Runtime Values, Identity, and Memory Boundaries Legacy Import
created: 2026-03-27
tags: [compiler, pbs, legacy-import, runtime, values, identity, memory]
---

## Context

Legacy import from `docs/compiler/pbs/learn/03. Runtime Values, Identity, and Memory Boundaries.md`.

This lesson preserves the runtime-facing mental model that keeps PBS lowering, diagnostics, and future optimization work aligned on aliasing, retention, and ownership.

## Key Decisions

### Value categories are explicit

**What:** PBS distinguishes copied payload values, identity-bearing values, and carrier-only values.

**Why:** Later lowering and diagnostics need a stable answer to whether a construct preserves aliasing, creates retention, or just transports an existing payload.

**Trade-offs:** The model is intentionally qualitative rather than layout-specific, which keeps it stable but less byte-accounting-friendly.

### Host boundary semantics remain explicit

**What:** Host interaction is stack-only across the boundary, but host-backed resources still count as identity-bearing on the PBS side.

**Why:** PBS needs a clean boundary without pretending that host ownership disappears once a value crosses into language semantics.

**Trade-offs:** This is semantically clean, but it requires implementers to avoid naive “stack-only means no ownership complexity” shortcuts.

## Patterns and Algorithms

- Treat scalars as copied payload without user-visible identity.
- Treat structs, services, and host-backed resources as identity-bearing.
- Treat tuples, `optional`, and `result` as carriers that do not create identity of their own.
- Interpret cost visibility semantically:
  - allocation-bearing,
  - retention-bearing,
  - copy versus aliasing,
  - host-boundary crossing,
  - trap possibility.
- Keep future lifetime-control and concurrency surfaces out of `core-v1` unless explicitly claimed.

## Pitfalls

- Assuming carrier types create fresh identity.
- Confusing qualitative runtime guarantees with exact allocator or collector promises.
- Assuming stack-only host crossing eliminates host ownership concerns.
- Silently treating future-profile surfaces as current supported behavior.

## Takeaways

- PBS runtime contracts are qualitative on purpose.
- Identity, aliasing, and retention are the stable facts that matter most for maintenance.
- Host authority and PBS semantic identity can coexist without contradiction.