🧠 Memory: What Makes Continuation Possible

on November 8, 2026

From software to AI, from video games to music and images: what we retain to continue creating.

Introduction

What needs to be preserved for something to continue? A decision whose reason has been forgotten, a calculation to revisit, a recognized melody: this question underlies development, gaming, and creation. In Darkwood, memory takes on different durations and supports. Some data accompany an operation and then disappear; others must remain understandable long after their creation. The experiences gathered in Darkwood Memory make these differences manipulable. They explore a common passage: keeping enough of the past to be able to decide on the future.

Darkwood — The Memory of Knowledge

Resuming a project often begins with an investigation. The code works, a document gives an instruction, a conversation hints at an abandoned solution. Yet, reasoning may be lacking. Why was this option chosen? Under what conditions was it valid? A team can keep its files and lose what would enable their use. For Darkwood, which connects software, infrastructure, automation, and AI, this context break is concrete: every resumption risks reopening a discussion that has already been settled.

A decision should be retrievable and understandable. A stable identifier provides it with an address that withstands changes in title. The date situates it within a state of the project. The origin indicates whether it comes from an observed constraint, a trial, or a preference. The history shows what has changed. This information transforms an isolated phrase into reusable knowledge. It also makes disagreement possible: one can reexamine a choice without erasing the path that led to it.

The Darkwood Memory workshop puts this principle on a small scale. The search for MEM-001 retrieves a fictitious decision regarding the preservation of musical motifs. The first version keeps only an audio output. The next also retains the notes, tempo, and parameters needed to create a variant. The change carries its date and its origin, both fictitious as well. Reading the two versions makes the second intelligible: one understands what the initial choice did not allow to be resumed.

This distinction is particularly important when an AI agent is involved in the work. A conversation contains trials, hypotheses, corrections, and sometimes no longer useful instructions. Keeping everything in the history does not indicate which passages still hold authority. The context transmitted to the agent must therefore designate the relevant references and their status. Retrieving an old message can help; retrieving a validated decision linked to its reasons and version provides a much more precise basis for action.

A search by proximity of meaning makes this recall easier when the words in the question differ from those in the document. It neither verifies the currency of the answer nor the permission to apply it to the current problem. A summary reduces the volume to reread, at the risk of removing a decisive reservation. The memory of knowledge requires keeping access to detail. A short conclusion becomes more useful when it allows one to return to the document on which it depends.

In the ecosystem, catalogs of repositories and domains already follow this logic of identification. They provide a common reference to find a known project or destination. Their role remains limited: knowing a domain does not allow its creation, and finding a repository does not prove that it is available on every machine. This simplicity seems essential to me. A reliable memory expresses both the scope of information and its content; it avoids transforming a practical indication into a general permission.

Sharing between people and agents requires the same attention. A common identity can facilitate access; each document retains its audience and responsibility. One must be able to correct a reference, remove data, and distinguish a proposal from an adopted instruction. An outdated note, automatically loaded, can do more damage than an absent note. Forgetting becomes a maintenance operation that preserves the necessary reasons for understanding changes.

The foreseeable continuation for Darkwood consists of making these gestures regular: linking a correction to the concerned decision, signaling knowledge to review, loading useful context. This does not mean that a universal memory already connects the six services. Readable documents and stable references may suffice. At the next interruption, a person must be able to resume understanding what is established, what remains open, and what they can question.

Flow — The Memory of Execution

Within a program, the question narrows: what data does the next step need? A calculation produces a value, a transformation enriches it, another uses it. This continuity already constitutes a memory, sometimes limited to a few function calls. Flow intervenes here: the PHP library composes processing steps and organizes their execution. To understand its contribution, let’s start with the data path before discussing saving or resuming.

The real example added to Memory uses the package darkwood/flow, in version 8.1.6. Three closures successively receive a PHP array. The first adds 4, 7, and 9 and adds the total, 20, to the transmitted state. The second uses this total to calculate the average. The third calculates what remains out of 100, which is 80, and then collects the result. A counter confirms that the addition occurred only once. Subsequent steps have access to the previous work because its result accompanies the data.

In this executable example, FlowFactory assembles the steps, an Ip object carries the input, and then await() waits for the processing to finish. The operations remain PHP primitives: an array, an addition, a division, and functions. This short chain could also be written without a library. Its size allows one to observe the transmission contract. Flow becomes useful when the organization of execution justifies this composition, without asking to reinvent the calculations.

