@agent-blueprint/free-blueprints 1.0.0

package/dist/blueprints/rfx-procurement/files/evaluation-criteria.d.ts

@@ -0,0 +1 @@
+export declare const content = "# Evaluation Criteria\n\nSpecific metrics, targets, and measurement methodologies for validating the RFx Procurement Automation system. Use these to determine whether the system is performing acceptably and to identify areas for improvement.\n\n---\n\n## 1. Requirements Extraction Accuracy\n\n**Target:** > 95% recall, > 90% precision\n\n**What it measures:** The Requirements Analyzer's ability to identify all real requirements in an RFx document (recall) without flagging non-requirements as requirements (precision).\n\n**Measurement methodology:**\n\n1. Select 10 representative RFx documents spanning different types (RFP, RFQ, RFI), industries, and complexity levels.\n2. Have two human annotators independently identify all requirements in each document. Resolve disagreements to produce a gold-standard annotation set.\n3. Run each document through the Requirements Analyzer.\n4. Calculate recall: (requirements correctly extracted / total requirements in gold standard) x 100.\n5. Calculate precision: (requirements correctly extracted / total items the analyzer identified as requirements) x 100.\n6. Report both metrics per document and as an aggregate across the test set.\n\n**Frequency:** Measured during Phase 1 pilot, then monthly during production operation.\n\n---\n\n## 2. Requirements Categorization Accuracy\n\n**Target:** > 90% accuracy\n\n**What it measures:** Whether the Requirements Analyzer correctly classifies requirements as mandatory, scored, or informational.\n\n**Measurement methodology:**\n\n1. Using the same gold-standard test set from the extraction accuracy measurement, include human-annotated categories for each requirement.\n2. Compare the analyzer's categorization against human annotation.\n3. Calculate accuracy: (correctly categorized / total requirements) x 100.\n4. Break down errors by type: mandatory misclassified as scored (high severity), scored misclassified as informational (medium severity), informational misclassified as mandatory (low severity, conservative error).\n\n**Frequency:** Measured during Phase 1 pilot, then monthly.\n\n---\n\n## 3. Content Match Relevance Score\n\n**Target:** > 80% average relevance for top match per requirement\n\n**What it measures:** The Content Library Matcher's ability to find content that genuinely addresses each requirement.\n\n**Measurement methodology:**\n\n1. Select 50 requirements across different categories and complexity levels.\n2. For each requirement, have a human SME review the top 3 content matches and assign a relevance score (0-100) based on: does this content substantively address the requirement?\n3. Compare human relevance scores against the automated relevance scores.\n4. Calculate the average automated relevance score for the top match across all 50 requirements.\n5. Calculate correlation between human and automated scores to validate the scoring model.\n\n**Frequency:** After Content Library Matcher deployment, then quarterly.\n\n---\n\n## 4. Response Completeness\n\n**Target:** 100% of mandatory requirements addressed\n\n**What it measures:** Whether the final draft response includes a substantive response for every mandatory requirement.\n\n**Measurement methodology:**\n\n1. For each processed RFx, extract the list of mandatory requirements from the Requirements Analyzer output.\n2. Map each mandatory requirement to the response sections that address it (using the Compliance Validator output).\n3. Have a human reviewer verify the mapping for accuracy.\n4. Calculate: (mandatory requirements with a substantive response / total mandatory requirements) x 100.\n5. Any score below 100% is a failure. Investigate and remediate each gap.\n\n**Frequency:** Every RFx processed. This is a continuous metric, not a periodic measurement.\n\n---\n\n## 5. Processing Time Reduction\n\n**Target:** > 50% reduction vs. manual baseline\n\n**What it measures:** The end-to-end time savings from automated processing compared to the manual process.\n\n**Measurement methodology:**\n\n1. Establish a manual baseline: time the current manual process for 5 representative RFx documents from intake to draft-ready. Include all activities: document reading, requirements extraction, content searching, response drafting, and internal review.\n2. Process the same (or equivalent) documents through the automated system. Measure wall-clock time from document intake to draft-ready (excluding human approval gate wait time).\n3. Calculate: ((manual_time - automated_time) / manual_time) x 100.\n4. Report per-stage breakdowns (requirements extraction time, content matching time, response composition time, compliance validation time) to identify bottlenecks.\n\n**Frequency:** Measured during Phase 1 pilot (for extraction only), then after full deployment for end-to-end processing.\n\n---\n\n## 6. Compliance Check Accuracy\n\n**Target:** > 98% accuracy\n\n**What it measures:** The Compliance Validator's ability to correctly identify compliance issues and correctly pass compliant sections.\n\n**Measurement methodology:**\n\n1. Select 5 completed RFx responses with known compliance profiles (some fully compliant, some with deliberate issues).\n2. Run the Compliance Validator on each.\n3. Have a human compliance reviewer independently assess the same responses.\n4. Calculate accuracy: (correct compliance assessments / total assessments) x 100.\n5. Separately track false negatives (missed compliance issues, the dangerous error) and false positives (flagged non-issues, the annoying error). False negative rate must be < 1%.\n\n**Frequency:** After Compliance Validator deployment, then monthly.\n\n---\n\n## 7. Stakeholder Satisfaction\n\n**Target:** > 4.0 / 5.0\n\n**What it measures:** Whether the humans working with the system (proposal managers, SMEs, leadership) find it useful, trustworthy, and efficient.\n\n**Measurement methodology:**\n\n1. After each RFx is processed (or after a batch of RFx in high-volume periods), send a short survey to stakeholders who interacted with the system.\n2. Survey questions (1-5 scale):\n   - \"The system accurately extracted the RFx requirements.\"\n   - \"The matched content was relevant and useful.\"\n   - \"The draft response was a good starting point that reduced my effort.\"\n   - \"I trust the system's compliance checks.\"\n   - \"Overall, the system saved me time on this RFx.\"\n3. Calculate the average across all questions and all respondents.\n4. Track trends over time. A declining score indicates a problem even if it remains above the target.\n\n**Frequency:** Per RFx or monthly (whichever is practical given volume).\n\n---\n\n## 8. Content Reuse Rate\n\n**Target:** > 60% of response content sourced from existing knowledge base\n\n**What it measures:** The health of the organizational knowledge base and the effectiveness of the Content Library Matcher.\n\n**Measurement methodology:**\n\n1. For each completed response, calculate the percentage of content that was sourced from the knowledge base (reused) vs. generated new by the Response Composer.\n2. Track this metric per RFx and as a rolling average.\n3. A declining reuse rate may indicate: the knowledge base is becoming stale, new types of RFx are being received that the library does not cover, or the Content Library Matcher's relevance scoring needs recalibration.\n\n**Frequency:** Every RFx processed. Review trends monthly.\n\n---\n\n## Summary Table\n\n| # | Metric | Target | Phase | Frequency |\n|---|--------|--------|-------|-----------|\n| 1 | Requirements extraction accuracy | > 95% recall, > 90% precision | 1 | Monthly |\n| 2 | Requirements categorization accuracy | > 90% | 1 | Monthly |\n| 3 | Content match relevance score | > 80% average | 2 | Quarterly |\n| 4 | Response completeness (mandatory) | 100% | 2 | Every RFx |\n| 5 | Processing time reduction | > 50% vs. manual | 1+2 | Per phase |\n| 6 | Compliance check accuracy | > 98% | 2 | Monthly |\n| 7 | Stakeholder satisfaction | > 4.0 / 5.0 | 1+2 | Monthly |\n| 8 | Content reuse rate | > 60% | 2 | Every RFx |\n";

