#!RFC-AI/2;id=37;draft=4;v=0.5.0;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=4b52f312eb6124408d788ed852c39e77bf385002c469443ad2651b4a98942924
For easier reading, view RFC-AI documents using RFC-AI Reader software.

RFC-AI 37 — PROVIDER PROFILES, CAPABILITY DISCOVERY, WORKING-MODE MANAGEMENT AND REFRESH
STATUS: DRAFT 4 — CEO REVIEW REQUIRED; NOT APPROVED, ACTIVATED, OR IMPLEMENTED
DATE: 2026-11-02 UTC | NUMBER: PROVISIONAL SUBJECT TO RFC-AI 9 REGISTRY RECONCILIATION
SCOPE: All AI service providers, Chat/API surfaces, registered provider selectors, worker working-modes, and their account-specific observed capabilities
RELATED: RFC-AI 4,8,9,12,17,19,21,25,28,31,32,33,34,35,36

ABSTRACT
Define provider profiles as framework-owned, separately stored, automatically refreshed descriptions of observed provider capabilities, supported selectors, working-modes and continuity behavior. The framework uses simple hard-coded logic for retrieval, validation, cache freshness, routing and safe fallback; an AI MUST NOT create, interpret or promote its own capability or authorization. The worker identity remains exactly (type, provider, selector, account). Optional working-mode is not part of that ID. Refresh successful profiles every six hours by default and perform a cheap freshness check on each contact; do not make a full external provider call on each contact unless there is a documented low-cost need.

1. DEFINITIONS AND NON-IDENTITY
1.1 PROVIDER is the canonical registered service/product (e.g. ChatGPT.com). SELECTOR is the provider's service/function discriminator and is a required four-tuple component which MAY be the empty string "" where no discriminator exists. A blank selector is NOT a missing key. Account is the canonical provider account string, kept private as appropriate. TYPE is Chat or API.
1.2 working-mode is a separately represented OPTIONAL operational mode (examples: "work", "chat") under a single registered worker tuple. Distinct working-modes do not create distinct workers, nicknames, training records, roles or permissions. The serialized key is literally "working-mode" with a hyphen, never a legacy alternate key or a "mode" identity component, or an extension to the worker ID.
1.3 A provider profile is a non-authoritative capability observation; a worker identity registry is the authority for tuples and nicknames; an authorization system is the authority for protected actions. A public provider model list is not account-specific entitlement, quota, current availability, proof of retained memory, or binding of a website session to a worker.
1.4 Distinguish a public PROVIDER_PROFILE (public API schemas, product properties), an access-controlled ACCOUNT_CAPABILITIES observation (actual authenticated account entitlements and usage signals), and a TASK/MODE selection event. Store their source identities and access scopes separately. Never copy one account's entitlements or continuity data into a global provider profile.

2. PROFILE SCHEMA AND PROVENANCE
2.1 Required profile fields: schema_version; canonical type/provider/selector; supported working-modes with tri-state SUPPORTED/UNSUPPORTED/UNKNOWN (and per-capability evidence); source identifier/version/URI; acquisition method and assurance; source-observed or collected UTC; last_success_utc; last_attempt_utc; expiration_utc; supported operations; limits/usage-signal availability; continuity characteristics; privacy classification; revision/digest; status and error history references. Public fields MUST use approved provider catalog and typed bounded values. Unknown MUST NOT be treated as false, true or permission to probe arbitrarily.
2.2 Account-specific observations also bind to the authenticated four-field worker tuple or registered account-scoped principal and task context; persist only safe entitlement indicators and masked identifiers. Exclude credentials, cookies, session tokens, password reset links, secrets, raw private chat content and provider-internal undocumented IDs.
2.3 Keep feature capabilities independent: mode_select_automation, quota_readability, quota_reset_observability, tool_availability, persistent_conversation_reference, provider_cross_session_memory, external_continuity_injection, file_access, network_access, cost_per_probe and usage signals. Each may be YES/NO/UNKNOWN with evidence, timestamp and supported interface; an LLM claim or a marketing page alone cannot prove actual account behavior.
2.4 Continuity survivability is a measured property, not an identity rule. For each mode track whether authorized session history and external handoff can be observed and restored; when unknown or unreliable, ALWAYS obtain GetWorkerContinuity again at authenticated contact and use task records, not remembered chat. A provider's memory is never the source of corporate policy or completion evidence.
2.5 Example synthetic profile slice (not a statement about actual current ChatGPT features):
{ "schema_version": 1, "type":"Chat", "provider":"ChatGPT.com", "selector":"", "working-modes": {"work":{"supported":"UNKNOWN"},"chat":{"supported":"UNKNOWN"}}, "refresh_interval_seconds":21600, "last_success_utc":null, "expiration_utc":null, "status":"UNVERIFIED" }
2.6 All schema changes are versioned. Reject extra fields that would be interpreted as instructions, unknown providers, invalid timestamps, unexpected switches, unsafe URL targets, oversized payloads, malformed status or conflicting catalog aliases. Retain last independently verified snapshot separately from new unverified candidates; never self-authorize profile migration.

