An article can tell a team that something changed. A proposal must establish whether that change applies to its system, what work remains and how the result will be verified.
The AI Control Layer connects these steps through documentation and evidence. This guide uses the app's existing proposal process as a reference. It does not create or approve an app implementation item.
Preserve the source and its uncertainty
For an announcement, record the original publisher, primary URL, publication date, effective date, product/version and availability conditions. For an observed failure, preserve a sanitized input and the result that failed your acceptance check.
Do not convert “the provider announces a preview” into “our app supports it.” Do not treat a failed prompt as proof of a server authorization defect without checking the executable path. Use the news-reading guide and evaluation-set guide for those earlier steps.
Verify the relevance in current source
Identify the exact connection, route, function, configuration or document involved. Record the source revision. Determine whether the feature is absent, implemented but disabled, deployed without setup, or working with inaccurate documentation.
These states require different work. A missing credential is not automatically a coding task. A stale article may need an editorial correction. An unavailable account feature may require a test to be marked blocked rather than a patch.
Read generated references as inventories with stated coverage. They can help locate a route; they do not establish its permissions or a live provider result.
Reuse the canonical work item
In OpenTechnologyApp, intake searches the existing proposal queue and registry before adding work. One outcome has one canonical parent. The agent instruction source and generated companion point contributors to that workflow.
The current AI-control documentation provides a concrete example: read/navigation tools are present in the inspected dispatcher, while confirmable item writes remain in the existing AI-03 work. An article asking for AI writes should link to that work rather than creating a competing implementation plan. Scoped machine API access likewise has an existing AUTHSEC-05 design boundary.
These are source and proposal states, not promises of hosted availability. See the app control guide.
Build a contract someone else can test
Use a brief with the following fields:
| Field | What the reviewer needs |
|---|---|
| Source and finding | Exact evidence, date and applicability |
| Current behavior | Source revision, reproduction and uncertainty |
| Canonical work ID | Existing owner or justified new parent |
| Actual approval | Who authorized which scope; pending remains pending |
| Proposed behavior | A concrete input and expected outcome |
| Boundaries | Roles, organization/project scope, tools and provider transfers |
| Verification | Positive, negative, retry and recovery outcomes |
| Rollout and cleanup | Configuration, release evidence and reversal |
| Documentation | README, generated sources, setup and public claims affected |
For a documentation-only update, say there is no runtime change. For a mutation, specify what happens after a lost response or repeated request. Do not substitute a disabled button for a persistence or idempotency design.
Follow an actual documentation intake
The AI Control Layer documentation itself provides a completed source example. On September 13, 2026, the owner asked to connect README/generated docs, agent-controlled proposals and marketing. That request became DOCS-06 under the existing agent-documentation proposal; it did not create a new AI runtime workstream.
| Intake field | Recorded result |
|---|---|
| Source | Explicit owner request for the documentation connection |
| Canonical work | DOCS-06, existing agent-documentation proposal |
| Authorized scope | Documentation, generated instruction alignment and marketing handoff |
| Runtime impact | No new provider calls, permissions, document retrieval or mutation tools |
| Source outcome | Contract, README/setup links, proposal-template fields and regenerated AGENTS |
| Evidence | Local generator/proposal checks and the app gate sweep passed |
| Release state | Source pushed for review; public availability is a separate check |
This is a documentation example, not a news-origin incident. It shows how a verified source and actual authorization can be preserved without claiming they approve adjacent runtime features.
Use a teaching example without inventing news
Imagine a verified finding that a provider setup instruction names a retired configuration field. This is a hypothetical exercise, not a report about any real provider.
First compare the actual installed version with its official setup documentation. If runtime configuration already uses the supported field, the outcome may be a documentation fix. If code still uses the retired field, map the exact adapter change, credential handling, compatibility window and tests into the existing integration proposal.
If no current source confirms the retirement, keep the finding unverified. Do not publish it as news or build a migration from it. The research result may simply be “insufficient evidence.”
Return evidence to the public explanation
After implementation, record the tests actually run, their limits, the deployed version and the observed outcome. Update affected README/setup guidance and regenerate references from their sources. Give marketing only the sanitized claim supported by that evidence.
If a release is still pending, keep that state visible. A generated proposal, a merged document and a successful local test are different events. The public wording should identify the one that actually happened.