Proposal Workflows

# Solicitation Package Review

## User Input
- **Target source:** [GovTribe opportunity link, government/user file link, solicitation number, or source package]
- **Review focus:** [Optional focus such as PWS/SOW, Section L/M, pricing, amendments, Q&A, cybersecurity, or evaluation factors]
- **Company context:** [Optional offeror, capability, pursuit, certification, or vehicle-access context]

## Goal
Use GovTribe MCP tools to review an opportunity, pursuit, solicitation package, source package, or selected government/user files at file-text depth.
Stage source files with vector-store retrieval when record metadata and snippets are not enough.
Return a source-backed capture or proposal readout that helps the user understand the package before building a checklist, workbook, outline, bid/no-bid review, or pricing model.
Return copyable markdown only; do not create, upload, or promise DOCX, XLSX, slide, workbook, or other generated file artifacts.

## Required Input
The user must provide enough information to resolve either a file-bearing GovTribe record or a concrete set of files.

Accept any of the following:
- A GovTribe opportunity, pursuit, IDV, grant, state/local opportunity, or other record with attached files
- A solicitation number, notice ID, opportunity title, grant title, file name, or source-package description
- Government file or user file links, IDs, names, or a file set supplied by the host client
- A review focus such as PWS/SOW, Section L/M, pricing, amendments, Q&A, cybersecurity, clearances, eligibility, required forms, page limits, or evaluation factors

Input rules:
- If the input resolves cleanly to one target or file set, proceed immediately.
- If several records or files match, identify the likely candidates and ask for the minimum detail needed to choose the package.
- Do not guess deadlines, mandatory requirements, evaluation factors, pricing rules, or attachment coverage.
- Treat missing files, inaccessible files, ambiguous amendments, and partial vector-store readiness as explicit source-coverage risks.

## Workflow

### Steps
1. Call `Documentation` once with `collections=["govtribe-for-agents"]`, `article_names=["Choose a search mode and write queries", "Manage search context", "Date filtering", "Filter by related records and hierarchies", "Vector-store content retrieval", "Troubleshoot search results"]`, and `max_tokens=12000`.
   - Treat the returned guide articles as binding for exact lookup, related-record filtering, file retrieval, vector-store staging, vector-store readiness, semantic retrieval, and troubleshooting.
   - Use each selected tool schema as the source of truth for exact arguments, fields, filters, relationship fields, sorts, and response shapes.
   - If the connected MCP client does not expose a named tool, use the closest available GovTribe record, file, or vector-search tool the client provides. If no equivalent tool is available, state that limitation instead of pretending the step was completed.

2. Identify the starting point.
   - If the user supplied a record with files, resolve the record first. Use `Search_GovTribe` when the record type is unclear, `Search_Federal_Contract_Opportunities` for federal solicitations and notices, `Search_State_And_Local_Contract_Opportunities` for state/local opportunities, and the closest typed search tool for IDVs, grants, pursuits, or other known record types.
   - If the user supplied government files directly, resolve the exact files with `Search_Government_Files` or by the provided file IDs or links.
   - If the user supplied workspace or uploaded files directly, resolve the exact files with `Search_User_Files` or by the provided file IDs or links.
   - Use exact quoted identifiers for solicitation numbers, notice IDs, amendment names, file names, URLs, and IDs.

3. Build the source set.
   - For a full-package read, stage the file-bearing record when that record type is supported by `Add_To_Vector_Store`.
   - For a focused read, stage selected government or user file IDs instead of the entire package.
   - Prioritize the solicitation, RFP/RFQ/RFI, PWS/SOW/SOO, instructions, Section L, Section M, amendments, Q&A, pricing files, exhibits, forms, clauses, attachments, and related source documents.
   - When searching files, request stable metadata and summary fields such as `govtribe_id`, `govtribe_url`, `name`, `govtribe_ai_summary`, `posted_date`, and `download_url` when available. Use `content_snippet`, `parent_record`, or similar relationship-backed fields only when the tool response actually provides them; do not make them required for linking or coverage decisions.
   - Record expected but missing source documents, including missing amendments, missing attachments, unclear Q&A files, absent pricing forms, or file names that imply an attachment was not retrieved.

