Section 01
Executive answer
Decision this Blueprint supports: Should we license a media asset manager this quarter, or expand the shared storage array first?
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.
Not recommended right now
Storage expansion (~$14k quoted). The array is at 88% because completed work never leaves it. Roughly 40% of current occupancy is finished projects with no reason to stay on working storage. Capacity is a symptom here, not the constraint.
Scope and evidence
Section 02
Current-state map
How media actually moves today, with every claim marked by how we know it.
- 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.
Section 03
Priority bottlenecks and unknowns
Ranked by operational consequence and relevance to the decision — not by what is easiest to sell you.
-
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.
-
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.
-
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.
-
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.
-
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.
Section 04
Findings by operating layer
The same operation read through each layer separately, so a fix in one is not mistaken for a fix in another.
Layer 01
Storage and protection
Observed
One 120TB array serves as working storage and, by default, as the archive. LTO-7 exists but is written occasionally and without a trigger. Copies are not tracked, and no document states how many copies of a finished project should exist or where they should live.
Two fault domains were described: the array itself, and the tape set. They are in the same building. Whether the 2019–2022 tapes are readable is unknown — see finding 02.
Not claimed: no hardware health check, throughput test, backup-recoverability test, or capacity forecast beyond the team's own stated growth rate was performed.
Layer 02
Organization, metadata, and retrieval
Observed
Three naming conventions are in active use, corresponding roughly to who joined the team when. Project folders carry a client name and a loose date; there is no stable identifier that survives from ingest to delivery to archive.
Metadata beyond the filename does not persist past the edit. Nothing that a person knows about a shot — the client, the campaign, whether it cleared legal — is written anywhere a search could reach.
Retrieval today is a person, not a system. That works at the current library size and stops working at the next one.
Layer 03
Ingest, handoffs, review, and delivery
Stated
Each stage functions. The failures are at the seams. Offload has no verification step beyond visual inspection, so a bad copy would not be noticed until the footage was needed. Responsibility for a project between picture-lock and delivery is not assigned to anyone by name.
Review links expire on a default the team did not choose. Approvals return by email and are not bound to the version they approved, which is the mechanism behind finding 05.
Delivered masters leave the building with no record the team can query afterwards. Asked what was delivered to a client in 2024, the operation's honest answer is to go looking.
Layer 04
Automation and AI fit
Inferred
No automation is currently justified. Automating a process with three naming conventions and no defined close-out would encode the inconsistency rather than remove it, and would make it harder to change later.
Two bounded opportunities exist once close-out is real, in this order:
- Checksum verification at offload. Deterministic, cheap, no model involved. Removes an unmeasured risk at the earliest point in the chain.
- Automatic index entry on close-out. Writing the project ID, client, date, and destination to the index when a job is closed, rather than asking a person to remember.
Content-level AI — transcript search, visual tagging, automatic selects — is a day-90-or-later question. It requires a consistent library to be useful and a human review step to be trustworthy. No accuracy claim is made here.
Layer 05
Ownership and continuity
Stated
No one owns the archive. It is the only stage in the map with an unassigned owner, and it is the stage where every unresolved finding accumulates.
Operational knowledge is concentrated in one senior producer: where older work lives, which tape holds what, which client wanted which deliverable format. None of it is written down. This is a single point of failure with no redundancy and no documentation, and it is the finding most likely to become urgent without warning.
Note: this is an organizational finding, not a technical one. No purchase resolves it. A named owner and a written index do.
Section 05
Recommended target state
One coherent direction, justified by the evidence above. Architecture direction, not an implementation specification.
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
Why an index and not a catalogue
A spreadsheet with a project ID and one line of contents answers the retrieval question actually being asked, costs nothing, and produces the consistency a real catalogue would need later. If it is being maintained at day 90 and still not sufficient, that is genuine evidence for a MAM purchase. If it is not being maintained, a MAM would not have been either.
Section 06
90-day roadmap
Sequenced so each step produces the evidence the next one needs. Every line has an owner, a dependency, and a condition that says it is finished.
Section 07
Media Nexus scoped
The complete system, with your scope drawn on it — so you can see what you would and would not be buying, and judge the rest of this document against it.
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
Phase 1The foundation
CoreArchiveRelayOps
On the existing array. This is the whole of what section 08 calls the Archive Pilot, and the only phase that would be scoped from this Blueprint.
Replaces: the spreadsheet index, manual offload verification, and the capacity surprise.
Phase 2The work in flight
PostReview
Once the foundation has been running long enough to have a library worth reasoning over. Neither is useful before close-out is real.
Replaces: the version ambiguity behind finding 05 and the informal “where is that job” question.
Phase 3Only if earned
DeliveryAutomation
Only against measured demand. Delivery is currently disabled in the product; Automation is beta. Neither should be committed to on the strength of this document.
Replaces: nothing that is hurting today.
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.
Our recommendation on Media Nexus, for this operation, today
Not yet, and possibly not at all. Everything in Phase 1 above depends on four things Northbeam has not done: a close-out definition that is being followed, a passed restore test, one identifier convention that survives three projects, and a named owner. All four are free. Prove the behaviour with a spreadsheet for 60 days. If the index is being maintained and the team has outgrown it, Phase 1 becomes a real option worth pricing. If it is not being maintained, no software would have been maintained either — and that is a more useful thing to learn for $499 than a licence would have been.
Section 08
Implementation options, unknowns, and non-claims
Four ways forward, including doing nothing. One is recommended; the reasoning is given so you can disagree with it.
-
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.
-
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.
-
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.
-
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.
Non-claims
- No hardware health, backup recoverability, security, or compliance claim is made anywhere in this document unless specifically evidenced above.
- No AI accuracy claim and no cost-savings figure is asserted.
- No files, storage, configurations, or production systems were changed by this Blueprint.
- No implementation feasibility is promised. Any build requires a separate written scope.