Know what to build before you build it.

Neither, first. The evidence does not support a cataloguing purchase or a capacity purchase as the next move. Both would sit on top of the actual constraint rather than remove it.

Northbeam has no defined end state for a finished project. Each editor decides independently when a job is done, what gets kept, and where it lands. That single missing definition produces four of the five ranked findings below: the duplicate masters, the 88% array, the retrieval dependency on one producer, and the untested LTO set. A MAM introduced now would index an inconsistent library and reproduce the inconsistency in search results.

Recommended next move: define and enforce a project close-out: one naming and identifier convention, one archive destination per project type, one checklist that must pass before a job is marked complete. Run it manually on the next three projects before automating any part of it. Re-evaluate a MAM at day 90 against a library that has a shape.

Most important uncertainty: the 2019–2022 LTO set has not been restored from since it was written. Recoverability was not tested in this engagement and cannot be assumed. A single restore test is the cheapest high-value action available to the team and is scheduled first in the roadmap.

Scope and evidence

• Observed Directly visible in supplied material.
• Stated Described by the team, not independently tested.
• Inferred Reasoned from the above; the reasoning is given.
• Unknown Important and not established here.

Boundary note: this map covers one team and one recurring workflow. Freelance edit-at-home cycles were described but not mapped, and are carried as an unknown in section 08.

1. 01Observed

   No defined end state for a finished project.

   Close-out is decided per editor per job. Three duplicate masters were found across two volumes during the session, and finished work is the largest occupant of working storage.

   Consequence

   Drives findings 02, 03 and 04. Blocks any catalogue from being trustworthy.

   Confidence

   High

   First proof

   Write the close-out checklist; run it manually on the next three projects.

2. 02Unknown

   The 2019–2022 LTO set has never been restored from.

   Roughly 60TB of archive-only material. Tapes were written on a drive that is no longer in the building. Recoverability was not tested in this engagement.

   Consequence

   Potential total loss of three years of finished work, currently unquantified.

   Confidence

   Unknown by definition; that is the finding.

   First proof

   Restore two tapes chosen at random. One afternoon, no purchase required.

3. 03Stated

   Retrieval depends on one producer's memory.

   Older assets are found by asking the same person, who is also carrying the heaviest project load. No index exists that survives their absence.

   Consequence

   Reuse effectively stops when they are out; estimated at several hours per week of avoidable search.

   Confidence

   Medium: consistent across three accounts, not measured.

   First proof

   Log every retrieval request and its duration for two weeks.

4. 04Observed

   Working storage is at 88% and rising ~2% per month.

   An expansion quote is already in hand. Approximately 40% of occupancy is completed work with no operational reason to remain.

   Consequence

   A capacity purchase now buys roughly eleven months and preserves the underlying behaviour.

   Confidence

   High

   First proof

   Archive the three oldest completed projects under the new close-out rule and measure what is recovered.

5. 05Inferred

   Approvals are not attached to the version they approved.

   Sign-off lives in email while versions live on the array under ad-hoc names. Two of the described re-cuts are consistent with a client approving a superseded version.

   Consequence

   Occasional re-work at the most expensive point in the schedule.

   Confidence

   Medium: the pattern fits; specific incidents were not reconstructed.

   First proof

   Adopt a version identifier that appears in the filename, the review link, and the approval reply.

The shape Northbeam needs is not a new platform. It is a boundary between working storage and the archive, with one identifier that survives the crossing, and one named owner for the crossing itself.

[source / ingest] → [controlled working path] → [archive / index]
                                  → [search / review / reuse]
                                            ↕
                            [ownership, evidence, maintenance]

Read left to right, the change is small: one gate between the working path and the archive. Read bottom to top, it is the whole point: every stage above depends on someone owning it and on the evidence being written down as work happens rather than reconstructed later.

Keep / change / pilot / defer

Nothing in this roadmap requires a purchase from Vaultline. If the team executes days 0–60 and the constraint is gone, that is a successful outcome of this Blueprint.