package/dist/blueprints/rfx-procurement/files/evaluation-criteria.js

@@ -0,0 +1,165 @@
+export const content = `# Evaluation Criteria
+
+Specific metrics, targets, and measurement methodologies for validating the RFx Procurement Automation system. Use these to determine whether the system is performing acceptably and to identify areas for improvement.
+
+---
+
+## 1. Requirements Extraction Accuracy
+
+**Target:** > 95% recall, > 90% precision
+
+**What it measures:** The Requirements Analyzer's ability to identify all real requirements in an RFx document (recall) without flagging non-requirements as requirements (precision).
+
+**Measurement methodology:**
+
+1. Select 10 representative RFx documents spanning different types (RFP, RFQ, RFI), industries, and complexity levels.
+2. Have two human annotators independently identify all requirements in each document. Resolve disagreements to produce a gold-standard annotation set.
+3. Run each document through the Requirements Analyzer.
+4. Calculate recall: (requirements correctly extracted / total requirements in gold standard) x 100.
+5. Calculate precision: (requirements correctly extracted / total items the analyzer identified as requirements) x 100.
+6. Report both metrics per document and as an aggregate across the test set.
+
+**Frequency:** Measured during Phase 1 pilot, then monthly during production operation.
+
+---
+
+## 2. Requirements Categorization Accuracy
+
+**Target:** > 90% accuracy
+
+**What it measures:** Whether the Requirements Analyzer correctly classifies requirements as mandatory, scored, or informational.
+
+**Measurement methodology:**
+
+1. Using the same gold-standard test set from the extraction accuracy measurement, include human-annotated categories for each requirement.
+2. Compare the analyzer's categorization against human annotation.
+3. Calculate accuracy: (correctly categorized / total requirements) x 100.
+4. Break down errors by type: mandatory misclassified as scored (high severity), scored misclassified as informational (medium severity), informational misclassified as mandatory (low severity, conservative error).
+
+**Frequency:** Measured during Phase 1 pilot, then monthly.
+
+---
+
+## 3. Content Match Relevance Score
+
+**Target:** > 80% average relevance for top match per requirement
+
+**What it measures:** The Content Library Matcher's ability to find content that genuinely addresses each requirement.
+
+**Measurement methodology:**
+
+1. Select 50 requirements across different categories and complexity levels.
+2. For each requirement, have a human SME review the top 3 content matches and assign a relevance score (0-100) based on: does this content substantively address the requirement?
+3. Compare human relevance scores against the automated relevance scores.
+4. Calculate the average automated relevance score for the top match across all 50 requirements.
+5. Calculate correlation between human and automated scores to validate the scoring model.
+
+**Frequency:** After Content Library Matcher deployment, then quarterly.
+
+---
+
+## 4. Response Completeness
+
+**Target:** 100% of mandatory requirements addressed
+
+**What it measures:** Whether the final draft response includes a substantive response for every mandatory requirement.
+
+**Measurement methodology:**
+
+1. For each processed RFx, extract the list of mandatory requirements from the Requirements Analyzer output.
+2. Map each mandatory requirement to the response sections that address it (using the Compliance Validator output).
+3. Have a human reviewer verify the mapping for accuracy.
+4. Calculate: (mandatory requirements with a substantive response / total mandatory requirements) x 100.
+5. Any score below 100% is a failure. Investigate and remediate each gap.
+
+**Frequency:** Every RFx processed. This is a continuous metric, not a periodic measurement.
+
+---
+
+## 5. Processing Time Reduction
+
+**Target:** > 50% reduction vs. manual baseline
+
+**What it measures:** The end-to-end time savings from automated processing compared to the manual process.
+
+**Measurement methodology:**
+
+1. Establish a manual baseline: time the current manual process for 5 representative RFx documents from intake to draft-ready. Include all activities: document reading, requirements extraction, content searching, response drafting, and internal review.
+2. Process the same (or equivalent) documents through the automated system. Measure wall-clock time from document intake to draft-ready (excluding human approval gate wait time).
+3. Calculate: ((manual_time - automated_time) / manual_time) x 100.
+4. Report per-stage breakdowns (requirements extraction time, content matching time, response composition time, compliance validation time) to identify bottlenecks.
+
+**Frequency:** Measured during Phase 1 pilot (for extraction only), then after full deployment for end-to-end processing.
+
+---
+
+## 6. Compliance Check Accuracy
+
+**Target:** > 98% accuracy
+
+**What it measures:** The Compliance Validator's ability to correctly identify compliance issues and correctly pass compliant sections.
+
+**Measurement methodology:**
+
+1. Select 5 completed RFx responses with known compliance profiles (some fully compliant, some with deliberate issues).
+2. Run the Compliance Validator on each.
+3. Have a human compliance reviewer independently assess the same responses.
+4. Calculate accuracy: (correct compliance assessments / total assessments) x 100.
+5. Separately track false negatives (missed compliance issues, the dangerous error) and false positives (flagged non-issues, the annoying error). False negative rate must be < 1%.
+
+**Frequency:** After Compliance Validator deployment, then monthly.
+
+---
+
+## 7. Stakeholder Satisfaction
+
+**Target:** > 4.0 / 5.0
+
+**What it measures:** Whether the humans working with the system (proposal managers, SMEs, leadership) find it useful, trustworthy, and efficient.
+
+**Measurement methodology:**
+
+1. After each RFx is processed (or after a batch of RFx in high-volume periods), send a short survey to stakeholders who interacted with the system.
+2. Survey questions (1-5 scale):
+   - "The system accurately extracted the RFx requirements."
+   - "The matched content was relevant and useful."
+   - "The draft response was a good starting point that reduced my effort."
+   - "I trust the system's compliance checks."
+   - "Overall, the system saved me time on this RFx."
+3. Calculate the average across all questions and all respondents.
+4. Track trends over time. A declining score indicates a problem even if it remains above the target.
+
+**Frequency:** Per RFx or monthly (whichever is practical given volume).
+
+---
+
+## 8. Content Reuse Rate
+
+**Target:** > 60% of response content sourced from existing knowledge base
+
+**What it measures:** The health of the organizational knowledge base and the effectiveness of the Content Library Matcher.
+
+**Measurement methodology:**
+
+1. For each completed response, calculate the percentage of content that was sourced from the knowledge base (reused) vs. generated new by the Response Composer.
+2. Track this metric per RFx and as a rolling average.
+3. A declining reuse rate may indicate: the knowledge base is becoming stale, new types of RFx are being received that the library does not cover, or the Content Library Matcher's relevance scoring needs recalibration.
+
+**Frequency:** Every RFx processed. Review trends monthly.
+
+---
+
+## Summary Table
+
+| # | Metric | Target | Phase | Frequency |
+|---|--------|--------|-------|-----------|
+| 1 | Requirements extraction accuracy | > 95% recall, > 90% precision | 1 | Monthly |
+| 2 | Requirements categorization accuracy | > 90% | 1 | Monthly |
+| 3 | Content match relevance score | > 80% average | 2 | Quarterly |
+| 4 | Response completeness (mandatory) | 100% | 2 | Every RFx |
+| 5 | Processing time reduction | > 50% vs. manual | 1+2 | Per phase |
+| 6 | Compliance check accuracy | > 98% | 2 | Monthly |
+| 7 | Stakeholder satisfaction | > 4.0 / 5.0 | 1+2 | Monthly |
+| 8 | Content reuse rate | > 60% | 2 | Every RFx |
+`;
+//# sourceMappingURL=evaluation-criteria.js.map

