A living memory of software interfaces

Software changes. Lapisa remembers.

Every release leaves a trace. Lapisa preserves what software exposed, follows how those surfaces evolve, and turns that history into compatibility evidence people and machines can act on.

Quiet decisions

Let safe updates move quietly.

A maintainer should not have to relive the bot's uncertainty. Lapisa keeps the reasoning available, while making the next action unmistakable.

Lapisa preserves the surfaces. SACUBA delivers the verdict: Safe, Caution, Unknown, or Breaking.

dependency updatecurrent head
  • Safe — Ready to mergeNo affected usage found in the measured boundary.
  • Caution — Review one behaviorOne specific decision remains.
  • ?
    Unknown — Review as usualLapisa cannot recommend; evidence is incomplete.
  • ×
    Breaking — Close for nowAn interface used here was removed.
View evidence for this decision

Surface change, repository exposure, coverage boundary, and provenance stay available without crowding the action.

Versioned surfaces

A memory of software, not merely a diff.

  • surface.symboladdressable names and exports
  • surface.signatureparameters, returns, and types
  • change.relationappeared, moved, renamed, removed
  • evidence.originrelease, source, tool, and coverage
v1.0 · release
Appeared
v2.1 · release
Renamed
v3.9 · release
Moved
v4.7 · release
Removed

The Lapisa horizon

One memory. Four ways to use it.

Today we begin with Python dependency decisions. Over time, the same evidence becomes a public archive, a machine-readable intelligence layer, and private organizational memory.

  1. L0Quiet dependency decisions

    Contextual verdicts, with detail reserved for the few updates needing attention.

  2. L1Public interface archive

    Versioned surfaces to look up, compare, and revisit.

  3. L2Compatibility intelligence

    Evidence that tools, agents, and the SBOM ecosystem can query.

  4. L3Private organizational memory

    On-premise knowledge of internal interfaces and exposure.

Early stage

Built with maintainers, on real updates.

We are starting with Python.

We are looking for a small group of design partners who want calmer dependency work and will help shape where evidence must be strongest.

Fit 01

Maintain active Python projects.

Your project sees real dependency movement, not a synthetic benchmark.

Fit 02

Face update queues and trade-offs.

You want attention reserved for the few changes that truly need it.

Fit 03

Care about false confidence.

You value honest evidence boundaries as much as speed.

Leave better evidence for the software that comes next.

Software changes. Its observable history should not disappear with the release that replaced it.