4. Stage files for package review.
   - Call `Add_To_Vector_Store` with the resolved file-bearing entity or selected file records.
   - Reuse a relevant completed `govtribe_vector_store_id` when the same source set is already staged.
   - Capture the returned `govtribe_vector_store_id`. If the first call omitted `govtribe_vector_store_id`, include the returned ID on follow-up `Add_To_Vector_Store` status checks along with the same source `items`; otherwise an external MCP client may create a new vector store instead of polling the existing one.
   - Follow the `Add_To_Vector_Store` response and poll until it says the requested files are ready for `Search_Vector_Store`.
   - If `Search_Vector_Store` returns chunks while some requested files are still pending, treat the chunks as partial evidence and continue polling before making final package-level claims.
   - If vector-store staging fails or is unavailable, continue with record fields, summaries, file metadata, and snippets only, then label clause-level findings as not directly verified from full file text.

5. Search the staged source package with focused questions.
   - Run targeted `Search_Vector_Store` queries for scope, PWS/SOW deliverables, performance standards, submission instructions, volume structure, page limits, required forms, evaluation factors, pass/fail rules, pricing instructions, option-year assumptions, contract type, set-aside or eligibility constraints, facility or clearance requirements, cybersecurity clauses, mandatory site visits or conferences, amendments, and Q&A impacts.
   - Prefer several focused searches over one broad query when the user needs precise evidence.
   - Keep retrieved chunks tied to the specific claim they support.

6. Synthesize the package review.
   - Separate confirmed facts, source-backed interpretations, and unresolved questions.
   - If company context was provided, identify company-specific implications, risks, likely workstreams, and follow-up questions without turning the answer into a full bid/no-bid review unless the user asked for one.
   - State source limits plainly when files are missing, vector-store readiness is partial, attachments are ambiguous, or retrieved chunks do not answer a requested point.

## Output Format
Return the answer in this order:

1. **Source Package Resolved**
   - Identify the resolved record, files, or source package and explain how it was resolved.

2. **Source Coverage**
   - List the files or file groups read, the files searched but not staged, and any missing or ambiguous attachments.
   - State whether the readout is full-text verified through vector-store retrieval or best-effort from record summaries, metadata, and snippets.

3. **Executive Readout**
   - Summarize what the opportunity or source package is asking for and what matters most for capture, proposal, pricing, or compliance.

4. **Key Requirements and Instructions**
   - Cover PWS/SOW/SOO requirements, deliverables, submission instructions, required forms, page limits, mandatory attendance, due dates, question deadlines, and special contract requirements.

5. **Evaluation, Pricing, and Compliance Notes**
   - Summarize evaluation factors, pass/fail criteria, pricing instructions, set-aside or eligibility constraints, cybersecurity requirements, clearance/facility requirements, and other hard gates.

6. **Amendment and Q&A Impacts**
   - Identify changes only when retrieved source evidence shows a change.
   - If no amendment or Q&A evidence was retrieved, say so instead of assuming there are none.

7. **Capture and Proposal Implications**
   - Provide practical implications for capture, proposal management, technical writers, pricing, contracts, and leadership.

8. **Open Questions and Next Actions**
   - List missing-source risks, unclear instructions, questions for the customer or contracting office, and owner-ready next steps.

9. **Confidence and Source Limits**
   - State confidence and explain what evidence would raise or lower it.

## Citation Rules
- Only cite sources retrieved in the current workflow.
- Never fabricate citations, URLs, IDs, dates, file names, or quote spans.
- Use exactly the citation format required by the host application.
- Attach citations to specific claims, especially deadlines, mandatory rules, evaluation factors, pricing instructions, eligibility constraints, and risks.
- Quote only short source language where exact wording affects compliance or interpretation.

## Grounding Rules
- Base claims only on provided context or GovTribe MCP tool outputs.
- If sources conflict, state the conflict explicitly and attribute each side.
- If the context is insufficient or irrelevant, narrow the answer or state that the package review is partial.
- If a statement is an inference rather than a directly supported fact, label it as an inference.

# Solicitation Intelligence and Compliance

## User Input
- **Target solicitation:** [GovTribe opportunity link, solicitation number, or RFI/RFQ/RFP title plus agency]
- **Company context:** [Optional offeror, capability, or pursuit context]

