# The Vault Must Keep Its Versions

Today I put Alfresco under VALESKA as a deployment substrate, then fix re-deposit so superseded PDF/A bytes are not overwritten in place.

Language: en
Canonical: https://avanticomplex.com/en/blog/the-vault-must-keep-its-versions/

Published: 2026-06-28T18:00:00.000Z

An HTTP deposit that cannot land in a running content platform is still a rehearsal. Today I add the Alfresco deployment substrate VALESKA actually starts, and I fix a quieter defect: re-deposit was overwriting node content in place, so superseded PDF/A bytes disappeared and the version label never advanced.

## The wrong default

The usual integration is “point the URL at Alfresco and call it deployed.” The other usual mistake is to treat a second deposit of the same record as a silent replace. Both destroy evidence. A vault that forgets what it held yesterday is not keeping records. It is keeping the latest file.

A library that reshelves a new edition by throwing away the old one cannot tell you what was true last year. I want a real version: major when the execution state is executed, minor otherwise, with a governance comment on the upload.

## Substrate, then history

On 27 June I add the Alfresco deployment substrate — the compose and configuration that actually bring the content platform up beside VALESKA, not a paragraph that assumes it. The next day I change deposit itself. The first deposit now creates the node with the `cm:versionable` aspect and auto-version on. A re-deposit ensures that aspect, then uploads content as a new version rather than a smash write. The receipt reports the live `cm:versionLabel` read back from Alfresco.

I verified that against a live Alfresco node I then deleted: executed went to 2.0 major, pending to 2.1 minor, the receipt label matched the live label each pass, and history accrued. The deposit unit suite still reports 17 passing. Existing nodes created before the fix need a one-time retrofit of the versionable aspect. I am not pretending that retrofit has already run across a customer vault. It has not. This is my environment, my own nodes.

The substrate is the compose and configuration that actually start Alfresco beside VALESKA. I traced the coupling before assuming it was structural: governed deposit needs the client; the rest of the API does not have to. That distinction will matter when I later ship a profile with no ECM. Today I still need the vault if I want versions.

Upload now carries major\_version and a comment on the content PUT. The execution-state label remains the fallback if Alfresco does not echo a label. I would rather read the live label back than trust the fallback. The throwaway node is gone. The behavior stays.

I came from a fail-closed library that refused incomplete envelopes. HTTP gave that library a door. This week the door lands in a running vault, and the vault keeps yesterday’s bytes. Without those three steps in order I would have a demo of refusal, a demo of POST, and a vault that forgets. I want them as one path on my own data.

Follow-up is explicit: pre-fix nodes need the versionable aspect added once. I will not bury that in a success sentence. If I re-deposit onto an old node today, I can still lose history. The test I ran was on a node created after the fix.

## The next test

The next test is the HTTP path from [12 June](/en/blog/deposit-arrives-over-http/) through this versioning behavior on a node I keep, not a throwaway. Until a receipt, a live label, and a previous version can be shown together, this is a substrate and a repaired write, not a records program in production.

* * *

**Historical basis:** VALESKA commits `aeb5374` (27 Jun) and `647bf07` (28 Jun 2026).


## Translations
- en: https://avanticomplex.com/en/blog/the-vault-must-keep-its-versions/
- es: https://avanticomplex.com/es/blog/the-vault-must-keep-its-versions-es/
- pt: https://avanticomplex.com/pt/blog/the-vault-must-keep-its-versions-pt/