Check that the registered material has been read accurately into a form AI can use for proposals. Compare any missing or misread text with the original and correct it.

Also check that information needed for a decision, such as the source and document date, is available. Resolve any unreadable or unclear content before moving on to analysis or proposals.

The "current version" is the content that has been formally applied and is used in operations. New evidence and proposed changes belong in a separate "version under review."

Link each version to the evidence it uses. This lets you compare what is being added or changed while keeping current operations intact.

Compare added or replaced evidence with current decisions. AI identifies where there may be an impact, explains why, and cites the evidence it used.

A person checks the AI explanation against the original material and considers whether a review is actually needed. Treat the analysis as support for a decision; its results alone do not justify approval or applying a change.

A person checks the new evidence and the impact identified by AI, then decides whether to prepare a new proposal. If information needed for that decision is missing, gather further evidence.

Record the reason whether the decision is to keep the current approach or proceed with a review. Starting a review and changing current operations are separate stages.

Check that the version under review contains both the evidence carried forward and the newly added material. Make clear what has changed and why a review became necessary.

Before asking AI to prepare a proposal, check that material from other work or outdated information has not been included by mistake.

A single perspective may not be enough to judge a proposal for business use. This guide organizes proposals around four perspectives: readiness for operations, expected benefits, model selection, and initiative priorities.

For readiness for operations, check what must be put in place before use and which issues need attention. For expected benefits, consider what improvements are expected and how you will assess them.

For model selection, consider suitable models and when to use each, taking account of the performance and cost required for the intended use. For initiative priorities, consider what to advance first and what to put on hold or review.

A proposal explains both what to do and why that response is needed. It should show what would change in current operations alongside the evidence supporting the change.

When a proposal estimates benefits or sets priorities, make its assumptions clear. Retain the reasoning behind the conclusion so that a person can judge whether the proposal is sound.

Return from the proposal to the original evidence and check whether the AI explanation reflects the material. Distinguish facts stated in the source from conclusions AI has inferred from them.

A reference alone does not make an explanation correct. A person checks for gaps in the reasoning and missing assumptions that matter to the decision.

Save AI-generated proposals as awaiting human review. Present the proposed response with its supporting evidence so that it is clear what needs a decision.

Completing generation does not mean a proposal has been approved or applied to operations. In the next stage, a person checks the content and decides whether to approve it.

AI's role is to analyze evidence and propose a response. People remain responsible for the approval decision and the procedure for applying approved content to operations.

Generating a proposal does not itself authorize a business action. The system checks which actions are allowed and their permitted scope against the approved content.

If a proposal contains errors or needs more explanation, a person reviews and corrects it. Record the content before and after the edit, together with who made it, so the changes are clear.

Saving an edit and approving the content are separate steps. Review the revised proposal again before deciding whether to approve it.

A person reviews the proposal and its supporting evidence, then decides to approve or reject it. An approved proposal can move to the stage where its changes are applied. A rejected proposal is not applied to operations.

Record the reasons for either decision. Note the information that mattered and any concerns in enough detail for someone reading the record later to understand how the decision was reached.

Approval means that the person reviewing a proposal has decided its content is acceptable for use. Applying it means making that approved content the official content used in operations.

Approval does not change the content currently used in operations. That changes only when the approved content is applied. Keeping these steps separate allows people to check the timing and operational impact after approval.

Keep a record of the proposal, the approval or rejection, the reasons, who decided, and when. Make the evidence used at the time available alongside that record.

During the next review, revisit the evidence and reasons as well as the earlier conclusion. Identifying which assumptions have changed helps you decide whether the decision needs to be reconsidered.

Before proceeding, compare the proposal's content and version with the approval record. Check that no unapproved changes or rejected proposals have been included.

If the content needs to change after approval, obtain approval again for the revised content. The next stage covers when to apply it and what needs to be prepared first.

The system checks that a person has approved the content being applied. It excludes unapproved and rejected proposals, saving only approved content as official decision records.

Afterward, a person checks the records to confirm that the intended content was applied. The system also keeps a history of what was applied and when.

After applying the changes, check the official decision records against the proposals they came from. Confirm that no approved content is missing or has been replaced with something else.

