Know exactly which code you mean

A name is convenient for people. An exact identity is useful when you need to know which code ran. Septa uses content addressing so a dependency selection can refer to specific content rather than relying only on a mutable name or version label.

This connects three activities that are often separate: selecting code, changing it and assessing evidence for it.

A pin identifies content

The original-library route derives a library pin from its canonical sources and dependency pins. A changed byte produces a different content pin. Aliases let people use convenient names while preserving an exact owner underneath.

Two versions can coexist when selected explicitly. That does not make their types interchangeable. Distinct owners can require an explicit conversion even when their data shapes look identical.

Different identities describe different things

Source, archive and executable bundle identities are related but answer different questions. An archive captures inputs and settings; a bundle identifies emitted executable artifacts. Tooling reports the context needed to interpret each one.

When reviewing a change, avoid treating any hash as a universal “version.” Ask what object it identifies and which relevant inputs participate in it.

Identity makes updates deliberate

A selected pin continues to name the same content. An update selects new content and becomes a reviewable change. You can examine the exported contract, effect surface, authority needs and compatibility implications before activating it.

Content addressing removes ambiguity about identity. It does not remove API compatibility, migration, dependency trust or release-planning decisions.

Evidence also needs an identity

A passing test is meaningful only for the inputs it actually consumed. Septa’s graph evidence records the captured source, case inputs and execution context. An applicability query compares those recorded inputs with the current graph.

An unrelated edit can preserve a particular case’s applicability. A changed relevant dependency can make it stale. Selected-case evidence cannot validate tests that were never run.

Integrity is not trustworthiness

An exact identity can reveal that bytes changed. It does not show that the original code was benign, that a publisher is authentic, or that a runtime was uncompromised.

Dependency review and scoped authority remain necessary. The useful combination is know which code is selected, make its effects visible, and limit what it can do.

Try code and evidence to see these identities in a working development loop.