PlaysbyMoat8
Back to the library
The workflow guideFinance

Route investment requests by their purpose

Give capacity, risk and other investment proposals the appropriate review path.

6 implementation stepsIntermediate

How this works

Give capacity, risk and other investment proposals the appropriate review path.

Route an investment proposal according to the decision it asks the business to make. Capacity expansion, risk reduction and mandatory replacement need different supporting evidence; a project label should not substitute for the applicable approval policy.

Before you start

Defined operating scope

Capital requests have different purposes and require distinct supporting evidence and approval paths.

Required source material

Obtain Investment request; Expected effect; Approval policy. If connectors are unavailable, use authorized files with the same fields.

Decision and exception rules

A capacity request has no evidence of the claimed bottleneck. Request the relevant operating analysis before presenting expansion as justified.

Prepare the inputs

request_id
Required

Proposal, amount and sponsor

Specify currency and requested decision.

purpose
Required

Capacity, risk, replacement or other stated goal

Allow mixed purposes with separate evidence.

supporting_analysis
Required

Expected effect and assumptions

Distinguish measured constraint from asserted need.

approval_policy
Required

Thresholds, roles and required evidence

Use the current applicable version.

Implementation, step by step

  1. Establish the working record

    • Confirm the selected records, effective versions and responsible owner.
    • Check request_id, purpose, supporting_analysis, approval_policy before beginning. Record the source version and the selected scope; an unavailable value stays unknown rather than becoming an inferred fact.

    Checkpoint: The input record identifies the selected request_id and any missing required fields.

  2. Classify the request’s purpose

    • Classify the proposal’s purpose from the actual requested effect and identify mixed-purpose components.
    • Check routing against the exact policy version, amount and purpose.

    Checkpoint: A saved intermediate result for: Classify the request’s purpose.

  3. Collect the relevant supporting analysis

    • Collect the evidence relevant to that purpose, such as constraint data, risk assessment or replacement condition, retaining gaps.
    • Verify every claimed effect is supported or explicitly marked as an assumption.

    Checkpoint: A saved intermediate result for: Collect the relevant supporting analysis.

  4. Route it to authorized reviewers

    • Determine authorized reviewers from policy and amount, then route a review-ready packet or a targeted request for missing analysis.
    • Check routing against the exact policy version, amount and purpose.

    Checkpoint: A saved intermediate result for: Route it to authorized reviewers.

  5. Reconcile the proposed result

    • Check routing against the exact policy version, amount and purpose.
    • Verify every claimed effect is supported or explicitly marked as an assumption.

    Checkpoint: The listed discrepancies have a named reviewer or an explicit unresolved status.

  6. Package the result and unresolved work

    • Validate constraint assumptions and applicable approval authority.
    • Routing prepares a decision; it does not approve spending or financing.

    Checkpoint: A review-ready investment request. Unresolved items remain visible in the review record.

Decisions along the way

A capacity request has no evidence of the claimed bottleneck.

Request the relevant operating analysis before presenting expansion as justified.

The amount crosses a policy threshold.

Use the corresponding approval route and do not split the request to evade it.

The proposal combines purposes with different reviewers.

Include the required reviewers and preserve separate rationale for each component.

What you will produce

capital-request-routing-result.json

JSON

A review-ready investment request. Label proposed and completed states separately.

Include: request_id · purpose_classification · amount · evidence_checklist · analysis_gaps · required_reviewers · routing_status · status · evidence_reference · review_note

capital-request-routing-review.md

Markdown

Keep the evidence and unresolved decisions needed to apply this result, including exceptions involving approval_policy.

Include: source_reference · question · owner · next_action

Check the result

  • Check routing against the exact policy version, amount and purpose.
  • Verify every claimed effect is supported or explicitly marked as an assumption.
  • Inspect request_id and purpose in both the original and output; confirm that record identity and interpretation survived the transformation.
  • Validate constraint assumptions and applicable approval authority.

When something goes wrong

A capacity request has no evidence of the claimed bottleneck.

Request the relevant operating analysis before presenting expansion as justified. Retain the affected evidence and recovery status.

The amount crosses a policy threshold.

Use the corresponding approval route and do not split the request to evade it. Retain the affected evidence and recovery status.

The proposal combines purposes with different reviewers.

Include the required reviewers and preserve separate rationale for each component. Retain the affected evidence and recovery status.

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Request

Route investment requests by their purpose for the following bounded example; prepare the result for review.

Inputs

Synthetic example: Request R-5 proposes equipment costing 50,000 units for capacity expansion. Policy requires operations and finance review above 40,000; no bottleneck data is attached.

Expected result

Synthetic expected result: Route to operations and finance with status evidence incomplete and a request for constraint analysis. Do not mark the investment approved or infer expected return.

Run a small pilot

Start small

Trial a representative batch containing the ordinary case and the exception demonstrated above.

Record the baseline

Record current preparation time, review effort and correction types for the same records.

Agree success criteria

Agree acceptable review and error limits; measure correct reviewer routing; requests returned for missing or mismatched analysis.

Stop or revise

The proposal combines purposes with different reviewers. Pause affected records and apply this recovery: Include the required reviewers and preserve separate rationale for each component.

Keep the scope clear

  • Routing prepares a decision; it does not approve spending or financing.
  • Qualified owners assess investment assumptions and authority.

Check before using

Validate constraint assumptions and applicable approval authority.

Business activities

  • Raise capital or evaluate investments

Editorially adapted workflow; not independently tested.

FROM A RECIPE TO YOUR WORKFLOW

Bring the company context together.

This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.

For this recipe: Investment request · Expected effect · Approval policy

Start with one recurring task, agree which sources to use, and review the first result with your team.

Discuss this workflow

What does your team do?

Choose the recurring work you would like to improve.

A field guide, made for work.

Plays is a curated library of anonymized business workflows. Each recipe explains the inputs, steps, tools, and checks you can adapt to your team. These are editorial guides, not independently tested implementations.

When you share a company website, the guide may read a limited number of public pages on that website. Messages and retrieved page text are sent to our AI provider, NVIDIA, to recommend relevant workflows. Share a general description rather than confidential information.

Saved workflows and selected activities stay in this browser. Your chat history and selected company website are kept in this tab and cleared when you reload or start a new chat. The server does not store conversations. Live source monitoring is not enabled.

If you allow analytics, PostHog receives page views and actions such as workflow saves, skill downloads and link clicks. Random browser and session identifiers connect these actions without identifying you by name. Your choice and browser identifier expire after 90 days; sessions restart after 30 minutes of inactivity or 24 hours. We use local storage, not analytics cookies. Messages, company URLs, search text, full referrers and IP addresses are not sent. There are no person profiles or session recordings. You can decline or withdraw in Analytics settings; Do Not Track and Global Privacy Control keep analytics off.

Read the Plays Privacy Notice ↗