3. SAFE DATA COLLECTION — SIMPLE LOGIC ONLY
3.1 Fixed per-provider adapters use explicitly approved, versioned, documented interfaces. A provider may support API model listing, OAuth/OIDC metadata, published revision notes and HTTP validators; these prove only the facts their interfaces actually represent. Vendor API docs, official deprecation notices and authenticated response headers are distinct evidence grades.
3.2 The model-list APIs of OpenAI, Anthropic and Gemini expose differing scopes and attributes; no universal provider profile endpoint exists. An API result MUST NOT be claimed to reveal ChatGPT Work/Chat mode limits or personal account entitlements. Model catalog, chat product UI, provider memory and quota are different observations. Capabilities unavailable via supported, permitted and authorized means stay UNKNOWN, not guessed from DOM/CSS, other users or model narrative.
3.3 Official OAuth 2.0 discovery data (RFC 8414), when offered, can describe authorization-server endpoints; it is NOT proof of identity or API access entitlement. Validate issuer, TLS certificate, exact host and signature/metadata according to interface before using; never substitute a page claim for authenticated session binding.
3.4 Support conditional HTTP fetch with ETag/If-None-Match or Last-Modified where available (RFC 9111); set explicit allowlisted origins and bounded timeout, response size, redirect count, content type, pagination, request count and budget. Reject SSRF, private-address pivots, untrusted redirections, HTML instruction injection and unsigned caller-supplied override. Observe robots/terms and avoid unsupported account automation or CAPTCHA bypass.
3.5 Do not call an AI model to draft or resolve the profile. An AI may propose research leads, but only authenticated adapters and explicit authorized human review can modify trusted catalogs, trust anchors, entitlement records or approved routing tables. Persist source evidence and digest, not its ability to tell the AI what to do.

4. REFRESH AND COST CONTROL
4.1 Default provider-profile validity interval is 21,600 seconds (six hours) after the last SUCCESSFUL verified refresh, based on the trusted UTC clock; last unsuccessful attempt NEVER extends expiration. Separate fast-expiring account/session availability and quota from relatively slow published provider facts; each field/category carries its own minimum freshness requirement and evidence.
4.2 Before each worker contact, GetWorkerContinuity checks local profile schema, latest approved catalog revision, snapshot integrity and expiration in fixed logic. If fresh, use it WITHOUT mandatory remote discovery. If expired, initiate a bounded refresh, deduplicated by provider+surface+selector and account scope, with one in-flight request per key. Avoid request stampedes and periodic refresh for unused providers unless justified by actual demand.
4.3 A six-hour timer/scheduler MAY refresh active profiles proactively if one is actually installed and authorized. There is no imaginary background refresh. Time sync policy in RFC-AI 8 has its OWN independent six-hour interval and state; never conflate provider checks with master_clock.txt or equate expiration with provider quota-reset time.
4.4 Cheap pre-contact validators MAY run more frequently only when provider supports an inexpensive authenticated metadata/ETag check and costs, API rules, privacy, quotas and resource use have been reviewed. No full model call, credit-consuming generation or account automation merely to check a profile. Do not assume HEAD or ETag support.
4.5 Timeout, HTTP 429/Retry-After, quota exhaustion, 403, changed schema, unavailable connector, TLS errors and network failure must be distinguished; apply bounded retry with jitter and circuit-breaker/backoff. An expired snapshot can remain VISIBLE as STALE evidence with its original timestamp, but MUST NOT authorize a new capability, mode or protected operation. Repeated errors trigger at most one actionable alert per defined interval.
4.6 On revocation/security advisories, authenticated event notifications or observed unsupported operations, invalidate the affected capability immediately, without waiting six hours. Known unsafe paths fail closed; unrelated permitted read-only work may continue. Provider removal or deprecation is recorded as an explicit status with recommended manual review, not silent deletion or alias reassignment.

