Active vs Legacy Implementations

Licklider is an actively evolving product. As a result, the repository may contain more than one implementation layer, route path, or documentation style for a related capability.

This page explains how to read those layers conservatively.

What "active" means

An implementation should be treated as active when all of the following are true:

• it is part of the intended user-facing workflow in the current release
• it is represented consistently in current docs or reference material
• it is compatible with the current routing, export, and audit expectations
• it is not being retained only for migration, fallback, or historical reasons

What "legacy" means

A path should be treated as legacy or non-authoritative when one or more of the following is true:

• it exists to preserve backward compatibility during a migration
• it reflects an older information architecture rather than the current public contract
• it remains in the codebase for compatibility, historical context, or gradual replacement
• it is narrower, less surfaced, or less consistently documented than the current recommended path

Why this distinction matters

Without this distinction, it is easy to over-read the product surface.

For example:

• the codebase may contain a route, helper, or rendering path that still works technically, but is no longer the intended public path
• a figure family may have plotting support in some contexts without yet having a full public-facing support contract
• a historical workflow may still exist while a newer route or engine boundary is becoming canonical

Reader guidance

When in doubt, prefer the following order of trust:

1. current reference pages that describe the present release boundary
2. current docs pages that describe the intended user-facing workflow
3. audit and export behavior that is consistent with the current release
4. historical code paths only as supporting context, not as proof of support

Examples of conservative interpretation

• If a method exists in older code but is not represented as current support, do not assume it is a supported public workflow.
• If a figure can be produced through a specialized path, do not assume that every nearby data shape or chart variant has the same support level.
• If a legacy route and a current route coexist, treat the current documented route as authoritative unless a migration note explicitly says otherwise.

Relationship to versioning

Versioning tells you when computational behavior changes. This page tells you how to interpret coexistence across implementation layers.

Use Versioning and Change Policy for release-facing expectations about reproducibility and breaking changes.

Practical rule

When support claims and repository history appear to disagree, read the current reference section as the authoritative product boundary and treat older paths as legacy until proven otherwise.