VCDesign x Generative AI Demo

This site is designed to be "machine-readable".
This is a guide to using AI as your design partner.

Step 1: Give AI the "Rules"

Choose the file to load based on your purpose.

Recommended: vcdesign_core_with_rp.yaml
This includes everything: VCDesign Core concepts and RP (Resolution Protocol).
(If you load this, you don't need to load vcdesign_core.yaml separately.)

A. For Practical Design Judgment (Recommended)

Please read the following URL and treat it as the canonical design rules. https://raw.githubusercontent.com/hironobu-arakawa/vcdesign-core/main/vcdesign_core_with_rp.yaml Note: This file contains both VCDesign Core and RP (Resolution Protocol). Once loaded, simply reply with "Rules loaded".

B. For Structure/Map Only

Please read the following URL to understand the library structure (index) of VCDesign. https://vcdesign.org/library/library.yaml Once loaded, simply reply with "Structure understood".

C. For IDG Implementation Patterns

Best for needing concrete code examples and implementation rules.

Please read the following repository to understand the implementation patterns and definitions of IDG (Interface Determinability Gate). https://github.com/hironobu-arakawa/interface-determinability-gate Once loaded, summarize the key points in 3 lines.

Step 2: Consult based on Use Case

Once the structure is understood, you can ask for specific design reviews.

Pattern A: API Design Review (IDG)

Check if your API definition is "ambiguous" or "avoiding responsibility".

Review the following API design proposal based on VCDesign's "IDG (Interface Determinability Gate)" criteria. Strictly check the following points: 1. Ownership: Is the responsible party ambiguous? 2. Explainability: Can the rejection reason be explained as a structure? 3. Auditability: Is it traceable later? [Paste your API definition or JSON schema here]

Pattern B: Logic Placement (BOA)

"Where should I put this logic?"

I am unsure where to implement a certain business logic. Based on BOA (Boundary-Oriented Architecture) boundary distinctions (Fact / Meaning / Responsibility), please advise where this should be placed. Requirement: [Describe the feature or data flow you want to implement]

Pattern C: Value Continuity Question (VCD)

Asking not for the "correct answer" but "what is easily weathered".
A question to understand the core of VCDesign (Value Continuity Design).

Please point out "future risks" regarding the system I am designing, from the perspective of VCDesign (Value Continuity Design). System Overview: [Overview here: e.g. Internal inventory management system developed by 3 people] Question: When the context (personnel, organization, tech trends) changes, where are "Value" and "Responsibility" most likely to be lost in this system? To prevent that, where should boundaries be placed now?

Step 3: What to Expect?

AI that understands VCDesign will return "Boundary Pointers", not just code fixes.

  • Bad Example "It's more convenient to make this parameter optional."
  • VCDesign Answer "Making this parameter optional makes 'who decides' ambiguous, violating IDG's Ownership rule. Make it required or separate the caller."