KARL Core: enterprise memory begins when the file is created

Within a workflow supported by KARL Core, data, transformations and decisions are linked to resources as files are created, and their history is preserved beyond the boundaries of a Git repository.

T0: recording the origin, then following the changes

A file often begins its life well before its first delivery. It is born from a request, addresses a requirement, goes through several revisions and contributes to a result. Its final content only tells part of that journey.

The principle of memory built at the source is to start at T0, the moment the file is created within a workflow supported by KARL Core. The company can then record its identity, its first state and its link to the project. Subsequent events enrich this history: a new version, a move, a copy, a relationship with a test, integration into a delivery, or a retirement.

This continuity relies on a concrete condition: the operations concerned must go through KARL's governed functions or be transmitted through a suitable integration. A file created on an isolated workstation does not become visible merely by existing. If it later joins the tracked scope, prior history depends on what was actually available at import.

The promise can thus be stated precisely: preserve history as soon as it occurs within the covered scope, with an explicit origin for anything brought in from elsewhere.

Building memory during the work itself

A backup preserves data so it can be recovered. Depending on its scope, it can also keep versions, metadata and rich logs. These elements are valuable for restoring a state or analyzing the past.

The difficulty appears when one wants to deduce, after the fact, a business history that the sources did not fully record. Two versions of a document show a change. They are not always enough to explain its reason, the requirement concerned, the test that justified it, or the delivery that retained it.

The frequency of collection does not, on its own, settle this question. A history can be very detailed about files and incomplete about their relationships with the company's work. Conversely, a late collection can retrieve a complete prior history when the source genuinely kept it.

Coverage of information matters as much as the timing of its collection.

With KARL Core, the states and relationships recorded as work happens directly constitute the substance of memory. A requirement can be linked to a precise version, that version to a test result, and then to a delivery reference. Later consultation relies on these preserved associations.

The benefit is to reduce retrospective reconciliation and the uncertainty over its outcome. A missing relationship remains missing information; it is not turned into certainty because two files happen to look alike.

History follows the identity of the resource

A file's name and folder often change over the course of a project. Durable memory must keep a reference point more stable than its location.

KARL Core distinguishes the resource from its access paths and the sources that designate it. Within supported operations, a rename or a move preserves its identity. A copy becomes a distinct resource whose provenance can be tracked. A correction to an attribution keeps a trace of the previous association.

This distinction makes it possible to trace a document's path after a reorganization and to tell an original apart from a customer adaptation. Two identical contents are not automatically treated as the same business resource.

“History follows the file” therefore means that states and events remain attached to the tracked resource, despite recorded changes of location. It does not mean that an exported copy spontaneously carries the whole memory into any external tool.

Git provides valuable visibility, within its scope

Git preserves the recorded states of a project and their history. It provides essential visibility into contributions and the evolution of versioned files. Its design distinguishes local work, the staging of changes, and their recording: creating a file on a workstation is not enough to enter it into the shared history.

Git documentation — What is Git? →

KARL Core has a built-in Git service, which can be enabled depending on the deployment, allowing it to receive contributions from a repository directly and integrate them into the project's traceability. A company can thus place KARL on the contribution path, without waiting for periodic collection from a third-party host.

For this path, server visibility begins with the contributions received. It does not automatically cover local changes that were never pushed. A strict start at file creation therefore requires an integration that also records that event.

Git is one of the entry points of memory. Other information can come from files stored outside the repository, production tools, test results, or documentation folders. Linking them requires the corresponding integrations and declarations. The value of KARL Core lies in being able to connect them within the same project scope.

An example: from the first file to equipment maintenance

Take Ateliers de l'Estuaire, a fictional company that manufactures packaging equipment. A new machine requires an adaptation of the cleaning procedure.

The company organizes the tracking of its resources and their relationships in KARL Core. The times below illustrate this journey; they are not performance measurements.

Read the diagram notation

flowchart LR
    A[Customer requirement] --> B[Procedure created at T0]
    B --> C[Software contribution received via Git]
    B --> D[Test report outside Git]
    C --> D
    D --> E[Procedure corrected]
    E --> F[Reference delivery]
    F --> G[Maintenance incident]

Diagram of the business relationships recorded in this example.

During the incident, the team wants to understand why the procedure changed and which versions accompanied the machine. It can consult the references kept for the delivery, find the associated test, and review the correction.

An isolated software repository would have provided the history of the program. A backup would have made it possible to retrieve the elements it had protected. The workflow organized in KARL Core also links the customer need, the procedure, the test, and the delivery.

The benefit comes from this continuity between business activities and sources.

From knowledge layer to enterprise memory

A knowledge layer makes information accessible and connects it. It gradually becomes an enterprise memory — a memory layer — when these relationships also preserve successive states, events, and the references needed to understand a past situation.

Time adds more than volume. Each new delivery, each correction, and each test enrich the workflows already documented. Applications that consult this memory can evolve without having to redefine the identity of resources or reinvent relationships already established.

This progression requires a discipline of contribution: recording useful events, linking the right versions, and preserving important justifications. Memory gains depth as its scope is fed; its completeness does not result from the mere passage of time.

A continuity to protect

Building memory as work happens avoids having to deduce, after the fact, relationships that were already recorded. Indexes or consultation views can nonetheless be rebuilt from the information kept. This technical operation is distinct from an attempt to recover a business context that was never captured.

Backup, replication, and disaster recovery remain necessary to protect this asset. KARL Core itself must also be operated with resilience measures suited to the deployment.

Its own contribution is to make memory begin with the work.

When creation, changes, and useful relationships are recorded from the outset, the company has a history it can consult, hand over, and enrich. It reduces its dependence on the late reconstruction of context and on the memories of the people who were present.