## Goal
Use GovTribe MCP tools to produce a source-backed readout of a solicitation, RFI, RFQ, RFP, amendment, attachment package, or related notice.
Identify scope, deadlines, submission rules, eligibility constraints, evaluation factors, required forms or attachments, compliance risks, and unanswered questions.
Return a copyable markdown briefing, not a DOCX, XLSX, slide deck, workbook, or uploaded file.

## Required Input
The user must provide enough information to resolve one solicitation or source package.

Accept any of the following:
- GovTribe opportunity or government-file link
- Solicitation number, notice ID, RFI/RFQ/RFP title, or amendment identifier
- Opportunity title plus agency, buyer, jurisdiction, or other disambiguating detail
- File-package context supplied by the host client

Input rules:
- If the input resolves cleanly to one target, proceed immediately.
- If several notices or amendments match, identify the likely candidates and ask for the minimum detail needed to choose one.
- Do not guess dates, mandatory requirements, evaluation factors, or submission rules.
- Treat missing files, inaccessible attachments, and ambiguous amendments as explicit risks.

## Workflow

### Steps
1. Call `Documentation` once with `collections=["govtribe-for-agents"]`, `article_names=["Choose a search mode and write queries", "Manage search context", "Date filtering", "Filter by related records and hierarchies", "Vector-store content retrieval", "Troubleshoot search results"]`, and `max_tokens=12000`.
   - Treat the returned guide articles as binding for search behavior, exact lookup, file retrieval, vector-store retrieval, search-context management, and troubleshooting.
   - Use each selected tool schema as the source of truth for exact arguments, fields, filters, relationship fields, sorts, and response shapes.
   - If the connected MCP client does not expose a named tool, use the closest available GovTribe record, file, or vector-search tool the client provides. If no equivalent tool is available, state that limitation instead of pretending the step was completed.

2. Resolve the target solicitation.
   - Use `Search_GovTribe` first when the record type is unclear or the user provides a GovTribe URL that could point to a notice, file, award, IDV, vehicle, or state/local record.
   - Use `Search_Federal_Contract_Opportunities` for federal opportunities, solicitations, RFIs, RFQs, RFPs, sources sought notices, presolicitations, amendments, and notice IDs.
   - Use `Search_State_And_Local_Contract_Opportunities` for state or local procurement notices.
   - Favor exact quoted lookup for solicitation numbers, notice IDs, titles, and file names.
   - Request fields that support scope, dates, buyer, set-aside, NAICS/PSC or category, place of performance, points of contact, descriptions, summary, related files, and related awards or vehicles when available.

3. Pull source files and snippets.
   - Use `Search_Government_Files` for files tied to the resolved target or parent records.
   - If the resolved record already includes attached `government_files`, use those file IDs or names to narrow the file search.
   - Prioritize solicitation documents, amendments, Q&A, attachments, PWS/SOW/SOO, Section L, Section M, pricing instructions, clauses, forms, and exhibits.
   - If snippets are not enough for a requested fact or compliance conclusion, use `Add_To_Vector_Store`, then `Search_Vector_Store`.
   - If file text, snippets, vector-store upload, or vector-store search are unavailable or unauthorized, continue only with retrieved record summaries and file metadata. Say clearly that clause-level requirements were not directly verified.
   - If a host client does not expose file upload, document creation, or code execution tools, keep working with GovTribe MCP snippets and vector-store search results only.

4. Extract the solicitation readout.
   - Separate confirmed facts from assumptions and inferences.
   - Capture scope, buyer, due date, question deadline, site visit or conference rules, submission method, page limits, volume structure, required forms, pricing requirements, eligibility, set-aside, vehicle or ordering path, and evaluation factors.
   - Call out amendment impacts only when the source evidence shows a change.
   - If company context was provided, identify company-specific fit or compliance risks without turning the output into a full bid/no-bid review.

5. Perform a final source and risk pass.
   - Confirm every deadline, mandatory instruction, evaluation factor, and pass/fail requirement has a supporting source.
   - Mark any item as unresolved when the available evidence does not support a direct answer.
   - Do not infer missing clauses or mandatory requirements from attachment names, record summaries, or similar solicitations.
   - Do not promise to create or attach a workbook, DOCX, XLSX, slide deck, or other artifact.

## Output Format
Return the answer in this order:

1. **Solicitation Readout**
   - Identify the resolved target and explain how it was resolved.