Media Nexus is Vaultline's local-first media operations system. It is built around roles rather than fixed hardware: the same software runs on one machine, on an edit bay plus a server, or against a NAS. Nothing about it assumes a particular storage layout, which is why it can sit on the array and the LTO set Northbeam already owns.

One architectural rule governs the whole system and is the reason it is safe to point at a working operation: the modules never scan storage themselves and never write toward source media. A node reads, indexes, and generates derivatives; every module above re-reads what Archive already indexed. Your masters are never the thing being modified.

System architecture

Read top to bottom, the system only ever moves in one direction: source media is read, an index and a set of derivatives are produced, and every module reasons over the index. Read as a whole, that is the property that makes it appropriate for an operation that cannot afford to be experimented on.

Module catalog, with Northbeam scope

Maturity below is Vaultline's own internal status, reported as it stands rather than as it would sell. Two of these are experimental and one is currently disabled.

Search and local AI are not modules. They are shared capabilities owned by the module contracts above, which is why there is no separate line item for them, and no separate licence. Tagging and transcription run locally on your hardware; no footage is uploaded anywhere to make them work.

Phased against your roadmap

What stays exactly as it is

• Premiere and the edit workflow. Media Nexus does not touch the NLE. Post reads project files; it does not run the edit.
• Your storage. The array and the LTO set are yours, stay where they are, and are read rather than migrated.
• Client review, if you want it that way. Frame.io can remain; Review is an option, not a requirement of the foundation.
• The close-out decision. No software decides what “finished” means for your operation. The system enforces the definition; it does not supply it.
• The archive owner. A person, not a feature. Every finding in layer 05 survives any software purchase.

Vaultline builds Media Nexus, so treat this section with the scepticism that deserves. It is specified here in full precisely so the recommendation against buying it can be checked against what is actually on offer. Section 08 sets out every option, including the ones with no Vaultline involvement.

1. Option 01

   No project now

   Preserve what this Blueprint established and change nothing else. Even taken alone, the team keeps the workflow map, the ranked findings, and the knowledge that the LTO set is untested.

   Viable. Not recommended only because the restore test is cheap and the exposure is real.

2. Option 02

   Internal execution

   Recommended

   Northbeam runs the 90-day roadmap itself. Every action is within the team's existing skills and none require a purchase. Estimated effort is a half-day for the restore test, a few hours to write the close-out checklist, and a standing few minutes per closed project.

   Recommended because the constraint is a missing operating decision, not a missing capability. Buying software before making the decision converts a cheap problem into an expensive one. If the roadmap is executed and the constraint is gone at day 90, no further engagement is needed.

3. Option 03

   Media Nexus Archive Pilot

   A fixed-scope archive foundation on the team's existing hardware, covering the scope set out in section 07.

   Not available yet. All four prerequisites in section 07 are unresolved. Revisit at day 90 if the index is being maintained and has been outgrown.

4. Option 04

   Bespoke Media Operations Build

   Custom workflow, integration, or hardware implementation under a new written scope.

   Not justified. Nothing in the evidence indicates this operation needs software written for it. Revisit only if a constraint survives the full 90 days and has no off-the-shelf answer.

Unknowns carried forward

• Whether the 2019–2022 LTO set is readable. Untested. Resolved by the day-30 restore test.
• The true retrieval cost. Described as “an afternoon” but never measured. Resolved by the two-week log.
• Frame.io retention settings and what happens to review assets over time. Not inspected.
• Whether offsite copies of the 2019–2022 material exist. Stated as “probably,” not confirmed.
• Freelance edit-at-home cycles. Described but outside the mapped boundary.
• Real storage growth rate once completed work stops accumulating on the array.

Clarification window: send one consolidated set of questions within 10 business days of delivery and we answer it in a single pass. New analysis, additional teams or workflows, system access, implementation planning, or hands-on work requires a separate written scope.