5. MODE SELECTION, FALLBACK AND CONTINUITY
5.1 Provider-specific routing defaults are explicit DATA in an approved adapter. For the CEO-designated ChatGPT.com worker using a blank selector, preferred "working-mode" is "work" and fallback is "chat" when Work usage limits or unavailability are independently observed AND mode change is supported by an authorized accessible interface. The preference MUST NOT be generalized to all providers. When Work becomes verified usable again, return to Work at a safe task boundary.
5.2 The current mode and detected availability are RUN/SESSION CONTEXT, not a rewrite of the identity JSON or mode-independent worker authority. Record mode selection, verified evidence, UTC observation, reason, task checkpoint, provider capability snapshot revision, and user-visible limitations; never claim switching succeeded without an observed result.
5.3 A plain model response such as "I hit my Work limit" or a DOM label is not by itself independent provider proof. If an interface offers only a visible user message, label the observation UI_REPORTED/UNVERIFIED until independently confirmed. Without a supported switch-control interface, return MANUAL_SWITCH_REQUIRED and the smallest requested human action; do not manufacture API access, navigate undocumented UI invisibly, or bypass usage limits.
5.4 Before switching, persist exact current task and idempotency key, last independently verified operation and pending action. Resolve the authenticated new session to the SAME tuple, re-deliver GetWorkerContinuity and fresh GetWorkerContext, re-evaluate per-mode tool permissions and continue only if the mode can actually perform the required task. Distinct model/agent sessions do not share hidden state; loss of session or tool availability is reported explicitly.
5.5 An automatic fallback cannot silently change provider, account, selector, privacy boundary, chargeable plan, training role or privileged execution rights. Provider migration between identities requires separate authenticated human authorization and a task handoff; there is no implicit identity transfer. Never repeat non-idempotent side effects while retrying or switching; reconcile provider receipts first.
5.6 Rate limits may apply to API organization, project, model, user or UI mode differently. A general model list or public plan document cannot predict an account's remaining Work allowance. Do not invent reset timestamps; use only observed provider signals with documented semantics.

6. OWNERSHIP, ENFORCEMENT AND STORAGE
6.1 RFC-AI 34 owns the separate PROVIDER_PROFILE and private ACCOUNT_CAPABILITIES record classes, their human-readable names, exact canonical Drive source ID/revision, and access control. Maintain one canonical logical profile per approved provider+surface+selector and one private account-specific overlay as needed. Do not create hidden local authoritative master caches or duplicate folders. An in-memory disposable cache is permitted for efficiency.
6.2 RFC-AI 33 exclusively governs the tuple and nickname. RFC-AI 35 joins only the authorized snapshot and displays its freshness and unknowns. RFC-AI 36 governs session/target/current working-mode as operating context. RFC-AI 19 routes supported model and tool operations based on these verified capabilities; RFC-AI 32 enforces exact protected actions regardless of whether Work or Chat is selected.
6.3 Provider-profile refresh is authorized READ/OBSERVATION, not a grant to change provider credentials, policy, quotas or CEO directives. Trusted provider changes are untrusted as corporate INSTRUCTIONS and cannot modify tool permissions, founder roles or approved RFC status. A compromised documentation endpoint cannot promote a previously forbidden tool.
6.4 Catalog/profile writes use authorized service principal, expected revision, guarded transaction/readback, privacy controls and append-only verification events. Preserve accepted previous snapshot on parse, source or integrity failure; make degradation explicit. API-credential use MUST be scoped to the approved provider adapter, protected from AI access, and audited without token exposure.
6.5 Distinguish generic framework design from site-specific deployment configuration. This RFC alone cannot establish a six-hour scheduled process, browser automation, or live ChatGPT mode switching.