Before using a record in operations, check both that its content has been applied and that it belongs to the version needed for this work. Keep it distinct from unapproved proposals and approved content that has not yet been applied.

Before making the version under review the current version, check that the required approvals and changes have been completed. Applying some proposals and starting to use the new version as a whole are separate things to verify.

After the switch, make the new version available to users. Retain the previous version in the history and make sure it cannot be confused with the content now in use.

Keep the applied content linked to the evidence, AI proposal, and human decision. Make it possible to compare the content before and after the change and identify what changed and why.

Use this history when new evidence prompts another review. Keeping earlier decisions allows people to see the assumptions on which those decisions were based.

When there are several initiatives, compare their readiness for operation, expected benefits, and issues needing attention. Check when each decision was made and what information supported it.

People decide what to advance first using the officially applied decisions and the current business situation. Check whether the reasons and assumptions still hold, rather than relying only on priority scores suggested by AI.

Use the approved and applied content to decide who will carry out each action. Separate work done by people from processes handled by systems, and check the permissions and permitted scope for each.

Define when a person must check an action before it proceeds and who to contact if a problem occurs. Make the next steps clear enough for the people responsible to act on the decision record.

Use the approved and applied content to define execution conditions, including the available operations, the items they may act on, and the required permissions. The system checks each proposed action against those conditions.

If the conditions are not met, the system stops the action. When a person's decision is needed, it explains why the action stopped and what needs review. Design the process so that agreement in a conversation alone cannot expand the scope of permitted execution.

Make it possible to trace which evidence informed a proposal, who approved what, and when the content was applied. Retain the reasons for each decision and the content as it stood at that time.

For system execution, record what ran, what was stopped, and the reasons and results. Link these records to the decisions and applied changes so that people can check whether actions followed the approved content.

Apply the flow covered so far to a specific business process. Assign people to register evidence, review and approve proposals, and apply approved content. Set out procedures that allow each person to proceed with confidence.

Alongside routine work, consider missing information, actions outside the execution conditions, and system failures. Prepare who will respond, what must be checked before work resumes, and where the records will be kept.

Users register evidence, review proposals, approve and apply changes, and inspect history through Streamlit in Snowflake. Snowflake Cortex AI analyzes the impact of evidence and generates proposals.

Enlarge

The proposals cover four areas: Governance (preparing for operations), Value (expected benefits), Model Routing (choosing models), and Portfolio (prioritizing initiatives). Together, they are called a Decision Pack.

SQL processes check inputs and approval status before applying content to official decision records. Tables and internal stages store registration details, proposals, decision records, and original files. Original TXT and PDF files remain linked to the text extracted from them.

An AI-generated proposal starts awaiting human review. In this state, its heading and description can be edited. Saving an edit does not approve it; a person checks the content and decides to approve or reject it.

Enlarge

The interface labels these states REVIEW_REQUIRED, APPROVED, and REJECTED. Approval alone does not apply the content to official records.

Once approved content has been applied, the proposal becomes PUBLISHED and official decision records are created. Rejected proposals are not applied.

The process checks that a proposal is approved before applying it, preventing unapproved or rejected content from being written to official records. It also checks for existing records to avoid creating duplicates from the same proposal.

Enlarge

When applied content needs review, changes are handled in a new version. Earlier content is retained in the history, and the version of the proposal being approved and applied is checked.

This implementation uses sample data to demonstrate and validate the flow. The model used to generate proposals is currently fixed within the processing code. The setup is not packaged for distribution as a Snowflake Native App.

Enlarge

It records proposal edits, approvals and rejections, and applied changes, but it does not guarantee that the stored history cannot be altered. Consistently capturing decision reasons also requires a procedure or mechanism that makes entering them mandatory.

Executing or stopping work in external systems, and recording the results, must be added to suit each connected system. Before operational use, define permissions for each role, how records are retained and protected, and how failures are handled.

The GitHub documentation provides an overview of the implementation and its current limitations. Consult the architecture materials and implementation code for detailed processing conditions. Check official documentation for the specifications of Snowflake features themselves.

Links to the Google Cloud version currently in development and other materials are collected under Related resources at the bottom of the page. If needed, contact us by email.

This guide's WebMCP features help with looking up its content and navigating between steps. If useful, access them through a WebMCP-compatible browser in your AI environment.

WebMCP documentation