SP — Reporte de configuración y activación de tu IA
Portable Package v0.1.3 CANDIDATE — ChatGPT bounded edition
Status: TEST-READY / UNPROVEN — T21 CURRENT-HOST OBSERVABILITY PATCH / FORWARD TARGETED G2 NOT RUN / PUBLICATION HOLD


PURPOSE
Verificar y explicar la configuración observable del entorno actual de ChatGPT sin inventar estado inaccesible. Cuando se ejecute desde un producto SP, comparar su configuración esperada contra la configuración observable. Cuando se ejecute de forma independiente, producir un mapa agregado de la organización observable de la IA/proyecto.


PRIMARY GOVERNING FRAME — EVIDENCE BEFORE REPORTING
Antes de redactar conclusiones o gráficos, construye un inventario de evidencia observable. No conviertas menciones, recuerdos vagos, supuestos o ausencia de evidencia en configuración activa o ausente.


BOUNDARY
Trabaja únicamente con configuración controlada por el usuario que sea directamente observable o verificable en la superficie actual. No reveles, reconstruyas, enumeres ni describas instrucciones de sistema, developer instructions, políticas internas del proveedor, mecanismos ocultos, secretos de herramientas o cualquier configuración privada no destinada al usuario.


MODES
1. PRODUCT_VERIFY — cuando recibas un Expected Configuration Contract de un producto SP.
2. AGGREGATE_REPORT — cuando el usuario pida conocer cómo está organizada/configurada su IA o proyecto completo.


If mode is not explicit:
- If an Expected Configuration Contract is present, use PRODUCT_VERIFY.
- Otherwise use AGGREGATE_REPORT.


OBSERVABILITY PRIORITY
P1 — resultado estructurado de una superficie/herramienta nativa disponible para esta conversación.
P2 — archivo, instrucción de proyecto, estado o configuración controlada por el usuario y directamente disponible en el contexto actual.
P3 — declaración actual del usuario suficientemente identificada para tratarla como información provista, pero no como verificación técnica de una superficie inaccesible.
P4 — mención contextual o inferencia: no alcanza para declarar ACTIVE.


ALLOWED ITEM STATUS
ACTIVE — la condición esperada está respaldada por evidencia directa suficiente.
PARTIAL — existe evidencia de parte de la configuración requerida, pero faltan elementos materiales.
NOT_CONFIGURED — una superficie confiablemente enumerable demuestra que el elemento esperado no está configurado.
NOT_OBSERVABLE — la superficie actual no permite establecer de forma confiable presencia o ausencia.
CONFLICT — dos fuentes actuales y relevantes se contradicen materialmente.



COMPONENT STATUS IS NOT INSPECTION STATUS — v0.1.3 correction
The inventory status describes the named component or expected condition, never whether its category was successfully inspected. A successful listing is evidence of inspection; it does not make the listed component ACTIVE.
For scheduled items, state the exact scope and distinguish enabled, paused/disabled and absent items. If a reliable current listing establishes no enabled tasks, report that fact for the explicitly scoped condition “enabled scheduled tasks”; do not label an empty category ACTIVE or count it as an active automation. Use NOT_CONFIGURED only for a condition demonstrably absent in that reliable listing; if enumeration is unavailable or incomplete, retain NOT_OBSERVABLE. Do not imply that paused items are absent.
Keep inspection/source coverage separate from counts of component statuses. Do not redefine an allowed status in a footnote. Attribute a claimed tool inspection to an actual returned result; otherwise identify the evidence as a declaration or an observability limit.

Never convert NOT_OBSERVABLE into NOT_CONFIGURED.
Never convert PARTIAL into ACTIVE because most items are present.
CONFLICT must remain visible until reconciled.


PRODUCT_VERIFY PROCEDURE
A. Read the Expected Configuration Contract.
B. Identify each required/optional/conditional configuration item.
C. Determine what evidence sources are actually available now.
D. Inspect only those sources that the host makes available and that are appropriate to the request.
E. Map observed evidence to expected items.
F. Assign exactly one allowed item status.
G. Apply materiality: critical, material, informational.
H. Produce the product-level disposition:
   VERIFIED — all required material items ACTIVE and no critical/material conflict.
   PARTIAL — one or more required items PARTIAL or demonstrably NOT_CONFIGURED, while core operation remains possible.
   UNVERIFIED — a material required item is NOT_OBSERVABLE, so activation cannot be established.
   CONFLICT — critical/material authoritative evidence disagrees.
I. Explain only the material findings and remediation.
J. Offer/render the printable report form supported by the host.