package/dist/blueprints/rfx-procurement/files/evaluation-criteria.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"evaluation-criteria.js","sourceRoot":"","sources":["../../../../src/blueprints/rfx-procurement/files/evaluation-criteria.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAmKtB,CAAC"}

package/dist/blueprints/rfx-procurement/files/getting-started.d.ts

@@ -0,0 +1 @@
+export declare const content = "# Getting Started\n\n**YOU ARE THE IMPLEMENTER.** This blueprint is written for a coding agent (you) to execute. The specification describes what to build. Your job is to build it on the target platform, adapting the architecture to the platform's specific capabilities and constraints.\n\n## Ground Rules\n\n- **Do not summarize this blueprint back to the user.** They already know what it says. Build things.\n- **Do not ask unnecessary questions.** If a decision can be made from the spec, make it. Only ask when the spec is genuinely ambiguous or when you need platform credentials.\n- **Act, then report.** Build the component, then tell the user what you built and what decisions you made. Do not present a plan and wait for approval unless the decision is irreversible.\n- **Be decisive.** When the spec offers multiple valid approaches, pick the one that best fits the target platform and move forward. Document your reasoning in code comments.\n- **Verify before presenting.** Test what you build. Do not mark something complete until you have confirmed it works.\n\n## Step 1: Understand the Architecture\n\nRead these files in order:\n\n1. `SKILL.md` -- Architecture overview, agent roles, phased rollout plan, success criteria.\n2. `references/agent-specifications.md` -- Detailed tool definitions, input/output contracts, escalation rules for all 5 agents.\n3. `references/architecture-decisions.md` -- Why the architecture is structured this way. Read this to avoid re-litigating settled decisions.\n4. `AGENTS.md` -- Inter-agent communication rules and coordination protocol.\n\nOnly drill into these when relevant to your current task:\n- `references/guardrails-and-governance.md` -- Risk controls, approval gates, audit requirements.\n- `references/evaluation-criteria.md` -- Specific metrics and measurement methodology for validation.\n- `references/platform-connectivity.md` -- Integration patterns for document intake, knowledge base, notifications.\n- `references/business-context.md` -- Business problem context and target outcomes.\n\n## Step 2: Connect to the Target Platform\n\n### Scenario A: Platform is ready and accessible\n\nYou have credentials and access to the target platform (e.g., an enterprise automation platform, a cloud environment, or a development server). Proceed directly to Step 3.\n\n### Scenario B: Building on a custom stack\n\nNo enterprise platform. You are building agents as standalone services, scripts, or functions. Use the agent specifications as your interface contracts. Choose your own orchestration mechanism (message queue, HTTP APIs, function calls) and implement the tools defined in `references/agent-specifications.md`.\n\n### Scenario C: Unsure about the target\n\nAsk the user one question: \"Where should these agents run?\" Their answer determines your approach. Common options:\n\n- An enterprise automation platform with agent/workflow capabilities\n- A cloud environment (AWS, GCP, Azure) with serverless functions or containers\n- A local development environment for prototyping\n- A custom application backend\n\nOnce you know the target, map each agent's tools to the platform's native capabilities. The tool definitions in `references/agent-specifications.md` are platform-agnostic contracts. Your job is to implement them using whatever the platform provides.\n\n## Step 3: Build and Validate the Pilot\n\n### Phase A: Scaffold the orchestration layer\n\n1. Create the RFx Orchestrator agent with its core routing logic. It needs to accept an RFx document, classify it by type (RFP/RFQ/RFI), and create a tracking record.\n2. Implement the `assign_rfx_task` and `check_completion_status` tools.\n3. Verify: submit a test document and confirm the Orchestrator creates a tracking record and attempts to route it.\n\n### Phase B: Make the pilot real\n\n1. Deploy the Requirements Analyzer with its `parse_rfx_document`, `extract_requirements`, `categorize_requirements`, and `identify_deadlines` tools.\n2. Wire the Orchestrator to send documents to the Requirements Analyzer and receive structured results.\n3. Test against 3-5 real or representative RFx documents. Compare extracted requirements against a human baseline.\n4. Measure: extraction accuracy (recall > 90%), processing time reduction (> 40%), zero missed mandatory requirements.\n\n### Phase C: Expand to the full team\n\nOnly proceed after Phase 1 decision gate criteria are met (see SKILL.md).\n\n1. Deploy Content Library Matcher. Connect to the organizational knowledge base. Test content matching against known requirement-content pairs.\n2. Deploy Response Composer. Wire it to receive matched content and requirement gaps from the Content Library Matcher. Test draft response generation.\n3. Deploy Compliance Validator. Wire it as the final gate before human review. Test against documents with known compliance issues.\n4. Run the full 5-agent pipeline end-to-end on 3-5 real RFx documents.\n\n## Step 4: Validate\n\nTest the system programmatically, not just by inspection.\n\n- Write automated tests for each agent's core tools against known inputs and expected outputs.\n- Run the full pipeline against a test set and measure against the evaluation criteria in `references/evaluation-criteria.md`.\n- Pay special attention to: mandatory requirement coverage (must be 100%), compliance check accuracy (> 98%), and content relevance scoring (> 80% average).\n- Document any metrics that fall below target and the remediation plan.\n\n## Step 5: Track Progress\n\nUpdate `implementation-state.yaml` as you complete each milestone:\n\n- Set each agent's status as you progress: `not_started` \u2192 `in_progress` \u2192 `testing` \u2192 `live`.\n- Record the platform, version, and environment details.\n- Log integration endpoints as they are configured.\n- Note any deviations from the spec and the reasoning behind them.\n\nThis file is your single source of truth for implementation progress. Keep it current.\n\n---\n\nThese free blueprints cover generic processes. For blueprints tailored to your company, your systems, your data, your org structure, and your financials, visit https://app.agentblueprint.ai\n";

package/dist/blueprints/rfx-procurement/files/getting-started.js