2. **Key Facts**
   - Use a 2-column markdown table for buyer, title, solicitation number, notice type, due date, question deadline, site visit or conference rules, set-aside, NAICS/PSC or category, place of performance, and source-package status.

3. **Scope and Requirement Summary**
   - Summarize the work in plain language.
   - Quote only short source language where exact wording changes compliance or interpretation.

4. **Submission and Compliance Rules**
   - Use a copyable markdown table.
   - Recommended columns: `Requirement`, `Source`, `Required Action`, `Risk If Missed`, `Status`.

5. **Evaluation Factors**
   - Use a compact markdown table when factors or subfactors are available.
   - Include pass/fail factors separately from scored or adjectival factors.

6. **Compliance Risks and Open Questions**
   - List missing files, unclear amendments, hard deadlines, mandatory attendance, eligibility gaps, unusual formats, pricing constraints, and questions the team should resolve.

7. **Recommended Next Actions**
   - Provide practical next steps for capture, proposal, pricing, contracts, or BD owners.

8. **Overall Confidence**
   - State confidence and explain what evidence would raise or lower it.

## Citation Rules
- Only cite sources retrieved in the current workflow.
- Never fabricate citations, URLs, IDs, dates, or quote spans.
- Use exactly the citation format required by the host application.
- Attach citations to the specific claims they support, especially deadlines, mandatory rules, evaluation factors, and risks.

## Grounding Rules
- Base claims only on provided context or GovTribe MCP tool outputs.
- If sources conflict, state the conflict explicitly and attribute each side.
- If the context is insufficient or irrelevant, narrow the answer or state that the goal cannot be fully completed from the available evidence.
- If a statement is an inference rather than a directly supported fact, label it as an inference.

# Proposal Compliance Checklist

## User Input
- **Target solicitation:** [GovTribe opportunity link, solicitation number, or source package]
- **Compliance focus:** [Optional checklist focus such as submission, eligibility, pricing, or Section L/M]
- **Company context:** [Optional offeror, certification, vehicle, or team context]

## Goal
Use GovTribe MCP tools to build a source-backed proposal compliance checklist or matrix from a resolved solicitation, notice, amendment, or file package.
The output must be a copyable markdown table or CSV-ready table that a proposal manager can paste into another tool.
Do not create, upload, or promise an XLSX workbook, DOCX document, slide deck, or generated file artifact.

## Required Input
The user must provide a target solicitation, GovTribe link, file package, or enough context to resolve one source package.

Optional input may include:
- A checklist focus such as submission instructions, Section L, Section M, pricing, forms, eligibility, attachments, or pass/fail requirements
- Offeror, team, certification, vehicle-access, or capability context
- Desired table columns, owner/status conventions, or review-gate language

Input rules:
- If the target is not resolvable, ask for the minimum detail needed to proceed.
- If source coverage is incomplete, still produce a scoped checklist and label missing-source risk clearly.
- Do not invent owners, statuses, page counts, deadlines, or requirement IDs unless the user asks for placeholders.

## Workflow

### Steps
1. Call `Documentation` once with `collections=["govtribe-for-agents"]`, `article_names=["Choose a search mode and write queries", "Manage search context", "Filter by related records and hierarchies", "Vector-store content retrieval", "Troubleshoot search results"]`, and `max_tokens=12000`.
   - Treat the returned guide articles as binding for exact lookup, related-record filtering, file retrieval, vector-store retrieval, and troubleshooting.
   - Use each selected tool schema as the source of truth for exact arguments, fields, filters, relationship fields, sorts, and response shapes.
   - If the connected MCP client does not expose a named tool, use the closest available GovTribe record, file, or vector-search tool the client provides. If no equivalent tool is available, state that limitation in the checklist scope.

2. Resolve the target and source package.
   - Use `Search_GovTribe` first when the record type is unclear.
   - Use `Search_Federal_Contract_Opportunities` or `Search_State_And_Local_Contract_Opportunities` for solicitations, RFIs, RFQs, RFPs, sources sought notices, and related opportunity records.
   - Use exact quoted identifiers for solicitation numbers, notice IDs, amendment names, file names, and titles.
   - Request enough fields to support due dates, buyer context, set-aside or eligibility, descriptions, files, related awards or vehicles, points of contact, and source URLs.

