Following up: this evidence question is blocking completion of a read-only technical review. Could a Vercel team member or community moderator help route it to someone who can confirm the supported sources and their limits?

To make the request actionable, a separate yes/no/source answer for each group would be very helpful:

1. On Hobby, can an owner obtain complete effective project-access counts, distinguishing direct and inherited access, role categories and overlaps, without disclosing member identities? If the distinctions are not applicable on Hobby, please identify the documented rule and its coverage.
2. For an existing deployment at a past time, are the effective Node.js patch, an immutable digest/manifest of the deployed function artifact, and the source/dependencies/build/deployment/environment/time binding available through a supported read-only record or provider attestation? A source commit or configured Node major alone does not resolve these questions.
3. Is there a retained project-level record establishing a historical configured/default function timeout when the UI field is blank and the project response omits the relevant keys? A deployment configuration snapshot is a different object/time scope.

If a record is not exposed, not retained, unavailable on Hobby, or cannot be reconstructed retrospectively, an explicit distinction would be equally useful. If another free official channel is appropriate for this capability question, please point us to it.

No upgrades, paid support, production invocations, redeployments or configuration changes are requested. This remains a general question: no project/account identifiers, secrets, logs or attachments. Thank you.

Hobby is a single-user plan with some usage limits. The only person on the team effectively takes the owner role

You can review team member actions in the Activity Log

Vercel rolls out Node.js minor and patch updates automatically, so only the major version is guaranteed.

With Fluid compute, Hobby's default and maximum are both 300s

For more info, please go to vercel.com/docs and search or use the Ask AI button

Thanks, Amy. Your answer clarifies the single-user/Owner model and the automatic Node.js updates. I checked the linked documentation; the remaining questions are narrower:

1. Hobby access classification. For a single-user Hobby project, are project-direct, inherited and overlap membership categories applicable? Is the Owner classified as inherited access without a direct project assignment, or should those categories be recorded as not applicable? I do not want to invent zero counts from the absence of a project-role UI.

2. Historical Node.js patch. I understand that only the major version is selectable/guaranteed. Separately, does Vercel retain a record of the exact runtime minor/patch used by an existing deployment at a specified past time/region? If available, what supported read-only source exposes it? A new invocation or build would not establish the historical state.

3. Deployed output and provenance. Is an immutable digest/manifest of the installed function output available, with a binding to source commit, resolved dependencies, build, deployment, environment and time? A source-file tree or Git SHA alone does not identify the deployed output. If there is no supported customer-facing record, can the team confirm whether a provider attestation is possible?

4. Historical non-Fluid timeout. The 300s answer is explicitly for Fluid Compute. For a legacy Hobby project with Fluid disabled, what did a blank project Max Duration field with placeholder 10 mean on 11 October 2026? The Activity Log catalog lists project-function-max-duration and project-functions-fluid-enabled/disabled. Do their retained records include old/new values and enough history to establish that earlier project setting/default, and what are the retention and read-only access limits? A later deployment's duration is a separate observation.

For unavailable records, please distinguish "not exposed to customers", "not retained", and "not reconstructible retrospectively". A short answer or the appropriate free technical channel is enough. No account identifiers, private records, changes, redeployments or paid services are requested. Thank you.

Small update: the current single-user Owner role/count is now reconciled, thanks to Amy's clarification. That removes one part of the original request.

Our filtered Activity request did not return a usable historical value; this does not establish that no changes or records exist.

Rather than repeat the four questions in my previous reply, could a staff member help route the remaining access-classification, historical runtime/artifact provenance, and non-Fluid timeout questions to the appropriate product expert? For each, a supported read-only source or an explicit distinction between not exposed, not retained, and not reconstructible would let us avoid unsupported conclusions.

The topic currently shows Solved, but those specific follow-up questions remain unanswered. Could they remain under review? We are staying on Hobby and seeking existing evidence or a clarification of its limits, not configuration changes or paid services. Thank you.