Quality Standard
Blueprint Quality Standard v2
The Blueprint Quality Standard (BQS) defines the minimum requirements every ForgeWorkflows Logic Blueprint must satisfy before it can be listed for sale. BQS is the quality gate that justifies premium pricing and differentiates ForgeWorkflows from free community templates.
Every blueprint must pass all 12 points. A single failure blocks the release until resolved. There are no waivers. If a point cannot be met, the blueprint is not ready.
BQS v2 expanded the original 4-point audit to 12 points, incorporating findings from the Independent Test Protocol, inter-agent data schema standards, and production deployment learnings. See the glossary for term definitions.
The 12-Point Audit
Reasoning Required
What is evaluated
Whether the blueprint solves a genuine "Thinking Problem" — a task requiring multi-step reasoning, judgment, or analysis that cannot be reduced to simple if-then-else logic.
PASS
The workflow contains decisions that require dynamic evaluation against complex, variable criteria. Examples: lead qualification against ICP criteria, contract clause risk assessment, research synthesis from multiple sources.
FAIL
Every decision node in the workflow could be replaced by a static lookup table or regex match. Examples: data migration between CRMs, scheduled email sending, RSS-to-Slack notifications.
Modular Swarm Architecture
What is evaluated
Whether the workflow logic is decentralized into specialized agent nodes with defined roles, input schemas, and output schemas. No single monolithic prompt allowed.
PASS
Minimum 3 distinct agent roles (e.g., Researcher, Judge, Writer). Each node has its role documented. The swarm includes at least one explicit IF branch where pipeline behavior changes based on agent output.
FAIL
A single prompt handles all logic, or the pipeline is a linear chain with no conditional routing based on agent decisions.
Self-Correction and Error Handling
What is evaluated
Whether the blueprint handles failures gracefully at every external API call, including retry logic, fallback chains, and dead letter handling for unrecoverable failures.
PASS
Every external API call has: (1) at least 1 retry with backoff, (2) a documented fallback if the primary source fails, and (3) dead letter handling that quarantines failed records instead of silently dropping them.
FAIL
Any external API call lacks retry logic, has no fallback path, or silently drops records on failure.
10-Minute README
What is evaluated
Whether a non-developer operations manager can import and configure the blueprint in under 10 minutes using only the included README.
PASS
README includes: bundle contents, prerequisites with costs, step-by-step import instructions, configuration guide, test procedure, troubleshooting section, and support contact. A first-time user completes setup within the time limit.
FAIL
README is missing critical sections, assumes undocumented prerequisite knowledge, or requires external resources not included in the bundle to complete setup.
Error Handling Matrix
What is evaluated
Whether the blueprint ships with a customer-facing document mapping every failure mode to its resolution path, covering every external dependency.
PASS
Every external API call in the workflow has a corresponding row in the Error Handling Matrix documenting the failure point, trigger condition, automated behavior, and recovery path.
FAIL
The matrix is missing, incomplete, or has fewer rows than the number of external API calls in the workflow.
Test Protocol with Evidence
What is evaluated
Whether the blueprint has been tested against real data with results documented via the Independent Test Protocol (ITP).
PASS
ITP completed with minimum 20 test records across 3+ verticals, all Hold Points passed, actual cost-per-record measured, processing time measured, and edge cases documented with timestamps.
FAIL
Fewer than 20 records tested, any Hold Point unresolved, costs estimated rather than measured, or edge case results undocumented.
Model Selection Rationale
What is evaluated
Whether each agent node documents its LLM tier, specific model, selection rationale, temperature, and token limits.
PASS
Every agent node specifies: LLM tier (Reasoning/Classification/Creative), model name and version, rationale for selection over alternatives, temperature setting, and max token limit.
FAIL
Any agent node lacks model documentation, uses a model without stated rationale, or has no tier classification.
Blueprint Dependency Matrix
What is evaluated
Whether the blueprint ships with a customer-facing document listing all third-party services, API keys, and estimated monthly costs required to operate the workflow.
PASS
Every external service called by the workflow appears in the matrix with: dependency name, required/optional status, purpose, estimated cost, and where to obtain the API key.
FAIL
Any external dependency is missing from the matrix, or cost estimates are absent.
Export Verification
What is evaluated
Whether the .json workflow file imports into a clean n8n instance with zero errors — no pre-existing workflows, no pre-configured credentials.
PASS
Workflow imports cleanly: all nodes load, all connections render, no missing node types, no orphaned references. After credential configuration per the README, one test record runs end-to-end successfully.
FAIL
Any step in the import-configure-test sequence produces an error on a clean n8n instance.
Inter-Agent Data Schemas
What is evaluated
Whether all data passed between agent nodes conforms to documented JSON schemas with snake_case naming, null for missing optionals, ISO 8601 dates, and validation checks.
PASS
Every inter-node data handoff has a defined schema. Malformed input is caught by validation and rejected, not silently passed downstream. Source lineage is tracked.
FAIL
Data schemas are undocumented, naming conventions are inconsistent, or malformed input passes through without validation.
Prompt Engineering Standard
What is evaluated
Whether all system prompts are production-ready with clear role definitions, input specifications, chain-of-thought enforcement, strict output formats, and marked customization points.
PASS
Every prompt has: role definition, input specification, chain-of-thought steps, JSON output schema, constraint list, and temperature/token recommendations. Customization points use {{placeholder}} syntax and are documented in the README.
FAIL
Any prompt contains placeholder text, TODO stubs, ambiguous output format, or unmarked customization points.
Version and Compatibility
What is evaluated
Whether the blueprint carries a version number and documents the specific API versions it was tested against.
PASS
Version block present with: blueprint version (semver), release date, n8n tested version, all API versions explicitly stated, and update policy documented.
FAIL
Version information is missing, API versions are unstated, or no update policy is defined.
Every ForgeWorkflows Logic Blueprint must pass all 12 points before listing. No exceptions.