The result is visible in the Flow demonstration, along with its code. The public site being static, PHP executes during its generation. The browser receives the result; it does not execute the library. The neighboring interactive workshop uses JavaScript to vary a calculation and observe several memory durations. One of the experiments shows the passage of actual state in Flow, while the other makes the difference in duration perceptible.

The first state is temporary and disappears at the end of an evaluation. The second reuses a result during the same job: two reads of a sum share a calculation. The third retains a value in the browser storage. It can be retrieved after a reload, as long as this storage exists. A variable, a reused value, and a saved value meet three distinct needs, even when they contain the same number.

In the PHP example, the total is carried once calculated. Flow does not decide to keep it for tomorrow. Each new execution starts from a fresh state. An application that wishes to retain this result must choose its support, its key, and the conditions of its reuse. If the input numbers change, an old sum no longer holds. If the calculation rule evolves, one must also know which rule produced the retained value. Persistent memory begins with these additional commitments, beyond the simple chaining of functions.

The scope of the state is also a question of correction. A reusable resource may remain available between several operations, while the data specific to an operation must be isolated. Keeping more does not automatically improve a processing pipeline: one can retain a result that has become false or allow data belonging to one execution to influence the next. It is necessary to name what survives, know when to reset it, and be able to explain why a value has been resumed. Debugging becomes clearer when this lifespan is explicit.

An interesting evolution would be to document these boundaries in the processes that use Flow: which inputs have circulated, which result to keep, which operation to relaunch? These are application choices. They do not constitute durable recovery after a failure or a shared memory of agents already provided by Flow. The memory of execution has a precise scope: transmit enough state for the work to advance, then decide what must survive it.

Uniflow — The Memory of Processes

A recurring task often leaves a method in the mind of the person performing it. They know the order of operations, the information to gather, and the necessary checks. When they are absent, these once-obvious steps become questions. Formalizing a process transmits this way of doing things. This is the realm of Uniflow: representing related tasks and retaining their definition for recovering, understanding, and reusing a sequence.

The project records programs with their structured content, their name, and their description. They can be linked to a user, a folder, and tags; their visibility is also part of the preserved data. This organization gives a lasting place to a working method. A recorded definition remains distinct from what happens when it is executed. Knowing the recipe for a report does not allow one to know if the one from this morning was prepared, interrupted, or validated.

The Uniflow demonstration of Memory clearly separates these two levels. On one side, a definition named “Prepare a report” describes three steps: collecting values, adding them, producing the report. It bears an identifier and a version. On the other, each launch creates a distinct execution. With values 12, 8, and 5, the total obtained is 25. The processing pauses after the addition. Resuming this execution then produces the report using the total already available.

The important detail is the cursor: it indicates where the work has stopped. The intermediate result allows continuation, while events narrate the steps accomplished. A second resumption request does not restart the finished report. The experience remains entirely local to the browser and does not trigger any Uniflow production engine. It makes visible a resumption contract that can be examined separately from the interface: what operation remains to be done, with which data, and on which execution?

A written record does not, therefore, constitute a point of resumption by itself. “Addition complete” is useful information for understanding a process. To continue really, one must also hold the total and know which definition produced it. If the method changes between stopping and resuming, the question becomes more delicate: should one continue according to the old rule or launch a new process? The version number of the demonstration allows for posing the problem. It does not claim to solve it for all situations.

This distinction becomes crucial as soon as a process acts beyond its own calculation. Imagine a task that prepares a message, waits for validation, and then sends it. Re-preparing can be inconsequential; repeating the sending engages another person. A resumption must recognize the effects already produced. This example is a possibility of automation, without announcing any particular integration with Uniflow. It shows why the memory of a process must separate proposal, decision, and action actually taken.

Repeatability involves a human aspect. A method may retain the reason for a step and the conditions of a stop. These indications help modify the process as needs evolve. Understandable events, linked to the right execution, can be more useful than an exhaustive history. Sensitive data also demand a clear boundary: making a definition shareable does not make public the data entrusted to it by someone.

For Uniflow, one approach could be to bring the recorded method, its versions, and the traces needed for its resumption closer together, according to usage. The starting point exists in the structured programs of the project; the history and resumption shown in Memory remain a distinct pedagogical experiment. The desired continuity is that of work that can be entrusted, interrupted, and recovered without having to guess what has already taken place.

Darkwaar — The Memory of the Player