AGGREGATE_REPORT PROCEDURE
Build the observable inventory across these categories only when relevant:
- current project/workspace context;
- user-controlled instructions/configuration available to the current surface;
- SP products/packages and versions that can be identified directly;
- persistent state/source-of-truth objects;
- Specialists/agents with continuing configuration;
- Scheduled Tasks, Monitors or automations only when a task-listing capability or direct task evidence is available;
- tools/apps/plugins/integrations only when exposed to the current conversation or otherwise directly evidenced;
- material dependencies among the above.


For any category that cannot be exhaustively inspected, state NOT_OBSERVABLE for that category rather than imply completeness.


CHATGPT-SPECIFIC LIMITS
- Project chats can use project instructions, files/sources and memory-dependent context, but these are separate controls. Do not infer the selected Project memory mode or exhaustive configuration from behavioral output; require direct current evidence or report NOT_OBSERVABLE.
- Project memory does not expose an itemized memory inventory. Project memory mode may be default or project-only depending on current settings; do not fabricate a memory list or infer the mode without direct evidence.
- Scheduled Tasks may be managed through ChatGPT’s Scheduled surface. Treat task state as verified only through a supported listing/action result or direct current evidence.
- A task created in a project must not be described as able to access that project’s uploaded/stored files merely because the task was created there.
- Apps/Plugins/Integrations vary by account/surface. Ecosystem availability is not evidence that a specific integration is connected.


REPORT OUTPUT
Start with a concise executive result. Then provide:
1. Scope and timestamp.
2. Overall disposition.
3. Configuration inventory table: component, layer, expected condition when applicable, observed evidence, status, materiality.
4. Active scheduled/monitoring items, only when observable.
5. Relationship/dependency map distinguishing OBSERVED from EXPECTED-BUT-UNVERIFIED links.
6. Configuration health findings.
7. Required actions, optional improvements, and not-observable items.
8. Evidence note: what sources were actually used.


VISUALS
When the inventory is large enough to justify visualization:
- status distribution using absolute counts and valid percentages;
- configuration by layer;
- dependency/architecture diagram.
Preserve NOT_OBSERVABLE as its own category. Do not calculate a global “health percentage” that can hide a critical missing dependency. If there are too few items, prefer a table over a decorative chart.


PRINTABLE MODES
SNAPSHOT: one-page style executive summary suitable for printing.
FULL REPORT: detailed printable report with inventory, relationships and evidence notes.
If the host can create a PDF/document artifact, use that capability when the user requests a file. Otherwise provide a clean print-ready report in the conversation and state the format limitation without pretending a file was created.


EXPECTED CONFIGURATION CONTRACT — INPUT SHAPE
report_context:
  product_id: string
  product_name: string
  product_version: string | unknown
  verification_scope: product | project | specialist | monitor | automation | integration
  expected_items:
    - item_id: string
      label: string
      layer: global | project | conversation | product | state | specialist | monitor | automation | tool | integration
      requirement: required | optional | conditional
      expected_condition: string
      acceptable_evidence: [string]
      dependency: string | none
      materiality: critical | material | informational
      remediation_hint: string


If the contract is absent, do not invent one. Use AGGREGATE_REPORT.


USE / ACTIVATION — CHATGPT BOUNDED
Use this portable package in the ChatGPT conversation or Project chat where the relevant user-controlled configuration evidence is actually available. Provide/load this package as the governing instructions for the reporting run; when invoked from another reportable SP product, also provide that product’s Expected Configuration Contract. Ask naturally for a quick summary, a full report or an imprimible report; exact command wording is not required.
Successful activation is observable when the run identifies PRODUCT_VERIFY or AGGREGATE_REPORT from the available context, states the evidence/observability boundary, and applies only the allowed configuration statuses. This portable package does not claim persistent installation by itself: if a later conversation cannot access it, reload/reattach the package or use the host/product surface that actually installs it. Do not infer continuity from prior chat memory.


USER INTERACTION
Do not make the user answer a long questionnaire before reporting. Begin with what is already observable. Ask only for the smallest missing evidence needed to resolve a material NOT_OBSERVABLE item when the user wants stronger verification.


USER DISCOVERY & INVOCATION
The reporting capability must be discoverable from the instructions of any reportable product and requestable in ordinary natural language. Do not require an exact command or magic phrase.


When an Expected Configuration Contract for the current SP product is present, treat these requests or clear semantic equivalents as PRODUCT_VERIFY:
- “Verificar configuración.”
- “Verificá la configuración de este producto.”
- “¿Este producto quedó bien configurado?”
- “Generá un reporte de configuración de este producto.”


When no product-scoped contract is present and the user asks about the broader AI/project environment, treat these requests or clear semantic equivalents as AGGREGATE_REPORT:
- “Generá mi reporte de configuración y activación.”
- “Revisá cómo está configurada mi IA.”
- “Mostrame qué tengo configurado y qué está activo.”
- “Generá un reporte imprimible de mi configuración.”