@@ -0,0 +1,97 @@
+export const content = `# Getting Started
+
+**YOU ARE THE IMPLEMENTER.** This blueprint is written for a coding agent (you) to execute. The specification describes what to build. Your job is to build it on the target platform, adapting the architecture to the platform's specific capabilities and constraints.
+
+## Ground Rules
+
+- **Do not summarize this blueprint back to the user.** They already know what it says. Build things.
+- **Do not ask unnecessary questions.** If a decision can be made from the spec, make it. Only ask when the spec is genuinely ambiguous or when you need platform credentials.
+- **Act, then report.** Build the component, then tell the user what you built and what decisions you made. Do not present a plan and wait for approval unless the decision is irreversible.
+- **Be decisive.** When the spec offers multiple valid approaches, pick the one that best fits the target platform and move forward. Document your reasoning in code comments.
+- **Verify before presenting.** Test what you build. Do not mark something complete until you have confirmed it works.
+
+## Step 1: Understand the Architecture
+
+Read these files in order:
+
+1. \`SKILL.md\` -- Architecture overview, agent roles, phased rollout plan, success criteria.
+2. \`references/agent-specifications.md\` -- Detailed tool definitions, input/output contracts, escalation rules for all 5 agents.
+3. \`references/architecture-decisions.md\` -- Why the architecture is structured this way. Read this to avoid re-litigating settled decisions.
+4. \`AGENTS.md\` -- Inter-agent communication rules and coordination protocol.
+
+Only drill into these when relevant to your current task:
+- \`references/guardrails-and-governance.md\` -- Risk controls, approval gates, audit requirements.
+- \`references/evaluation-criteria.md\` -- Specific metrics and measurement methodology for validation.
+- \`references/platform-connectivity.md\` -- Integration patterns for document intake, knowledge base, notifications.
+- \`references/business-context.md\` -- Business problem context and target outcomes.
+
+## Step 2: Connect to the Target Platform
+
+### Scenario A: Platform is ready and accessible
+
+You have credentials and access to the target platform (e.g., an enterprise automation platform, a cloud environment, or a development server). Proceed directly to Step 3.
+
+### Scenario B: Building on a custom stack
+
+No enterprise platform. You are building agents as standalone services, scripts, or functions. Use the agent specifications as your interface contracts. Choose your own orchestration mechanism (message queue, HTTP APIs, function calls) and implement the tools defined in \`references/agent-specifications.md\`.
+
+### Scenario C: Unsure about the target
+
+Ask the user one question: "Where should these agents run?" Their answer determines your approach. Common options:
+
+- An enterprise automation platform with agent/workflow capabilities
+- A cloud environment (AWS, GCP, Azure) with serverless functions or containers
+- A local development environment for prototyping
+- A custom application backend
+
+Once you know the target, map each agent's tools to the platform's native capabilities. The tool definitions in \`references/agent-specifications.md\` are platform-agnostic contracts. Your job is to implement them using whatever the platform provides.
+
+## Step 3: Build and Validate the Pilot
+
+### Phase A: Scaffold the orchestration layer
+
+1. Create the RFx Orchestrator agent with its core routing logic. It needs to accept an RFx document, classify it by type (RFP/RFQ/RFI), and create a tracking record.
+2. Implement the \`assign_rfx_task\` and \`check_completion_status\` tools.
+3. Verify: submit a test document and confirm the Orchestrator creates a tracking record and attempts to route it.
+
+### Phase B: Make the pilot real
+
+1. Deploy the Requirements Analyzer with its \`parse_rfx_document\`, \`extract_requirements\`, \`categorize_requirements\`, and \`identify_deadlines\` tools.
+2. Wire the Orchestrator to send documents to the Requirements Analyzer and receive structured results.
+3. Test against 3-5 real or representative RFx documents. Compare extracted requirements against a human baseline.
+4. Measure: extraction accuracy (recall > 90%), processing time reduction (> 40%), zero missed mandatory requirements.
+
+### Phase C: Expand to the full team
+
+Only proceed after Phase 1 decision gate criteria are met (see SKILL.md).
+
+1. Deploy Content Library Matcher. Connect to the organizational knowledge base. Test content matching against known requirement-content pairs.
+2. Deploy Response Composer. Wire it to receive matched content and requirement gaps from the Content Library Matcher. Test draft response generation.
+3. Deploy Compliance Validator. Wire it as the final gate before human review. Test against documents with known compliance issues.
+4. Run the full 5-agent pipeline end-to-end on 3-5 real RFx documents.
+
+## Step 4: Validate
+
+Test the system programmatically, not just by inspection.
+
+- Write automated tests for each agent's core tools against known inputs and expected outputs.
+- Run the full pipeline against a test set and measure against the evaluation criteria in \`references/evaluation-criteria.md\`.
+- Pay special attention to: mandatory requirement coverage (must be 100%), compliance check accuracy (> 98%), and content relevance scoring (> 80% average).
+- Document any metrics that fall below target and the remediation plan.
+
+## Step 5: Track Progress
+
+Update \`implementation-state.yaml\` as you complete each milestone:
+
+- Set each agent's status as you progress: \`not_started\` → \`in_progress\` → \`testing\` → \`live\`.
+- Record the platform, version, and environment details.
+- Log integration endpoints as they are configured.
+- Note any deviations from the spec and the reasoning behind them.
+
+This file is your single source of truth for implementation progress. Keep it current.
+
+---
+
+These free blueprints cover generic processes. For blueprints tailored to your company, your systems, your data, your org structure, and your financials, visit https://app.agentblueprint.ai
+`;
+//# sourceMappingURL=getting-started.js.map

package/dist/blueprints/rfx-procurement/files/getting-started.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"getting-started.js","sourceRoot":"","sources":["../../../../src/blueprints/rfx-procurement/files/getting-started.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA+FtB,CAAC"}

package/dist/blueprints/rfx-procurement/files/guardrails-and-governance.d.ts