In a game, restarting can provide a valuable advantage: a better understanding. A dangerous passage becomes recognizable, a rule stops being surprising, a detour takes on meaning. The character returns to the starting point, while the person in front of the screen has changed. Darkwaar explores this difference with Aftertrace, a game dedicated to memory. Its idea lies in the journey between two attempts: what one discovers should illuminate the next choice.

Aftertrace offers three small shores organized in grids of four squares by four. The terrain is partly hidden. One advances to an adjacent square with a click or tap; some squares are safe, others crack and interrupt the attempt. The number of steps is limited. One must find a diamond-shaped signal and then reach the exit. Thus, seeking the path requires managing both uncertainty and distance: directing immediately toward the exit may leave behind necessary information to cross it.

The first crossing is done empty-handed, to recognize the shore. When a crack halts progression, Rewind restores the starting position and available steps while keeping discoveries on the map. A dangerous square remains marked; a safe square already visited remains known. The game gives a visible shape to memory. The player can review what they have learned and prepare a route without having to mentally retain each attempt.

Reaching the exit the first time is not enough. After the reconnaissance, Carry returns the player to the start with an ember to transport. One must retrace the journey using the acquired map. This second crossing gives value to the first: discovering a route becomes the condition for a journey completed with a new intention. Memory directly influences decisions, as it indicates which squares to avoid and which ones to rely on. The game demands the exploitation of knowledge, beyond the simple revelation of a setting.

Progression then shifts to another shore and erases this map. The three reconnaissance crossings do not merge into unlimited knowledge. Each place requires its own reading, and some paths retrace their steps to reach the signal. One can also choose Forget to erase discoveries from the current shore. The scope of memory becomes a comprehensible rule: it survives the returns of the same exploration, then gives way to the next problem. Reloading the game also makes this session memory disappear.

This limit distinguishes several experiences. The map is information explicitly preserved by the game. The player can also learn to observe the branches, monitor their step budget, or prepare for the return before picking up the ember. These habits can stay with them after closing the page. They are not inscribed in any save file. Aftertrace thus brings together represented memory on the screen and personal learning: the former makes the terrain readable, the latter improves the way to approach it.

The Darkwaar section of Memory also preserves its room with an inscription and a notebook, showing what remains after a reset. Aftertrace, playable in the same section, extends the question through spatial choices, failures, and accomplished journeys. Its teaser shows the real game. The brevity of the shores allows revisiting a mistake and observing what it brings to the next attempt.

Other Darkwaar games could explore incomplete memory or information to transmit. These are possibilities for creation, not announced functions for Aftertrace. They raise a requirement: the player must understand what they keep and be able to use it. If memory does not influence any decision, repetition becomes mere waiting. Here, the ember entrusted at the second departure gives the past a precise function: making possible a journey that one now knows how to prepare.

DJMatyo — The Memory of Music

A piece of music can prepare its own memory. A motif returns, a pulse sets in, a melody leaves one awaiting the next note. Upon re-listening, the surprise becomes a reference; a variation allows one to measure the gap. DJMatyo's Happy Hardcore identity gives this relationship a particular place. The rhythmic energy and melodic lines can carry a sense of familiarity and a desire for movement. Repetition maintains momentum by giving a recognizable form to what one hears.

This memory first belongs to the listening experience. One recognizes a return before being able to describe it, waits for a reprise, and notices that silence has shifted the accent. For the DJ, choosing a sequence plays with these expectations: what precedes gives a color to what arrives. A transition can prolong energy, create a contrast, or make an idea reappear. The thread of a set hinges on these temporal relationships. A succession of pieces does not automatically retain the reason for which they respond to each other.

The DJMatyo demonstration of Memory reduces this question to eight steps. Notes and silences compose a loop; the tempo can be modified, the motif listened to, and then preserved. The sounds are synthesized in the browser, without third-party samples. This original workshop material does not reproduce any piece from DJMatyo. It makes memory modifiable: one retrieves a series of notes whose organization can be changed.

The variation button shifts the sequence by one step. The vocabulary remains the same; the placement of events changes. The return of the loop no longer has the same support. This operation allows one to listen to what an idea retains when transformed: pitches, silences, and certain intervals remain available, while their relationship to the beginning shifts. The memorized structure gives an origin to the variant without deciding if it is musically preferable.

The preservation focuses on the notes and the tempo. They can be recalled from local storage or exported to a JSON file. This file describes how to replay the motif; it does not contain an audio recording. The difference meets a common creative need: keeping a rendering allows re-listening to a result, and maintaining its structure allows reworking it. At the scale of a richer musical project, one would also need to retrieve the sounds, parameters, and resources that this structure depends on. Eight steps suffice here to show why the two forms of memory complement each other.

