Hi Vercel team,

I am opening a focused follow-up to the earlier topic, which is marked Solved: https://community.vercel.com/t/read-only-evidence-on-hobby-effective-access-and-historical-deployment-metadata/51467

Thank you for clarifying the single-user/Owner model, automatic Node.js patch updates and the Fluid Compute duration limits. The current human membership/role-count question is resolved. The six questions below remain unanswered; they concern evidence availability and the meaning of settings, not a request to change the service.

Could someone from the relevant product team clarify these points for a Git-connected Hobby project?

1. Direct versus inherited access Are direct project membership and inherited team access distinct, applicable categories on Hobby? How should the single Owner be classified, and what supported source defines or exposes the aggregate counts? If the categories are not applicable, please distinguish that from applicable but not exposed.

2. Access overlap If those categories apply, can the same person count in both? How can an owner determine the overlap without exposing member identities? Absence of a project-role UI is not enough for us to assume zero.

3. Historical effective Node.js version Is there a retained record of the exact runtime minor/patch used by an existing deployment at a specified past time and region? We understand that only the major version is selectable/guaranteed. Build-time Node, the configured major and a new invocation do not establish the historical runtime.

4. Identity of deployed function output Can an owner obtain an immutable digest or manifest identifying the function artifact actually installed for an existing deployment? A source-file listing, Git SHA or build-cache hash alone would not establish that identity.

5. Provenance of that output Is there a retained record binding that installed output to its source commit, resolved dependencies, build, deployment, environment and time? If no customer-facing source exists for points 3–5, can Vercel provide a factual attestation, or explicitly confirm the relevant availability limit?

6. Historical non-Fluid timeout For a legacy Hobby project with Fluid disabled on 11 October 2026, what establishes the configured or applicable default duration when the project Max Duration input is blank with placeholder 10 and the project response omits the timeout/Fluid keys? Separately, do project-function-max-duration and project-functions-fluid-enabled/disabled Activity events retain old/new values, and what are their retention and read-only access limits? The 300s Fluid answer and a later deployment snapshot concern different contexts.

For each point, an exact supported read-only source with its scope/retention, or an explicit distinction between not exposed, not retained and not retrospectively reconstructible, would be very helpful. Partial answers are welcome; please route the remaining points to the appropriate team if needed.

This is a general capability question. No account/project identifiers, secrets, logs or attachments are included or requested publicly. We are staying on Hobby and are not requesting an upgrade, paid service, production invocation, redeployment or configuration change. Thank you.