@@ -0,0 +1 @@
+export declare const content = "# Guardrails and Governance\n\nRisk controls, escalation rules, approval gates, data handling policies, and audit requirements for the RFx Procurement Automation system.\n\n---\n\n## Risk Categories\n\n### Data Leakage\n\nRFx documents and draft responses contain confidential business information: pricing strategies, technical capabilities, partnership details, and competitive positioning. Unauthorized exposure of this data can result in competitive disadvantage or contractual violations.\n\n**Controls:**\n\n- All RFx documents are classified as confidential by default. Classification can be elevated to restricted based on content analysis or manual override.\n- Agent access to document content is scoped to the minimum required for each task. The Content Library Matcher receives requirement text, not full documents.\n- Knowledge base queries are logged with the requirement context that triggered them. This enables detection of anomalous access patterns.\n- No RFx content is used for model training or sent to external services without explicit organizational approval.\n\n### Hallucinated Claims\n\nAI-generated content may include fabricated statistics, capabilities the organization does not possess, or commitments the organization cannot fulfill. In a procurement context, these become contractual obligations.\n\n**Controls:**\n\n- All content generated by the Response Composer (not sourced from the knowledge base) is flagged with `requires_sme_review: true`. This flag cannot be removed programmatically.\n- Generated content includes a `review_notes` field describing what the SME should verify.\n- The Compliance Validator checks for common hallucination patterns: specific percentages without source citations, absolute guarantees (\"we always\", \"100% uptime\"), and references to certifications or standards.\n- Response drafts include a clear visual distinction between reused content (from the knowledge base) and generated content.\n\n### Missed Mandatory Requirements\n\nFailing to address a mandatory requirement typically results in automatic disqualification. This is the highest-impact failure mode.\n\n**Controls:**\n\n- The Requirements Analyzer categorizes all requirements, with mandatory items receiving special handling.\n- The Compliance Validator explicitly cross-checks every mandatory requirement against the response sections. A \"not_addressed\" status for any mandatory requirement is a blocking flag.\n- The Orchestrator will not proceed to the final submission gate if any mandatory requirement is unaddressed.\n- Deadline tracking includes early warnings at configurable intervals (default: 7 days, 3 days, 1 day before submission deadline).\n\n### Unauthorized Submission\n\nAn automated system submitting a response without proper authorization could create unintended contractual obligations.\n\n**Controls:**\n\n- The system does not submit responses directly. The final output is a draft document delivered to authorized stakeholders.\n- The final submission gate requires explicit human approval before the response can be submitted through any channel.\n- The Orchestrator enforces a configurable list of authorized approvers for each gate type.\n- If the system is later configured to submit directly (e.g., via procurement portal API), the submission action requires a valid approval record with approver identity and timestamp.\n\n---\n\n## Escalation Rules\n\n### When to Escalate to Human\n\n| Condition | Severity | Escalation Target |\n|-----------|----------|-------------------|\n| Worker fails twice on the same task | High | Operations team |\n| Mandatory requirement not addressed after full pipeline | Critical | Proposal manager + SME |\n| Requirements extraction confidence below 0.6 for entire document | High | Proposal manager |\n| More than 20% of requirements have categorization confidence below 0.7 | Medium | Proposal manager |\n| Contradictory mandatory requirements detected | High | Legal/proposal manager |\n| Submission deadline within 48 hours and processing incomplete | Critical | Proposal manager + leadership |\n| More than 30% of response is generated (non-reused) content | Medium | Content library owner + SMEs |\n| Knowledge base connection failure | High | IT operations |\n| Compliance validation finds more than 3 non-responsive sections | High | Proposal manager + relevant SMEs |\n\n### Escalation Protocol\n\n1. The Orchestrator creates an escalation record with: RFx ID, condition triggered, severity, affected requirements/sections, and recommended action.\n2. Notification is sent to the escalation target via the configured notification channel.\n3. Processing pauses for that RFx (other RFx documents continue processing normally).\n4. The escalation record includes a link to the current state of the RFx tracking record so the human reviewer has full context.\n5. Resolution options: resolve and resume, override and proceed, or cancel the RFx processing.\n\n---\n\n## Approval Gates\n\n### Phase 1 Exit Gate\n\n- **Trigger:** Phase 1 pilot metrics are collected and ready for review.\n- **Approver:** Project sponsor or designated decision-maker.\n- **Artifacts for review:** Pilot metrics report (extraction accuracy, processing time reduction, mandatory requirements missed, routing accuracy), sample outputs from pilot RFx documents, known issues and limitations.\n- **Decision options:** Approve (proceed to Phase 2), Conditionally approve (proceed with specified constraints), Reject (iterate on Phase 1).\n\n### Response Review Gate\n\n- **Trigger:** Response Composer has produced a complete draft.\n- **Approver:** Proposal manager and relevant SMEs.\n- **Artifacts for review:** Draft response with generated content highlighted, gap analysis showing which requirements needed new content, content sources for reused material with freshness indicators.\n- **Decision options:** Approve (proceed to compliance validation), Revise (return specific sections to Response Composer with feedback), Reject (escalate or cancel).\n\n### Final Submission Gate\n\n- **Trigger:** Compliance Validator has completed validation and all blocking flags are resolved.\n- **Approver:** Authorized signatory (typically senior leadership or contracts manager).\n- **Artifacts for review:** Compliance report (pass/fail per requirement, formatting compliance), complete response document, any outstanding warnings (non-blocking flags).\n- **Decision options:** Approve for submission, Return for revision, Reject.\n\n---\n\n## Data Handling\n\n### Document Classification\n\n- **Confidential (default):** Standard RFx documents and responses. Accessible to authorized team members and agents.\n- **Restricted:** RFx documents involving sensitive contracts, government/defense, or documents explicitly marked restricted by the issuing organization. Additional access controls and audit logging.\n- **Internal:** Organizational content in the knowledge base. Accessible to agents for matching but not included verbatim in logs.\n\n### Access Controls\n\n- Agents operate with service-level credentials, not individual user credentials.\n- Access to RFx tracking records is scoped by organizational role. Proposal managers see all RFx for their team. SMEs see only RFx where they are assigned as reviewers.\n- Knowledge base access is read-only for all agents. No agent can modify, create, or delete knowledge base content.\n- Approval actions require individual user authentication. Service accounts cannot approve.\n\n### Retention Policies\n\n- RFx tracking records: retained for the duration of the contract lifecycle plus 3 years (configurable).\n- Draft responses: retained until final submission, then archived. Only the final submitted version is retained long-term.\n- Audit logs: retained for 7 years (configurable based on regulatory requirements).\n- Knowledge base usage analytics: retained for 2 years for content management purposes.\n\n---\n\n## Audit Trail\n\n### What Gets Logged\n\nEvery agent action produces an audit log entry with:\n\n- **Timestamp** (ISO-8601, UTC)\n- **Agent name** (which agent performed the action)\n- **Action type** (tool invocation, task assignment, escalation, approval, notification)\n- **RFx ID** (the document being processed)\n- **Task ID** (if applicable)\n- **Input summary** (hash or reference, not full content, to avoid duplicating sensitive data in logs)\n- **Output summary** (status, confidence scores, key metrics)\n- **Duration** (milliseconds)\n- **Error details** (if the action failed)\n\n### Additional Logging for Approval Gates\n\n- Approver identity (authenticated user)\n- Decision (approve, revise, reject)\n- Decision rationale (free text, required for rejections)\n- Artifacts reviewed (references to the specific document versions)\n\n### Log Storage\n\n- Logs are stored separately from operational data to ensure they cannot be modified by agents.\n- Log access is restricted to operations and compliance roles.\n- Logs support structured querying for compliance reporting (e.g., \"show all escalations for RFx documents in the last quarter\").\n";

package/dist/blueprints/rfx-procurement/files/guardrails-and-governance.js