A sound identity is also built in the way of choosing, dosing energy, and bringing back familiar colors. For DJMatyo, the Happy Hardcore reference guides this search without imposing a repetition of the same sequence. Preserving a motif helps to hear what makes it recognizable and then to try what can change. Memory gives the present gesture the choice to prolong, shift, or abandon the idea.

The memory of a broadcast takes on another form. The DJ streaming project organizes a presentation frame with a logo, branding, and scenes before the live set and during mixing. These visual markers help to reclaim a listening framework; they do not describe musical production or the archiving of sessions. One avenue would be to accompany a set with its selection and notes on transitions, when rights and context permit. An intention is more easily recognized when named.

What one keeps must allow for a possibility of resumption. Retrieving a loop allows for listening to it differently; finding the reasons for a transition can illuminate the next set. Between the listener's memory and the creator's resources, memory maintains a vibrant relationship. A motif returns, but the person who makes it return has something new to ask of it. Musical continuity also plays out in this distance between the preserved idea and the present desire.

Heroclip — The Memory of Images and Narratives

The next shot inherits what the previous one has deemed important. A character has taken an object or left a place; the continuation must account for this in order to remain readable. In a generative video creation, this heritage needs to be formulated. A successful image does not convey all the intentions that produced it. Heroclip, designed around short video narratives continued through conversation, encounters this difficulty in transitioning from one segment to another.

The project preserves an initial brief and the generations attached to it. A generation may keep its chosen variant, its storyboard, the video generation text, its result, and a link to its parent generation. This lineage makes the creation path identifiable. It indicates which state of the narrative a proposal responds to and allows differentiating the starting point of a continuation, without imposing that all generations are identical.

A memory mechanism is already present in Heroclip’s code. In continuation mode, it selects up to three storyboards from successful generations and transmits them to prepare the next work. Some textual fields are shortened to limit their length. The context is therefore chosen and limited: the entirety of the past does not return with each request. A final image can also serve as a reference when available, depending on the used configuration. This possibility should not be confused with a guaranteed visual continuity.

The selection poses an artistic as well as a technical question. A decisive prop may have been introduced before the selected segments. A shortened description can lose a nuance of gesture or light. Too many details can also obscure the main intention. The choice of context engages what one wants to preserve: the character, the action accomplished, and the direction of the narrative do not necessarily require the same level of detail as the decoration of a background.

The Heroclip demonstration of Memory makes this transition visible without generating a video. One chooses a character and a palette; local rules construct a sequence of shots. With recall activated, the next shot retains the previous character, color, and prop. Without recall, it reverts to default values. This deterministic storyboard, limited to six shots, illustrates the transmission of references. It allows one to compare what the continuation receives when the past is transmitted to it and when it is omitted.

In video, control goes further. Preserving a character's name does not guarantee the same face or clothes. A common palette does not guarantee lighting continuity. The markers guide the production; viewing establishes if the result is satisfactory. A technically successful generation may call for an artistic correction. Maintaining this distinction avoids propagating an inconsistency simply because it has already been produced.

The lifespan of media poses a related problem. A reference to a video allows it to be retrieved as long as its destination remains available. It does not equate to a controlled archive. Resuming a story may require retaining the media, the storyboard choices, and the parameters of its selection. The lineage preserved in the project constitutes a support; a comprehensive preservation policy remains to be defined according to practices, rights, and storage costs.

A possible evolution would be to make the invariants of a story more explicit: what must remain recognizable, what can evolve, and what has just been corrected. A continuity sheet could complement recent storyboards without claiming to summarize the entire work. The challenge would be to make these markers revisable by the person creating them. Narrative memory then takes a precise direction: giving the next shot comprehensible commitments, while leaving space for a new event. A story continues because it also remembers what it has not yet told.

Conclusion

A decision retains its reasons, a calculation transmits a result, a process preserves its method. The player learns a path, the musician rediscovers a motif, and the narrative carries its references into a new scene. Their supports and durations differ. Their coherence comes from the attention given to what remains usable. For Darkwood, this leads to concrete choices: making an origin readable, delimiting a state, enabling a correction or erasure. Each activity demands deciding what it deserves to keep. Continuation becomes possible when this choice provides enough hold to resume, understand, and transform.