3. Retrieve the files that drive compliance.
   - Use `Search_Government_Files` for solicitation files, amendments, Q&A, instructions, evaluation factors, PWS/SOW/SOO, attachments, forms, exhibits, pricing sheets, and clauses.
   - If the resolved opportunity or notice includes attached `government_files`, use those file IDs or names to narrow the file search before broader text queries.
   - Use `Add_To_Vector_Store`, then `Search_Vector_Store`, only when snippets are not enough to extract checklist rows accurately.
   - If file text, snippets, vector-store upload, or vector-store search are unavailable or unauthorized, produce a best-effort checklist from retrieved record summaries and file metadata only, then mark clause-level rows as `Not directly verified`.
   - Track which source each checklist row came from.

4. Extract discrete compliance items.
   - Prioritize mandatory submission rules, deadlines, format rules, volume rules, page limits, representations, certifications, pricing instructions, attachments, deliverables, pass/fail criteria, evaluation factors, and eligibility constraints.
   - Keep source wording short and only where exact language matters.
   - Label derived checklist rows as `Inferred from source` only when the requirement is not stated as a discrete item but follows directly from source text.

5. Build the copyable matrix.
   - Use a markdown table that is also CSV-ready.
   - Include clear status values such as `Open`, `Met`, `Risk`, `Not Applicable`, or `Unknown` when useful.
   - Use `Not directly verified` for items that appear likely from record summaries, file names, or user context but were not confirmed in retrieved source text.
   - If company context was provided, identify offeror-specific pass/fail risks and evidence gaps.

## Output Format
Return the answer in this order:

1. **Checklist Scope**
   - Identify the resolved target, source coverage, and any known missing files.
   - State whether the checklist is source-text verified or best-effort from record summaries and file metadata.

2. **Compliance Checklist**
   - Use a required copyable markdown table.
   - Recommended columns: `ID`, `Requirement`, `Source`, `Due / Applies To`, `Required Response`, `Owner`, `Status`, `Risk`.
   - Keep table cells concise enough to paste into spreadsheets or proposal tools.

3. **Pass / Fail and Hard-Gate Risks**
   - List mandatory attendance, submission method, eligibility, set-aside, vehicle access, late-submission, certification, and format risks.

4. **Evaluation and Scoring Crosswalk**
   - Include only when evaluation factors are available.
   - Recommended columns: `Factor`, `What Evaluators Want`, `Proposal Response Needed`, `Source`, `Risk`.

5. **Open Questions**
   - List source gaps, ambiguous amendment changes, missing attachments, unclear response formats, or company-context unknowns.

6. **Next Proposal Actions**
   - Provide owner-ready actions the team can take next.

## Citation Rules
- Only cite sources retrieved in the current workflow.
- Never fabricate citations, URLs, IDs, dates, or quote spans.
- Use exactly the citation format required by the host application.
- Attach citations to individual checklist rows, not only to the table heading.

## Grounding Rules
- Base claims only on provided context or GovTribe MCP tool outputs.
- If sources conflict, state the conflict explicitly and attribute each side.
- If the context is insufficient or irrelevant, narrow the answer or state that the checklist is partial.
- If a statement is an inference rather than a directly supported fact, label it as an inference.

# Annotated Proposal Outline Starter

## User Input
- **Target solicitation:** [GovTribe opportunity link, solicitation number, or source package]
- **Company context:** [Optional offeror, solution, win-theme, or past-performance context]
- **Outline focus:** [Optional volume, response type, or writer focus]

## Goal
Use GovTribe MCP tools to create a source-backed, writer-facing markdown outline starter for a solicitation, RFI, RFQ, RFP, amendment, or source package.
Map outline sections to requirements, evaluation factors, source evidence, likely proof points, compliance notes, and unresolved capture inputs.
Return a markdown outline starter only; do not create, upload, or promise a DOCX, workbook, slide deck, or generated file artifact.

## Required Input
The user must provide a target solicitation, GovTribe link, file package, or enough context to resolve one source package.

Optional input may include:
- Company, solution, win-theme, past-performance, teammate, or product context
- Desired volume or response focus, such as technical, management, past performance, oral presentation, RFI response, or executive summary
- Known page limits, format rules, or proposal strategy constraints

Input rules:
- If the target cannot be resolved, ask for the minimum detail needed to proceed.
- Do not draft final proposal prose unless the user asks separately; this workflow creates an outline starter.
- Keep compliance requirements separate from writing guidance.

