In++ 2.0

Pattern Library v1

What is a Pattern?

A Pattern defines a class of intents - a reusable template with standardized fields. An Example shows a specific filled intenture based on a pattern.

Pattern answers: how is this class of intents structured? Example answers: what does a specific filled intenture look like?

Unified Pattern Structure

Each pattern includes:

  • Name
  • Object
  • Primary Actor
  • Supporting Actors
  • Value
  • Expected Output
  • Nature of the intenture
  • Constraints
  • Required Initial Inputs
  • Outputs by Actor
  • Review Cadence
  • Critical Signals
  • Final Decision Authority
  • Rule in Case of Conflict / Disagreement
  • Success Criterion
  • 4 Reference Patterns

    Client Intenture

    Purpose: Explication Record of a client's intent, created by an agency, consultancy, or service provider to capture the client's business request in a structured, actionable form Key Actors: Client (intent owner, decision maker) + Service Provider (explicator) + Client's stakeholders Specialized Fields:
    • Business Goal and Monetization Model
    • Product/Service details (type, stage, pricing, funnel)
    • Target Audience segments
    • Unit Economics (CPL, ROAS, conversion benchmarks)
    • Knowledge Cards: Client, Product, Market, Competitive
    Specialized Readiness:
    • Client's intent clearly expressed and bounded
    • Business constraints defined (budget, timeline, legal)
    • Expected outcomes measurable (KPIs with benchmarks)
    • Knowledge Cards initiated (at least Draft status)
    • Fit assessment completed (client matches provider capabilities)
    Ready-for-Realization: Universal CRT + Assumption Gate + business constraints clear + KPIs defined + Knowledge Cards initiated + fit assessment passed

    Health Care Team

    Purpose: Coordinated multi-expert health program Key Actors: Primary person + supporting experts (nutritionist, endocrinologist, cardiologist, etc.) Specialized Readiness:
    • Primary health goal defined
    • Baseline health data available
    • Jurisdiction clarified
    • Escalation rules between experts defined
    • Expert boundaries and decision authority established
    Ready-for-Realization: Universal CRT + Assumption Gate + all blocking fields Answered + expert roles agreed

    AI Agent

    Purpose: Bounded, observable, escalation-capable AI agent Key Actors: AI agent + human oversight team Specialized Readiness:
    • Allowed/prohibited actions defined
    • Escalation rules clear
    • Failure conditions specified
    • Decision boundaries established
    Ready-for-Realization: Universal CRT + Assumption Gate + allowed/prohibited actions defined + escalation rules fixed

    Product / Service

    Purpose: New or significantly changed product/service with clear value proposition Key Actors: Target users + development team + stakeholders Specialized Readiness:
    • Target user identified
    • Value proposition articulated
    • First scope boundary set
    • Success criteria defined
    • Key assumptions listed
    Ready-for-Realization: Universal CRT + Assumption Gate + target user defined + value proposition formulated + first scope fixed

    Hierarchical Multi-intenture Project (v1.9)

    Object: Large-scale project (platform, product, ecosystem) decomposed into a hierarchy of related sub-intentures with formal Constraint inheritance, Value aggregation, and Vergil coordination. Example: WiseTeam as AI-agent platform. Primary Actor: Human initiator (founder, product owner, lead architect) Supporting Actors: Sub-intenture owners, Vergil as coordinator, cross-tree dependency owners Critical Constraints:
    • [safety], [legal] - mandatory inheritance to all sub-intentures (override forbidden)
    • [scope] - root scope bounds the entire hierarchy
    • [budget], [resource] - Pool & Allocate from root to sub-intentures
    • [timeline] - Capped: root deadline = upper bound
    Specialized Readiness:
    • Composition tree valid (DAG, separability 4-tests pass for each child)
    • Value coverage: all root must-have Value items covered by child contributions
    • Pool allocation balance (sum ≤ total for each pool)
    • Inheritance compliance (no override violations)
    • Depth ≤ 3 (recommendation)
    Critical Signals:
    • Sub-intenture violation → blocks parent's Realizable
    • Pool overflow or Capped violation → blocks child's Realizable
    • Low-separability child (0-2/4 tests) → Vergil suggests collapse into Canvas block
    • Tangled Value coverage → Vergil signals human
    • High sibling coupling → signal "consider separate sub-portfolio"
    Ready-for-Realization: Universal CRT for root + all children Structured+ + Value coverage gate + no constraint violations in blocking children + Vergil green-light Reference: Intenture_Composition_Test/ (WiseTeam decomposition, depth-5 stress-tested)

    > Note on Client Intenture: the Client Intenture pattern mentioned above is Inspark CVD process domain extension, not part of core language. Described here as reference for production application. In core Pattern Library (§20 Master Release Document v1.9) - 4 patterns: Health Care Team, AI Agent, Product/Service, Hierarchical Multi-intenture Project.

    Entry Patterns

    Each pattern can be entered via 3 paths:

  • Greenfield - Starting from scratch. All Canvas blocks begin with Unknown Yet. Protocol: Capture -> Extract -> Normalize -> Clarify -> Validate -> Stress-Test -> Confirm Assumptions -> Decide Readiness -> Prepare Realization Form.
  • From Concept - Extracting from existing document. Capture receives a document, Extract works on text, some blocks may be immediately Answered or Assumed by AI. All steps including Confirm Assumptions apply.
  • Takeover - Reverse explicating from existing system. Extended protocol with Audit and Reverse Extract steps before Capture, plus Reconcile step for gap analysis. All steps including Confirm Assumptions apply.