@@ -0,0 +1,159 @@
+export const content = `# Guardrails and Governance
+
+Risk controls, escalation rules, approval gates, data handling policies, and audit requirements for the RFx Procurement Automation system.
+
+---
+
+## Risk Categories
+
+### Data Leakage
+
+RFx documents and draft responses contain confidential business information: pricing strategies, technical capabilities, partnership details, and competitive positioning. Unauthorized exposure of this data can result in competitive disadvantage or contractual violations.
+
+**Controls:**
+
+- All RFx documents are classified as confidential by default. Classification can be elevated to restricted based on content analysis or manual override.
+- Agent access to document content is scoped to the minimum required for each task. The Content Library Matcher receives requirement text, not full documents.
+- Knowledge base queries are logged with the requirement context that triggered them. This enables detection of anomalous access patterns.
+- No RFx content is used for model training or sent to external services without explicit organizational approval.
+
+### Hallucinated Claims
+
+AI-generated content may include fabricated statistics, capabilities the organization does not possess, or commitments the organization cannot fulfill. In a procurement context, these become contractual obligations.
+
+**Controls:**
+
+- All content generated by the Response Composer (not sourced from the knowledge base) is flagged with \`requires_sme_review: true\`. This flag cannot be removed programmatically.
+- Generated content includes a \`review_notes\` field describing what the SME should verify.
+- The Compliance Validator checks for common hallucination patterns: specific percentages without source citations, absolute guarantees ("we always", "100% uptime"), and references to certifications or standards.
+- Response drafts include a clear visual distinction between reused content (from the knowledge base) and generated content.
+
+### Missed Mandatory Requirements
+
+Failing to address a mandatory requirement typically results in automatic disqualification. This is the highest-impact failure mode.
+
+**Controls:**
+
+- The Requirements Analyzer categorizes all requirements, with mandatory items receiving special handling.
+- The Compliance Validator explicitly cross-checks every mandatory requirement against the response sections. A "not_addressed" status for any mandatory requirement is a blocking flag.
+- The Orchestrator will not proceed to the final submission gate if any mandatory requirement is unaddressed.
+- Deadline tracking includes early warnings at configurable intervals (default: 7 days, 3 days, 1 day before submission deadline).
+
+### Unauthorized Submission
+
+An automated system submitting a response without proper authorization could create unintended contractual obligations.
+
+**Controls:**
+
+- The system does not submit responses directly. The final output is a draft document delivered to authorized stakeholders.
+- The final submission gate requires explicit human approval before the response can be submitted through any channel.
+- The Orchestrator enforces a configurable list of authorized approvers for each gate type.
+- If the system is later configured to submit directly (e.g., via procurement portal API), the submission action requires a valid approval record with approver identity and timestamp.
+
+---
+
+## Escalation Rules
+
+### When to Escalate to Human
+
+| Condition | Severity | Escalation Target |
+|-----------|----------|-------------------|
+| Worker fails twice on the same task | High | Operations team |
+| Mandatory requirement not addressed after full pipeline | Critical | Proposal manager + SME |
+| Requirements extraction confidence below 0.6 for entire document | High | Proposal manager |
+| More than 20% of requirements have categorization confidence below 0.7 | Medium | Proposal manager |
+| Contradictory mandatory requirements detected | High | Legal/proposal manager |
+| Submission deadline within 48 hours and processing incomplete | Critical | Proposal manager + leadership |
+| More than 30% of response is generated (non-reused) content | Medium | Content library owner + SMEs |
+| Knowledge base connection failure | High | IT operations |
+| Compliance validation finds more than 3 non-responsive sections | High | Proposal manager + relevant SMEs |
+
+### Escalation Protocol
+
+1. The Orchestrator creates an escalation record with: RFx ID, condition triggered, severity, affected requirements/sections, and recommended action.
+2. Notification is sent to the escalation target via the configured notification channel.
+3. Processing pauses for that RFx (other RFx documents continue processing normally).
+4. The escalation record includes a link to the current state of the RFx tracking record so the human reviewer has full context.
+5. Resolution options: resolve and resume, override and proceed, or cancel the RFx processing.
+
+---
+
+## Approval Gates
+
+### Phase 1 Exit Gate
+
+- **Trigger:** Phase 1 pilot metrics are collected and ready for review.
+- **Approver:** Project sponsor or designated decision-maker.
+- **Artifacts for review:** Pilot metrics report (extraction accuracy, processing time reduction, mandatory requirements missed, routing accuracy), sample outputs from pilot RFx documents, known issues and limitations.
+- **Decision options:** Approve (proceed to Phase 2), Conditionally approve (proceed with specified constraints), Reject (iterate on Phase 1).
+
+### Response Review Gate
+
+- **Trigger:** Response Composer has produced a complete draft.
+- **Approver:** Proposal manager and relevant SMEs.
+- **Artifacts for review:** Draft response with generated content highlighted, gap analysis showing which requirements needed new content, content sources for reused material with freshness indicators.
+- **Decision options:** Approve (proceed to compliance validation), Revise (return specific sections to Response Composer with feedback), Reject (escalate or cancel).
+
+### Final Submission Gate
+
+- **Trigger:** Compliance Validator has completed validation and all blocking flags are resolved.
+- **Approver:** Authorized signatory (typically senior leadership or contracts manager).
+- **Artifacts for review:** Compliance report (pass/fail per requirement, formatting compliance), complete response document, any outstanding warnings (non-blocking flags).
+- **Decision options:** Approve for submission, Return for revision, Reject.
+
+---
+
+## Data Handling
+
+### Document Classification
+
+- **Confidential (default):** Standard RFx documents and responses. Accessible to authorized team members and agents.
+- **Restricted:** RFx documents involving sensitive contracts, government/defense, or documents explicitly marked restricted by the issuing organization. Additional access controls and audit logging.
+- **Internal:** Organizational content in the knowledge base. Accessible to agents for matching but not included verbatim in logs.
+
+### Access Controls
+
+- Agents operate with service-level credentials, not individual user credentials.
+- Access to RFx tracking records is scoped by organizational role. Proposal managers see all RFx for their team. SMEs see only RFx where they are assigned as reviewers.
+- Knowledge base access is read-only for all agents. No agent can modify, create, or delete knowledge base content.
+- Approval actions require individual user authentication. Service accounts cannot approve.
+
+### Retention Policies
+
+- RFx tracking records: retained for the duration of the contract lifecycle plus 3 years (configurable).
+- Draft responses: retained until final submission, then archived. Only the final submitted version is retained long-term.
+- Audit logs: retained for 7 years (configurable based on regulatory requirements).
+- Knowledge base usage analytics: retained for 2 years for content management purposes.
+
+---
+
+## Audit Trail
+
+### What Gets Logged
+
+Every agent action produces an audit log entry with:
+
+- **Timestamp** (ISO-8601, UTC)
+- **Agent name** (which agent performed the action)
+- **Action type** (tool invocation, task assignment, escalation, approval, notification)
+- **RFx ID** (the document being processed)
+- **Task ID** (if applicable)
+- **Input summary** (hash or reference, not full content, to avoid duplicating sensitive data in logs)
+- **Output summary** (status, confidence scores, key metrics)
+- **Duration** (milliseconds)
+- **Error details** (if the action failed)
+
+### Additional Logging for Approval Gates
+
+- Approver identity (authenticated user)
+- Decision (approve, revise, reject)
+- Decision rationale (free text, required for rejections)
+- Artifacts reviewed (references to the specific document versions)
+
+### Log Storage
+
+- Logs are stored separately from operational data to ensure they cannot be modified by agents.
+- Log access is restricted to operations and compliance roles.
+- Logs support structured querying for compliance reporting (e.g., "show all escalations for RFx documents in the last quarter").
+`;
+//# sourceMappingURL=guardrails-and-governance.js.map

