Understanding Projects¶

A Project in VDC serves as the top-level organizational unit for grouping related ingredients, feeds, users, and workflows. Projects provide isolation, permission control, and a consistent naming context for all activity within a team, product line, or validation domain.

Each project:

Contains one or more feeds
Manages ingredient and releases
Enforces role-based access control
Defines ownership on ingredients and workflows, but not access boundaries, as all users can view and consume releases across projects

All ingredients and releases in VDC exist within a project. There is no global/shared ingredient space.

Hierarchy and Containment¶

[Project: validation-team]
   ├── Feed: main
   │     └── Ingredient: IFWI_NVL
   │            └── Releases: v1.0, v2.0
   ├── Feed: experimental
   │     └── Ingredient: BIOS_drop
   │            └── Releases: v0.1, v0.2
   └── Workflows, permissions...

Project-Level Behavior¶

Feature	Behavior
Ingredient ownership	Determined by the project the ingredient is created in
Feed structure	Feeds are unique within a project, not across projects
Artifact storage	Blob containers and folders are scoped to project+feed
Role-based access control	Edit permissions are scoped per project, but all VDC users have read-only access to all projects by default
Dependency resolution	Fully supports cross-project references for all users
Naming flexibility	Same ingredient name can exist in different projects

Access Control¶

Projects define access for users and teams
Roles include: Admin, Contributor, Reader
Access is inherited by all feeds and ingredients within the project
Group-based access can is being managed via AGS groups

%%TODO: add information about AGS groups%%

Common Use Cases¶

%%TODO: add use cases that we recommend for how to define projects%%