7. DAVG ACCEPTANCE TEST MATRIX — CEO REVIEW REQUIRED
7.1 Same four-field identity, nickname, task and source permissions across work→chat→work; working-mode never enters composite key; optional blank selector survives JSON serialization and equality checks.
7.2 Fresh-profile contact creates zero remote refresh calls; expiration triggers one deduplicated refresh despite 100 concurrent worker contacts; failed refresh does not alter last_success_utc; 304 response validates only matching source/endpoint and field coverage; 429 respects Retry-After and bounded backoff; malformed response never becomes trusted.
7.3 Public model catalog may report a model yet account entitlement remains UNKNOWN; adapter claiming unavailable ChatGPT UI controls MUST NOT claim automatic Work↔Chat switching. Unsupported account/mode returns explicit MANUAL_SWITCH_REQUIRED or UNKNOWN.
7.4 Work limit with verified signal causes checkpoint before authorized Chat fallback and exactly-once EFFECT verification; expired policy, missing tool, wrong account and revoked permissions block action. Resumption uses fresh continuity and fresh context; worker identity remains unchanged.
7.5 Attacker-controlled URL redirects to loopback, credential-bearing log, forged provider notice, untrusted DOM, made-up providerUID or unapproved adapter changes all fail trust/authorization checks; source payload is data only.
7.6 Alter provider schema, switch modes, revoke a capability, and force six-hour clock expiration and clock rollback. Verify no hidden additional refresh and clock drift not misinterpreted as quota reset. Test offline provider and fresh/stale/unknown statuses distinctly.
7.7 A profile without effective provider interfaces is not falsely certified as continuously up-to-date. All failures and missing dependencies remain BLOCKED with precise evidence; mandatory CEO edition approval and runtime acceptance are separate.

8. EXTERNAL RESEARCH BASIS — ACTUALLY REVIEWED FOR THIS DRAFT
8.1 RFC 9111 HTTP Caching — authenticated validators, conditional requests, validated freshness, explicit stale handling. https://www.rfc-editor.org/rfc/rfc9111.html
8.2 RFC 8414 OAuth authorization server metadata — authenticated endpoint discovery, NOT model entitlements. https://www.rfc-editor.org/rfc/rfc8414.html
8.3 OpenAI API model listing exposes models, not ChatGPT Work usage or mode controls. https://developers.openai.com/api/reference/resources/models/methods/list
8.4 OpenAI rate-limit guide details API-specific headers, organization/project limits and 429 signals; do not project to a consumer chat account. https://developers.openai.com/api/docs/guides/rate-limits
8.5 Anthropic model list and deprecation notes — provider-specific capabilities and lifecycle. https://platform.claude.com/docs/en/api/models/list and https://platform.claude.com/docs/en/about-claude/model-deprecations
8.6 Gemini models.list exposes supportedGenerationMethods and model limits; no generic API exposes another provider's quotas. https://ai.google.dev/api/models
8.7 OWASP LLM prompt injection — do not treat retrieved text or AI output as authority; enforce actions at tool boundary. https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
8.8 Temporal event history and LangGraph persistence distinguish durable work state and long-term sources from current ephemeral sessions. https://docs.temporal.io/workflows and https://docs.langchain.com/oss/python/langgraph/persistence