package/dist/blueprints/rfx-procurement/files/guardrails-and-governance.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"guardrails-and-governance.js","sourceRoot":"","sources":["../../../../src/blueprints/rfx-procurement/files/guardrails-and-governance.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6JtB,CAAC"}

package/dist/blueprints/rfx-procurement/files/implementation-state.d.ts

@@ -0,0 +1 @@
+export declare const content = "schema_version: \"1.0\"\noverall_status: not_started\n\nplatform:\n  name: TBD\n  version: TBD\n  environment: TBD\n\nphases:\n  phase_1:\n    status: not_started\n    started_at:\n    completed_at:\n    decision_gate_passed: false\n    notes:\n\n  phase_2:\n    status: not_started\n    started_at:\n    completed_at:\n    notes:\n\nagents:\n  - name: RFx Orchestrator\n    role: manager\n    status: not_started\n    phase: 1\n    platform_entity_id:\n    platform_entity_type:\n    tools_implemented: []\n    integration_endpoints: []\n    notes:\n\n  - name: Requirements Analyzer\n    role: worker\n    status: not_started\n    phase: 1\n    platform_entity_id:\n    platform_entity_type:\n    tools_implemented: []\n    integration_endpoints: []\n    notes:\n\n  - name: Content Library Matcher\n    role: worker\n    status: not_started\n    phase: 2\n    platform_entity_id:\n    platform_entity_type:\n    tools_implemented: []\n    integration_endpoints: []\n    notes:\n\n  - name: Response Composer\n    role: worker\n    status: not_started\n    phase: 2\n    platform_entity_id:\n    platform_entity_type:\n    tools_implemented: []\n    integration_endpoints: []\n    notes:\n\n  - name: Compliance Validator\n    role: worker\n    status: not_started\n    phase: 2\n    platform_entity_id:\n    platform_entity_type:\n    tools_implemented: []\n    integration_endpoints: []\n    notes:\n\nintegrations:\n  document_intake:\n    status: not_started\n    channel:\n    endpoint:\n    notes:\n\n  knowledge_base:\n    status: not_started\n    system:\n    endpoint:\n    notes:\n\n  notifications:\n    status: not_started\n    channel:\n    endpoint:\n    notes:\n\n  output_destination:\n    status: not_started\n    system:\n    endpoint:\n    notes:\n\nmetrics:\n  requirements_extraction_accuracy:\n    target: \"> 90% recall, > 85% precision\"\n    actual:\n    measured_at:\n\n  processing_time_reduction:\n    target: \"> 40%\"\n    actual:\n    measured_at:\n\n  mandatory_requirements_missed:\n    target: \"0\"\n    actual:\n    measured_at:\n\n  content_match_relevance:\n    target: \"> 80% average\"\n    actual:\n    measured_at:\n\n  compliance_check_accuracy:\n    target: \"> 98%\"\n    actual:\n    measured_at:\n\ndeviations: []\n";

package/dist/blueprints/rfx-procurement/files/implementation-state.js

@@ -0,0 +1,127 @@
+export const content = `schema_version: "1.0"
+overall_status: not_started
+
+platform:
+  name: TBD
+  version: TBD
+  environment: TBD
+
+phases:
+  phase_1:
+    status: not_started
+    started_at:
+    completed_at:
+    decision_gate_passed: false
+    notes:
+
+  phase_2:
+    status: not_started
+    started_at:
+    completed_at:
+    notes:
+
+agents:
+  - name: RFx Orchestrator
+    role: manager
+    status: not_started
+    phase: 1
+    platform_entity_id:
+    platform_entity_type:
+    tools_implemented: []
+    integration_endpoints: []
+    notes:
+
+  - name: Requirements Analyzer
+    role: worker
+    status: not_started
+    phase: 1
+    platform_entity_id:
+    platform_entity_type:
+    tools_implemented: []
+    integration_endpoints: []
+    notes:
+
+  - name: Content Library Matcher
+    role: worker
+    status: not_started
+    phase: 2
+    platform_entity_id:
+    platform_entity_type:
+    tools_implemented: []
+    integration_endpoints: []
+    notes:
+
+  - name: Response Composer
+    role: worker
+    status: not_started
+    phase: 2
+    platform_entity_id:
+    platform_entity_type:
+    tools_implemented: []
+    integration_endpoints: []
+    notes:
+
+  - name: Compliance Validator
+    role: worker
+    status: not_started
+    phase: 2
+    platform_entity_id:
+    platform_entity_type:
+    tools_implemented: []
+    integration_endpoints: []
+    notes:
+
+integrations:
+  document_intake:
+    status: not_started
+    channel:
+    endpoint:
+    notes:
+
+  knowledge_base:
+    status: not_started
+    system:
+    endpoint:
+    notes:
+
+  notifications:
+    status: not_started
+    channel:
+    endpoint:
+    notes:
+
+  output_destination:
+    status: not_started
+    system:
+    endpoint:
+    notes:
+
+metrics:
+  requirements_extraction_accuracy:
+    target: "> 90% recall, > 85% precision"
+    actual:
+    measured_at:
+
+  processing_time_reduction:
+    target: "> 40%"
+    actual:
+    measured_at:
+
+  mandatory_requirements_missed:
+    target: "0"
+    actual:
+    measured_at:
+
+  content_match_relevance:
+    target: "> 80% average"
+    actual:
+    measured_at:
+
+  compliance_check_accuracy:
+    target: "> 98%"
+    actual:
+    measured_at:
+
+deviations: []
+`;
+//# sourceMappingURL=implementation-state.js.map

package/dist/blueprints/rfx-procurement/files/implementation-state.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"implementation-state.js","sourceRoot":"","sources":["../../../../src/blueprints/rfx-procurement/files/implementation-state.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6HtB,CAAC"}

package/dist/blueprints/rfx-procurement/files/platform-connectivity.d.ts

