# View Contracts at the intensionality boundary

## Conclusion

Tree Calculus does not support the abstraction theorem that the former
parametric View design assumed. Views can remain useful as boundary metadata and
as instructions for runtime guard placement, but they must not be presented as
types, proofs of parametricity, or representation-hiding abstraction.

## Fundamental conflicts

### Raw observation defeats representation independence

A parametric contract such as:

```text
forall a. a -> a
```

normally relies on code being unable to learn anything about `a`. A Tree
Calculus term can inspect the tree supplied at `a`, distinguish
representations, and return a representation-dependent value. The View variable
does not hide or seal that tree.

The same breaks existential abstraction. Advertising a payload as
`exists repr. ...` changes no operational capability: a client can still
inspect the representation directly.

### Opaque payloads are asserted, not checked

A typed-value node carries an executable tree beside a View. Metadata validation
deliberately treats that executable field as opaque. Consequently, accepting a
node proves that the envelope and View are well formed; it does not prove that
the tree denotes the advertised `Fn`, `List`, `Maybe`, or other structural
View.

Provenance labels do not change this. `Checked` and `Trusted` record where an
assertion came from, but neither is a derivation that another implementation can
replay to establish the assertion.

### Syntactic taint is not a semantic parametricity proof

Rejecting direct uses of `t` or `triage` is neither complete nor a stable
soundness boundary:

- an observer can be assembled after reduction;
- observation can arrive through higher-order or dynamically selected code;
- unknown external code can hide observation;
- absence of a rule-3 redex is not reduction-closed;
- exact detection would subsume non-trivial termination/reachability questions.

A conservative taint pass can define a programming convention, but it cannot
justify the parametric or abstraction guarantees previously attached to Views.

### Flow checking only checks represented flow

The checker sees frontend-emitted value, application, and requirement nodes. It
can check consistency among those nodes, but it cannot establish that the graph
faithfully represents every use performed by the opaque executable payload.
This is useful artifact validation, not whole-program typing.

## Retained contract

The reduced checker may soundly claim only:

1. View, node, and program envelopes satisfy their declared data schemas.
2. Explicit monomorphic View facts are propagated consistently through the
   represented application graph.
3. A `Guarded` View causes its executable predicate to run at represented
   boundaries, and guard failure prevents checked execution.
4. Content-addressed references prevent an attached View artifact from silently
   drifting to a different stored object.

Items 1, 2, and 4 establish metadata integrity, not semantic membership in an
unguarded View. Item 3 is the only retained mechanism that observes an ordinary
runtime value.

## Code direction

The initial rollback therefore:

- removes View-variable instantiation, substitution, and unification from the
  portable checker;
- rejects `Var`, `Forall`, and `Exists` as checker inputs while reserving
  their legacy tags for deterministic decoding;
- removes the frontend raw-intensionality taint pass;
- removes polymorphic stdlib annotations and value-level View facts;
- retains monomorphic View flow, artifact plumbing, diagnostics, and executable
  guards.

Further simplification should treat unguarded structural Views as descriptive
labels. If stronger guarantees are desired later, they require an operational
mechanism such as runtime recognizers/seals or a genuinely restricted language
whose evaluator enforces the restriction. Metadata provenance alone is
insufficient.