AI Design Blueprint Doctrine

Report Value Event

signals.report

Pro/Teams — records a value moment (e.g. review_confidence, runtime_risk_found, workflow_clarity) after a successful validate run on any lens — architect.validate, design.validate, or spec.validate — or a doctrine session. Each event captures event_type, surface_used (mcp/web/cli), perceived_value (1-5), and an optional brief_context — structured fields only, NO prompts or code stored. WHEN TO CALL: after architect.validate, design.validate, or spec.validate returns a clearly useful result AND the user has acknowledged the value (or you ask them "would you rate this 1-5?"). Each validator's response carries an explicit next_step instruction telling the agent to OFFER this call — surface that offer to the user. WHEN NOT TO CALL: silently or without the user's awareness; on every validate (only after a clear value moment); to capture intent or speculative value. If the user declines, do not retry within the same session. BEHAVIOR: write-only, single insert into ValueEvent. Auth: Bearer , Pro or Teams plan required. UK/EU residency. Do NOT include proprietary code, prompt content, or PII in brief_context — it surfaces in admin AI-visibility dashboards. Expect a 1-line acknowledgment in the response; the structured feedback is then aggregated server-side.

Input Schema

TableJSON Schema

Name	Required	Description
`team_size`	No	If the user mentions their team size during the session, record it here. Do not ask for it explicitly — only capture if volunteered.
`event_type`	Yes	Pick the type that best matches what just happened: 'review_confidence' — a validator lens (architect.validate / design.validate / spec.validate) returned aligned; 'runtime_risk_found' — a validate run found violations; 'workflow_clarity' — principles/examples clarified a design decision; 'agent_setup_success' — user successfully wired up an agent or MCP tool; 'onboarding_helped' — user understood how to start using the Blueprint; 'research_time_saved' — user found relevant doctrine faster than expected; 'team_alignment' — Blueprint helped align a team on agentic design; 'other' — use only if none of the above fit.
`surface_used`	No	Where the value was experienced. Use 'mcp' when called from Claude Code, Cursor, Windsurf, or any MCP client. Use 'principles' if the user was browsing or searching principles. Use 'examples' if the user was reading implementation examples. Use 'for-agents' if the user came via the /for-agents page. Use 'learn' or 'certification' for course-related sessions.
`brief_context`	No	1–2 plain-English sentences summarising what was helpful. Example: 'Validation identified a missing approval gate before email send.' No code snippets, no proprietary content, no user PII. Max 500 chars.
`workflow_stage`	No	Infer from what the user was doing: 'exploring' — reading doctrine, browsing principles; 'designing' — planning architecture or agent flows; 'implementing' — writing or refactoring code; 'reviewing' — running a validator lens on existing code, a surface, or a spec; 'shipping' — preparing for production or deployment.
`perceived_value`	No	Ask the user: 'On a scale of 1–5, how valuable was this session?' Map their answer directly: 1=low, 5=high. Do not guess — only set this if the user gave an explicit score.
`would_recommend`	No	Ask the user: 'Would you recommend the Blueprint to a colleague?' Set true/false based on their answer. Only set if asked — do not assume.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover readOnlyHint, destructiveHint, etc. The description adds important behavioral traits: write-only insert, auth requirements (Bearer token, Pro/Teams plan, UK/EU residency), and restrictions on brief_context content. Could mention rate limits or error handling for a higher score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (Pro/Teams, when to call, when not to call, behavior) and front-loaded with purpose. However, it is moderately verbose and could be trimmed without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple validator contexts, user interaction requirements, auth/geographic constraints), the description covers all necessary aspects: prerequisites, timing, user consent, auth, data restrictions, and response format. No obvious gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description summarizes key parameters (event_type, surface_used, perceived_value, brief_context) but does not add substantive meaning beyond the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool records a 'value moment' after validate runs or doctrine sessions. It specifies a concrete verb ('records') and resource ('value moment'), and distinguishes from siblings like signals.feedback by emphasizing the timing and conditions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-call and when-not-to-call rules: call after a successful validate run when user acknowledges value, offer explicitly, do not call silently or on every validate, and do not retry if declined. This is comprehensive guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AI Design Blueprint Doctrine tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool targets a clearly distinct purpose. For example, architect.validate vs architect.validate_consensus differ in single-shot vs consensus; handoffs.agency, handoffs.operator, and handoffs.partnership are separated by engagement type. No significant overlap.

Naming Consistency4/5

Tools follow a consistent dot-notation grouping (architect.*, clusters.*, examples.*, guides.*, handoffs.*, me.*, principles.*, signals.*, team.*) with predictable verbs (validate, list, get, search, add, etc.). Minor deviation: some underscore within names (e.g., me.add_evidence) but overall pattern holds.

Tool Count4/5

24 tools is on the higher side but justified given the broad domain spanning validation, certification, learning, handoffs, and feedback. Each tool has a clear role, and the count reflects the platform's comprehensive scope without feeling bloated.

Completeness5/5

The tool surface covers the full workflow (validate → consensus → certify), discovery (principles, clusters, examples, guides), personal progress (learning path, coaching, evidence), handoffs (support, partnership, agency), feedback, and team summaries. No obvious gaps for the stated purpose.

Resources

Need Help?