9. DESIGN STATUS, UNRESOLVED IMPLEMENTATION DEPENDENCIES AND CHANGE RECORD
9.1 OPEN implementation dependencies: approved provider catalog and endpoints, availability of account entitlements for each provider, supported mode-changing interfaces, permitted use of chat UIs, verified account/session binding, reliable source revision controls, service scheduler and independent security boundary. These are honest technical UNKNOWNs, not presumed features.
9.2 This specification is a DRAFT. It is not a new release gate, a running discovery service, a working ChatGPT Work fallback, or permission to bypass third-party controls. Only CEO approval can authorize an edition and release, subject to implementation evidence.
2026-11-02 UTC — Initial DAVG-researched RFC-AI 37 draft; source legacy comparison RFC-AI 12/19/33–36 and Corporate Extension nickname/history. No production change.


DOCUMENT CLASSIFICATION — RFC-AI RESEARCH-FIRST RECONCILIATION (2026-11-02T20:28:09.285Z)
DOCUMENT CLASS: STANDARD — TECHNICAL STANDARD DRAFT
This document contains normative technical format, protocol, security, interface, or evidence contract detail for its defined subject. The detail is an intended Standard rather than evidence that software has been built or deployed. Legacy software and its records are background research only; no RFC-AI component is implemented.
DAVG judges future objectives and observed results, rather than presuming legacy implementation or declaring these drafts active. CEO approval and independently observed operational evidence are still required for any future activation.


## HISTORICAL FAILURE EVIDENCE — RESEARCH ONLY; NOT AN RFC-AI IMPLEMENTATION
Historical context: Browser features and provider accounts were assumed capable or entitled without live provider/session evidence.
Historical reports have mixed evidence quality; verify primary facts before adopting a claimed root cause. Preserve source provenance and do NOT operationalize retired legacy policies as current RFC authority.

## MUST-DESIGN CRITERIA — CEO-DIRECTED PROPOSED FUTURE SYSTEM
MUST-37-UTC: Any current UTC datetime, timestamp, deadline, source-freshness comparison, expiry, or chronological identifier MUST obtain current time through GetUTCDateNow() or its approved typed Time Interface result. AI workers and application code MUST NOT read a host local clock directly for corporate decisions. The Time Interface owns actual synchronization, drift detection, freshness evidence and explicit uncertain-clock handling; a stored expiration alone never proves clock correctness. This is a future design obligation, not an implemented service.

MUST-37-01: MUST distinguish documented feature, observed provider profile, current authenticated account entitlement and current available session mode.
MUST-37-02: MUST NOT authorize privileged actions from a feature list or provider name; unsupported/unknown capabilities prompt authorized investigation, not fabricated capabilities.

IMPLEMENTATION STATUS: Entire RFC-AI system NOT IMPLEMENTED. Historical systems are independent past research material; no test or existing service may be counted as implementing this RFC-AI.


## ADDITIONAL MUST-DESIGN CRITERIA — 2026-11-02 (PROPOSED, NOT IMPLEMENTED)
Historical trigger: legacy materials repeatedly confused authored progress, scripts and document content with real observed execution; this is research evidence, not proof of any new RFC implementation.
MUST: Feature published by a provider is not actual authenticated entitlement. Record supported platform/browser/OS/API mode and compatibility evidence per assignment.
MUST consider the concrete literal behavior of competent AI workers and enforce required hard safeguards by simple, separately running Interface logic where an actual boundary exists. MUST not delegate Interface internal details back to this guiding document. MUST preserve the requirement in relevant top-level objectives.txt and independently verify that future implementation satisfies it. New requirements here remain draft, not live controls.

## DESIGN AMENDMENT 2026-11-03 — ACTUAL ENTITLEMENT MATRIX
REQ-AI-37-CAP-001: Context MUST distinguish feature advertised, tool exposed, account actually entitled, runtime actually reachable and worker currently authorized; a mounted cloud drive does not establish remote durability.
REQ-AI-37-CAP-002: Independent Context MUST exist before task assignment. A later assignment-target compatibility overlay must preserve baseline context and include verified capability source, observed UTC, expiry and UNKNOWN values.