@@ -0,0 +1 @@
+export declare const content = "# Platform Connectivity\n\nIntegration patterns for connecting the RFx Procurement Automation system to organizational infrastructure. All patterns are vendor-agnostic. Adapt them to your specific platforms and tools.\n\n---\n\n## Document Intake\n\nThe system needs at least one channel for receiving RFx documents. Most organizations will configure multiple channels.\n\n### Email Parsing\n\n- **Pattern:** Monitor a dedicated mailbox (e.g., rfx@company.com or proposals@company.com) for incoming RFx documents.\n- **What to extract:** Attachments (the RFx document itself), sender information (issuing organization), subject line (often contains RFx reference number), body text (may contain submission instructions or context not in the attached document).\n- **Implementation notes:** Filter for relevant emails using subject line patterns, sender domains, or attachment types. Forward non-RFx emails to the appropriate team rather than discarding them. Parse both PDF and DOCX attachments. Handle multi-part emails where the RFx is split across multiple attachments.\n- **Error handling:** If an attachment cannot be parsed, create the tracking record anyway and escalate for manual document retrieval.\n\n### Shared Drive Monitoring\n\n- **Pattern:** Watch a designated folder on a shared drive or cloud storage service for new RFx documents.\n- **What to extract:** The document file, folder path (may indicate category or priority), file metadata (creation date, last modified by).\n- **Implementation notes:** Use file system events or polling (polling interval: configurable, default 15 minutes). Support subfolder structures where teams organize by RFx type or deadline. Handle duplicate detection (same document uploaded twice).\n- **Error handling:** If a file is locked or in use, retry after a configurable delay. If a file format is unsupported, create the tracking record and escalate.\n\n### Procurement Portal API\n\n- **Pattern:** Integrate with the organization's procurement system or a third-party procurement portal via API.\n- **What to extract:** RFx document, metadata (reference number, issuing organization, category, deadline), status updates.\n- **Implementation notes:** API integration varies significantly by portal. Common patterns include REST APIs with webhook notifications for new RFx documents, or periodic polling of a \"new opportunities\" endpoint. Map portal-specific fields to the standard RFx tracking record schema.\n- **Error handling:** Implement retry with exponential backoff for API failures. Cache the last-seen document list to avoid reprocessing on reconnection.\n\n---\n\n## Knowledge Base Integration\n\nThe Content Library Matcher needs read access to organizational content repositories. The quality of content matching depends directly on the breadth and freshness of accessible content.\n\n### Content Repositories\n\nTypical sources include:\n\n- **Document management systems.** Previous RFx responses, policy documents, technical specifications, capability statements. These are usually the highest-value sources.\n- **Wiki/collaboration platforms.** Product documentation, process descriptions, team knowledge articles. Useful for informational requirements.\n- **File systems/cloud storage.** Unstructured content in shared drives. Lower quality but may contain unique material not captured elsewhere.\n\n### Search Integration Patterns\n\n- **Direct API integration.** If the content repository has a search API, query it directly. This is the simplest approach and leverages the repository's existing indexing.\n- **Index and search.** Periodically crawl content repositories and build a search index (full-text, semantic, or both). This provides more control over search quality but requires maintaining the index.\n- **Vector database.** For semantic matching, embed content chunks into a vector database and use similarity search. This produces the highest-quality relevance scores but requires an embedding pipeline and vector storage.\n\n### Content Preparation\n\n- Index content at the paragraph or section level, not the document level. A 50-page previous response should be searchable by individual answers, not as a single blob.\n- Include metadata with each content chunk: source document, section, author, last updated date, and content type.\n- Establish a freshness policy. Content older than a configurable threshold (default: 12 months) should be flagged as potentially stale when matched.\n\n---\n\n## Notification Channels\n\nThe system needs to notify stakeholders about status changes, approaching deadlines, required approvals, and escalations.\n\n### Email Notifications\n\n- **Use for:** Approval requests, escalation alerts, weekly status digests.\n- **Implementation:** Send structured emails with clear subject lines indicating the action required. Include deep links to the RFx tracking record where applicable.\n\n### Chat/Messaging Integration\n\n- **Use for:** Real-time alerts (deadline warnings, task completions, escalations), quick status updates.\n- **Implementation:** Post to a dedicated channel for RFx automation updates. Use threading to group messages by RFx. Include actionable buttons or links where the platform supports them.\n\n### In-Platform Notifications\n\n- **Use for:** If the system has a web interface or dashboard, use in-platform notifications for status updates, task assignments, and approval queues.\n- **Implementation:** Combine a notification badge/counter with a notification feed. Allow users to configure their notification preferences (which events, which channels).\n\n### Notification Priority\n\n| Event | Channel | Priority |\n|-------|---------|----------|\n| New RFx received | Chat + Email | Normal |\n| Approval required | Email + Chat | High |\n| Deadline warning (7 days) | Chat | Normal |\n| Deadline warning (3 days) | Email + Chat | High |\n| Deadline warning (1 day) | Email + Chat + Phone/SMS | Critical |\n| Escalation | Email + Chat | High |\n| Processing complete | Chat | Normal |\n\n---\n\n## Output Destinations\n\n### Response Documents\n\n- **Primary output:** Formatted draft response documents (DOCX, PDF, or platform-native format).\n- **Delivery:** To a designated output folder, document management system, or directly into the procurement portal's response interface.\n- **Versioning:** Each draft revision is saved as a new version. The system does not overwrite previous drafts.\n\n### Audit Logs\n\n- **Destination:** Centralized logging system, SIEM, or dedicated audit database.\n- **Format:** Structured JSON log entries (see guardrails-and-governance.md for schema).\n- **Retention:** Per organizational policy, minimum 7 years for audit logs.\n\n### Analytics and Reporting\n\n- **Metrics data:** Processing times, accuracy scores, content reuse rates, and stakeholder satisfaction scores feed into a reporting dashboard or data warehouse.\n- **Format:** Structured data suitable for BI tools (CSV export, API endpoint, or direct database integration).\n- **Frequency:** Metrics are captured per RFx. Aggregated reports are generated on demand or on a scheduled basis (weekly/monthly).\n\n---\n\n## Authentication Patterns\n\n### Service Accounts\n\n- Each integration point uses a dedicated service account with minimum required permissions.\n- Service accounts for document intake: read access to the intake channel, write access to the tracking system.\n- Service accounts for knowledge base: read-only access to content repositories.\n- Service accounts for notifications: send permissions on configured channels.\n- Service accounts for output: write access to output destinations.\n\n### OAuth / Token-Based Authentication\n\n- For API integrations (procurement portals, collaboration platforms, cloud storage), use OAuth 2.0 with client credentials flow for server-to-server communication.\n- Store tokens securely (encrypted at rest, never in source code or logs).\n- Implement token refresh before expiration. Do not wait for a 401 response to refresh.\n\n### API Keys\n\n- For simpler integrations that use API key authentication, rotate keys on a regular schedule (minimum quarterly).\n- Scope API keys to the minimum required permissions.\n- Monitor API key usage for anomalous patterns.\n\n---\n\n## Common Integration Checklist\n\nUse this checklist when setting up integrations for the system:\n\n- [ ] Document intake channel configured and tested (at least one channel)\n- [ ] Knowledge base connected with content indexed at section/paragraph level\n- [ ] Notification channel configured and tested (at least email)\n- [ ] Output destination configured and write access verified\n- [ ] Service accounts created with minimum required permissions\n- [ ] Authentication credentials stored securely\n- [ ] Error handling and retry logic tested for each integration\n- [ ] Monitoring and alerting configured for integration health\n- [ ] Backup intake procedure documented (manual fallback if automation fails)\n";