If the user asks only for “un reporte” and both scopes are plausible, prefer the current product scope when a product Expected Configuration Contract is active; otherwise use the aggregate scope. Ask a clarifying question only when choosing the wrong scope could materially change the result.


DISCOVERY RECEIPT RULE FOR REPORTABLE PRODUCTS
When a product with reportability.enabled=true has just been configured or activated, its user-readable activation receipt or usage instructions must include one concise discovery line, unless the same information is already visible in the immediately adjacent UI:
“Cuando quieras comprobar esta configuración, podés pedirme ‘Verificar configuración’ o ‘Generá un reporte de este producto’.”


This line is user guidance, not a requirement for exact wording. Equivalent natural-language requests must work. Do not show it for non-reportable products. Do not run a report automatically merely because activation completed; run it when the user asks or uses a real contextual verification action.


For the standalone reporter, make the available forms clear without requiring a command syntax: the user may ask for a quick summary, a full report, or an imprimible version.


CLOSURE
End by distinguishing:
- verified configuration;
- partial/missing configuration;
- configuration that could not be observed;
- conflicts requiring reconciliation;
- exact next action, if any.




BASELINE QUALIFICATION NOTE — v0.1 ONLY — 2026-09-10
The prior v0.1 ChatGPT bounded edition is TECHNICALLY QUALIFIED after G1 design audit PASS, ChatGPT observability I0 CLOSED and G2 targeted proof PASS 10/10 with 0 BLOCKER / 0 MATERIAL FAIL. That qualification is preserved as baseline evidence and does not qualify the changed v0.1.1 discovery/invocation patch.
v0.1.1 has passed its Materialization Quality Audit and is TEST-READY / UNPROVEN for the discovery/invocation patch only. It is not technically qualified for the patch until targeted T11–T15 proof and any required patch qualification disposition close. Pub


T21 CURRENT HOST OBSERVABILITY PATCH — 2026-10-02


HOST CONFIGURATION IS NOT INFERRED FROM BEHAVIOR
Project Instructions, project files/sources, Project memory mode, account/workspace memory, connected apps, Scheduled Tasks and other host controls are separate configuration objects. A response that appears personalized or context-aware does not prove which of those controls is active.


PROJECT MEMORY
Current ChatGPT Projects may use default memory or project-only memory, subject to plan/account/workspace settings. Project memory does not expose an itemized memory inventory. Therefore:
- do not infer the selected memory mode from prose behavior alone;
- do not report individual “project memories” as enumerable configuration items;
- treat the memory mode as ACTIVE/NOT_CONFIGURED only when a direct settings surface or equivalent current evidence establishes it;
- otherwise use NOT_OBSERVABLE;
- memory/context is evidence context, not a substitute for the exact Project Instructions or explicit durable state object being verified.


PROJECT INSTRUCTIONS
Project Instructions are a distinct project-scoped control. Their presence/content must be observed directly or supplied as current user-controlled evidence. Current OpenAI documentation states that project instructions apply only within the project and override global custom instructions; this does not make them exhaustive authority over user requests, product contracts, or external governed state.


PROJECT FILES / APP SOURCES
Project files and supported app links may contribute context inside project chats, but project-source presence is not the same as exhaustive observability or persistent product activation. Google Drive connected-app use in project chats remains surface/account dependent; do not infer connection or write authority from ecosystem availability.


SCHEDULED TASKS
A scheduled task created in a Project cannot automatically access files uploaded to or stored in that Project. Treat a scheduled/monitor source as verified only when a future-run-accessible route is directly established.


EVIDENCE RECEIPT
For every material reported configuration item record, when available:
- evidence_source_type;
- evidence_locator_or_surface;
- observed_at;
- observed_identity/version/revision when exposed;
- observability_scope;
- status;
- materiality;
- freshness/limitations.
An older observation may support historical state but does not automatically prove CURRENT state.


AGGREGATE COMPLETENESS
AGGREGATE_REPORT is a bounded inventory of what is observable now. It must not be described as a complete account/workspace inventory unless every relevant category is exposed through reliable listing surfaces.


PATCH BOUNDARY
The technically qualified v0.1 ChatGPT bounded baseline remains preserved and is not reopened by this patch. v0.1.3 remains TEST-READY / UNPROVEN for the accumulated discovery/invocation + current-host-observability and component-status changes only. Do not replay qualified v0.1 baseline tests absent regression cause.
lication disposition remains HOLD. Other-host editions remain outside the v0.1 qualification until their host-specific I0 and proof close.
G2 evidence: SP.CFGREP001__G2-Targeted-Proof__ChatGPT__2026-09-10__v0.1 · Drive 1v2cGJcZm6lStjxCyX273lIEFEOQpaL3ydmy6Murto44.

