Projects and assets

Projects and assets provide organizational foundations for Studio, but the inspected implementation mixes mock surfaces, local stores, and non-production persistence. Use them to group work and understand media references while keeping ownership, retention, deletion, and long-term reuse under review.

Projects

A project groups related creative activity. It can provide a reference that a generation request uses to associate jobs or assets with a body of work. The projects route also contains cards and actions that may be mock or foundation-only.

Do not infer durable project creation from a visible card. Some mock actions explicitly avoid persistence and provider calls. The supplied source bundle does not establish that every project survives application restart, deployment, or environment change.

When a project identifier is accepted by the media API, it can link current job and asset records. That relationship is useful for organization but does not settle the storage contract.

Assets

An asset is a saved or referenced media output. The asset surface and library can display generated items and their relationship to jobs or projects. An asset is distinct from the media job that produced it: the job records processing state, while the asset represents the output reference.

Current sources do not verify that every completed job produces a durable asset. Some outputs may be local, preview, mock, or dependent on provider configuration. Read the asset’s current metadata and availability rather than assuming a universal lifecycle.

Organization

Use projects to group assets by campaign, product, experiment, or other meaningful work boundary when the current surface supports it. Keep names descriptive without including secrets or unnecessary personal data.

Because project and asset stores may vary by environment, avoid designing a critical operational process around folder-like behavior that the repository does not confirm. The canvas and specialized workbenches can reference creative work, but their presence does not prove a complete shared library or cross-app handoff.

A clear organization pattern can still help during the current private-beta stage: maintain the prompt, job reference, asset reference, and intended project together. That information makes it easier to trace how an output was produced even when persistence is limited.

Metadata

Useful metadata can include the associated project, source job, modality, model or provider reference, prompt, timestamps, status, safety result, and other inspector fields supported by the current path. Not every asset will contain every field.

Treat estimated cost or credits as operational estimates, not billing records. Keep provider and model values tied to the job that produced the asset rather than turning them into permanent availability claims.

Do not add unsupported metadata guarantees. Ownership, retention date, deletion state, checksum, provenance, licensing, and provider-side storage require explicit source evidence before being documented as universal fields.

Reuse

An asset can conceptually serve as a reference for another workbench, especially image-to-video, which requires a source image. The current Studio shell can expose reference panels and result actions, but many handoff, export, and reuse controls are disabled.

Before reusing an item, confirm that the target workbench accepts the asset format and that the current provider is configured. If the UI does not offer a working transfer, keep the asset reference and add it through the supported input path rather than claiming an automatic handoff.

Do not promise that a shared asset is available across every Studio app. Cross-surface reuse remains dependent on the current store and panel wiring.

Deletion

No complete deletion contract is verified. Project and asset sources do not establish whether deleting a project removes its assets, whether removing an asset deletes provider-side data, or whether records are retained for a fixed period.

Use only deletion controls that are visibly supported, and confirm their stated scope. A disabled button, mock action, or local record removal should not be described as secure erasure. Do not promise provider-side deletion, cascading deletion, recovery windows, or irreversible removal.

Privacy and Terms are the approved legal references. Until storage and deletion behavior is reconciled, treat sensitive media carefully and avoid relying on Studio as the only copy of an important asset.

Project-to-job relationships

When a media request includes a project identifier, the generation route can associate current job and asset records with that project. This creates useful context, but it does not prove that the project owns the media in a durable storage system. Treat the association as a current-store reference.

A project card can also be mock. Before relying on its actions, look for text that says no persistence or provider call occurs. An editable-looking control can still be a design placeholder.

Asset provenance

For a generated asset, keep enough metadata to understand its origin: the source job, modality, prompt reference, model and provider reference, safety outcome, and project association where available. Provenance should describe what the current system recorded, not add claims about licensing, authenticity, or permanent custody.

An asset created from a fallback or mock path should carry that state. Otherwise, a later user may mistake it for a live provider output.

Storage conflict

The generation API and Studio UI use different language for non-production storage. One describes local private-beta storage; another describes in-memory storage. Both reject production durability, but the implementation needs reconciliation before documentation can state a single mechanism. Keep persistence-contract-requires-verification and avoid choosing whichever description sounds stronger.

Reuse boundaries

Reference panels can make an asset useful in another app, but availability depends on current wiring and store visibility. Image to Video needs a source image; a project relationship alone does not supply it. Confirm that the target app can read the reference and that the provider is configured before describing reuse as successful.

Deletion review

A complete deletion design would need to address the project record, asset record, underlying file, derived versions, job references, logs, and provider-side copies. The current source bundle does not show that chain. A local removal should therefore be described narrowly, without promising erasure across systems.

Project state inspection

A project surface can include sample cards, local data, or mock actions. Check whether the project has a persistent identifier and whether a generation request can reference it. A visual title and thumbnail alone do not establish a stored record.

Asset state inspection

An asset should be connected to a result reference or an existing media input. If its source is unclear, avoid using it as proof of a completed job. Mock assets and generated assets need different labels so later workflows do not confuse demonstration content with provider output.

Ownership and access

No complete ownership, sharing, or workspace-access model is verified for Studio projects and assets. Do not state that another user can or cannot access an item without direct source evidence. The current page remains an organizational guide, not an authorization reference.

Metadata changes

If the surface allows metadata editing, document only the fields and persistence behavior that are visible. A local label update should not be described as changing the original provider output or job record.

Downstream creative reuse

A reusable asset needs a format and reference that the target app understands. Image-to-video is the strongest example because it explicitly requires a source image. Other cross-app reuse and automatic project handoff remain unverified.

Deletion and references

Removing a project can leave job or asset references in another store, and removing an asset can leave its job history. The current sources do not define cascading behavior. Before using deletion, note the item relationships and interpret the result narrowly.

Project portability

No export or import contract is verified for projects. Do not promise that a project can move between environments or be reconstructed from its asset list. Keep external records of important prompts, source media, and results when portability matters.

Asset availability versus durability

An asset can be available in the current session while remaining non-durable. This is different from a mock asset, which may never have come from a provider. Preserve both the availability state and provenance state when documenting reuse.

Retention questions

Fixed retention periods are not verified for projects, assets, underlying files, or job references. Avoid phrases such as “stored indefinitely” or “deleted after” a set period. The correct user guidance is to minimize sensitive content and keep independent copies of important outputs.

Project and asset identifiers

Use identifiers only when the current surface or API returns them. Do not invent example IDs in product links or instructions. Keep the job, project, and asset references distinct so a missing object can be diagnosed without confusing the stores.

Mock content

Mock projects and assets are useful for layout and workflow previews. Label them clearly. They should not be used to demonstrate persistence, provider generation, ownership, or deletion behavior.

Sensitive media handling

Because retention and deletion remain unresolved, avoid using Studio projects or assets as the sole repository for sensitive or irreplaceable media. Minimize uploads and retain necessary copies under an approved storage process.