## Workflow

### Steps
1. Call `Documentation` once with `collections=["govtribe-for-agents"]`, `article_names=["Choose a search mode and write queries", "Manage search context", "Filter by related records and hierarchies", "Vector-store content retrieval", "Troubleshoot search results"]`, and `max_tokens=12000`.
   - Treat the returned guide articles as binding for exact lookup, file retrieval, vector-store retrieval, and troubleshooting.
   - Use each selected tool schema as the source of truth for exact arguments, fields, filters, relationship fields, sorts, and response shapes.
   - If the connected MCP client does not expose a named tool, use the closest available GovTribe record, file, or vector-search tool the client provides. If no equivalent tool is available, state that limitation in the outline scope.

2. Resolve the target solicitation and source package.
   - Use `Search_GovTribe` when the record type is unclear.
   - Use `Search_Federal_Contract_Opportunities` or `Search_State_And_Local_Contract_Opportunities` for opportunity records.
   - Use exact quoted lookup for solicitation numbers, titles, notice IDs, amendment names, and file names.
   - Request fields that support scope, due dates, descriptions, buyer context, files, set-aside, vehicle or ordering path, and related records.

3. Retrieve outline-driving source evidence.
   - Use `Search_Government_Files` for source files, instructions, evaluation criteria, PWS/SOW/SOO, Q&A, attachments, forms, exhibits, and amendments.
   - If the resolved opportunity or notice includes attached `government_files`, use those file IDs or names to narrow the file search before broader text queries.
   - Use `Add_To_Vector_Store`, then `Search_Vector_Store`, only when snippets are not enough to map outline sections to requirements.
   - If file text, snippets, vector-store upload, or vector-store search are unavailable or unauthorized, create a partial outline starter from retrieved record summaries and file metadata only, and label every section that is not source-text verified.
   - Preserve source references for each major outline section.

4. Identify outline structure and evidence needs.
   - Extract required volumes, sections, factors, subfactors, page limits, submission instructions, evaluation priorities, work requirements, deliverables, certifications, and required attachments.
   - Map each outline section to source requirements and likely evaluator concerns.
   - If company context is provided, add candidate win themes, past-performance hooks, solution proof points, and gaps as clearly labeled inputs.
   - If company context is not provided, use neutral placeholders instead of invented claims.

5. Build the annotated starter.
   - Use markdown headings and copyable tables.
   - Make it useful to writers, reviewers, and proposal managers without assuming a document-generation skill exists.
   - Keep it as an outline starter, not draft proposal prose.
   - For each major section, state whether the evidence basis is opportunity summary, file metadata, extracted file text, user-provided context, or placeholder.
   - Label every unsupported idea as a placeholder, assumption, or open capture input.

## Output Format
Return the answer in this order:

1. **Outline Scope**
   - Identify the resolved target, source coverage, and outline focus.

2. **Compliance-to-Outline Map**
   - Use a markdown table.
   - Recommended columns: `Source Requirement`, `Evaluation / Instruction`, `Outline Section`, `Writer Action`, `Risk`.

3. **Annotated Outline Starter**
   - Use nested markdown headings.
   - For each section include:
     - `Purpose`
     - `Source Requirements`
     - `Suggested Content`
     - `Evidence / Proof Points Needed`
     - `Compliance Notes`
     - `Open Questions`

4. **Win Theme and Proof-Point Inputs**
   - Include only source-backed or user-provided themes.
   - Mark placeholders clearly.

5. **Writer Risks and Review Gates**
   - List compliance, evidence, page-limit, evaluation, and unanswered-source risks.

6. **Next Actions**
   - Provide practical actions for proposal manager, volume lead, capture, pricing, contracts, and SMEs.

## Citation Rules
- Only cite sources retrieved in the current workflow.
- Never fabricate citations, URLs, IDs, dates, or quote spans.
- Use exactly the citation format required by the host application.
- Attach citations to outline sections, compliance rows, and source requirements they support.

## Grounding Rules
- Base claims only on provided context or GovTribe MCP tool outputs.
- If sources conflict, state the conflict explicitly and attribute each side.
- If the context is insufficient or irrelevant, narrow the outline or state that it is a partial starter.
- If a statement is an inference rather than a directly supported fact, label it as an inference.