IntentureIntenture

Changelog

Version history and release notes for the Intenture language.

v2.0 (In++ 2.0)2026-05
  • Major version bump: Intenture 1.9 → In++ 2.0 (canonical name 'Intenture', short form 'In++')
  • §16 Realization Artifacts (new chapter) - Core Entity + Realization Artifact Type + lifecycle (Draft/Active/Stale/Superseded/Archived) + JSON canonical template + domain extension via namespace manifests + Inspark CVD (SP/IRS/TB/PB) as reference implementation
  • §7.12 Block Taxonomy - 9 generic primitives in core (paragraph, heading, list, table, blockquote, pre, callout, metadata_grid, toc) + typed block envelope + domain extension mechanism via manifests + Canvas v2.0 supports typed blocks + backward-compat preserved
  • §7.10.8 Cross-org Namespace Governance - hierarchical namespace <org>/<project>[/<sub-project>] + URN syntax urn:intenture:<namespace>:<type>:<id> + reference resolution rules (5 steps with fallback) + cross-org collaboration patterns (reference/fork/joint/public)
  • §6 Meta-Model: Core Entities 20 → 22 (added Realization Artifact + Realization Artifact Type); semantic formulas 22 → 24 (added realizes, derived_from)
  • §7.7 Linked Artifacts section becomes typed (was untyped slots)
  • Renumbering: §16 Realization Artifacts inserted; old §16-27 → new §17-28
  • Core JSON Schemas v2.0: schemas-core/v2.0/ with realization-artifact.schema.json, 9 block primitives in blocks/ subdir, hierarchical namespace support in envelope
  • Sample artifacts: Sample Realization Artifact (Inspark SP example), Sample typed-blocks Canvas
  • All v1.4-v1.9 vulnerabilities (V1-V7) closed in prior versions; v2.0 formalizes architectural extensibility mechanisms preventing future artifact debt
  • Document title rebrand: 'Intenture 1.X' → 'In++ 2.0'; both names remain valid
  • §7.10.9 Registry Protocol - formal REST API contract: 10 endpoints (resolve, search, artifact lookup, version history, manifest, publish, etc.), response shapes, cache semantics, federation patterns, trust verification, minimum viable registry profile
  • §28 Tooling Specification (new chapter) - canonical 'intenture' (in++) CLI: 13 commands, configuration system, validator API contract, migration tooling, exit codes; renumber §28 → §29 Final Statement
  • Visual Notation v2.0 SVG diagrams: §05 Composition Tree, §06 Value Coverage Map, §07 Knowledge Card Graph - all rendered in Intenture_Visual_Notation.html
  • schemas-core/v2.0/namespace-manifest.schema.json - formal JSON Schema for namespace manifests
  • 3 reference namespace manifests in manifests/: wiseorg-inspark (6 KC + 4 RA + 8 blocks), wiseorg-wiseteam (3 KC + 4 RA), wiseorg-intenture-examples (empty reference)
  • Domain_Extension_Guide.md - complete 7-step guide for creating domain extensions + best practices + trust/signing + reference examples
  • All 'pending', 'post-MVP', 'future work' markers removed - clean release with formal references replacing placeholders
v1.92026-05
  • Closes Vulnerability V4 (Rollback) - all identified V1-V7 vulnerabilities are now resolved in v1.4-v1.9 line
  • §13.10 Knowledge Card JSON canonical template - formal JSON envelope (uuid, id, namespace, display_name, metadata) + KC-specific fields (card_type, staleness_period_days, staleness_last_check, fields, informed_by, used_by reverse index)
  • §13.11 Staleness Check Automation - Vergil periodically checks KC actuality, auto-transitions Active → Stale at staleness_period_days expiry, cascade signaling to all intentures with informed_by
  • §13.12 KC → KC Graph Rules - acyclic constraint (DAG), version cascade on upstream change, reference integrity, type-compatibility per domain, graph depth recommendation ≤ 3
  • §15.4a Vergil KC Management - operational responsibilities for KC staleness, cascade signaling, graph validation; KC version bumps classified by authority (patch/minor → Vergil; major → human)
  • §9.8 Rollback Procedure - formal mechanism: when allowed (failed realization, critical signal, substantive change reversal), authority (Vergil operational vs human substantive), 7-step procedure with audit log, 'Reverted' status semantics, lifecycle re-evaluation after rollback, rollback in Composition tree rules
  • §7.10.3 validation rules extended: readiness_layer.realization_decision mandatory for intentures in lifecycle state ≥ Explicated; metadata.entry_pattern mandatory for intentures created in v1.9+
  • §19.4 Entry Pattern Tracking - metadata.entry_pattern enum (greenfield | from_concept | from_artifacts | takeover) + entry_pattern_metadata; Vergil auto-detects on first Explication Record
  • §7.11 JSON template updated with entry_pattern example
  • Scope boundary explicitly fixed: language (In++) core / domain extension / project instance layers - prevents future bloat with company-specific artifacts (SP/IRS/TB/PB remain Inspark CVD domain extension, not core language)
  • Vulnerabilities Roadmap document: 'Open Vulnerabilities' section now empty; all V1-V7 closed
v1.82026-05
  • Composition Hierarchy (§14) - new chapter; closes Vulnerability V1 (Canvas scalability) and V6 (Value prioritization)
  • Composition as separate primitive in Meta-Model (not a special inter-intenture relation type) - tree formalism parallel to V2 graph of dependencies
  • Two inheritance patterns: Inherit & Restrict (safety/legal/scope/quality/coordination/timeline - child can only tighten) and Pool & Allocate (budget/resource - shared pool, allocated_from with sum check)
  • Override governance per constraint type: safety/legal/scope/timeline override forbidden always; quality/coordination override allowed with rationale + approved_by (Vergil for operational, human for substantive)
  • Structured Value items - new format with id, description, priority (must-have/should-have/nice-to-have), beneficiary, measurement, status, tags, delivered_by, contributes_to_parent_value; backward-compat with single string
  • Value-coverage-driven Readiness roll-up: parent → Realizable when every must-have Value item has at least one Structured+ child contributing to it; value_coverage computed in expanded view
  • Lifecycle independence with 2 hard constraints (child not Realizable+ if parent Dream/Exploratory; child not Active if parent Archived) + 2 soft warnings
  • Separability Principle (4 tests: Independent Intent, Discrete Expected Output, Own Value, Reparent-survivable) - qualifies child as sub-intenture vs Canvas block; prevents over-decomposition
  • Vergil (§15) - new chapter; AI agent named after Virgil of Dante's Divine Comedy; primary decision-maker for operational matters; human escalation only for substantive product/result/value decisions
  • Vergil complexity signaling responsibility: depth > 3, dense cross-tree graph, multiple overrides, low-separability children, tangled Value coverage, high sibling coupling
  • Three-tier addressing: uuid (UUIDv7 immutable) + id (mutable slug in namespace) + display_name (cosmetic); cross-references use slug + namespace + UUID fallback
  • Identity Operations (§9.7): rename, move, detach, split, merge with audit trail and authority classification (Vergil operational vs human substantive)
  • JSON envelope extended: uuid, id, namespace, display_name added as mandatory fields
  • 8-section canonical AI-facing form architecture (Composition inserted between Readiness Layer and Knowledge Cards)
  • 20 core entities (+Composition, +Vergil), §6.4b Composition Relations (contains/parent_of/inherits_constraint_from/allocates_from/contributes_to_value), 22 semantic formulas (+contains, +inherits_into, +contributes_to, +governs)
  • PM → Vergil terminology shift; ig-prompt → vergil-prompt in nav
  • Validated by 3 blind tests: comprehension at depth 5, violation detection (forbidden safety override + budget pool overflow + capped timeline violation), separability classification (7/8 perfect match on 8 candidates)
v1.72026-05
  • JSON-canonical representation promoted from practice (Inspark/Nick 2.0) to formal core of the language
  • §7.1 rewritten: dual-layer syntax now explicitly distinguishes canonical form (JSON, source of truth) from production forms (text serialization, visual rendering)
  • §7.3 rewritten: AI-facing syntax defined as canonical JSON conforming to registered JSON Schema; 6 formal requirements (canonical, unambiguous, normalizable, validatable, typed, versionable)
  • §7.10 new section: JSON-canonical specification - Schema as source of truth, required envelope ($schema, artifact_type, schema_version, artifact_version, metadata), validation rules, schema_version vs artifact_version separation, provenance fields, Information Source tags
  • §7.11 new section: canonical JSON template parallel to text template §7.9
  • §11.1 updated: Canvas as Single Source of Truth now explicitly via canonical JSON; derived forms (human-facing rendering, text serialization) auto-generated from JSON
  • Closes Vulnerability V7 (formal AI-facing form validation)
v1.62026-03
  • Knowledge Cards — typed, structured, versioned knowledge units that exist independently of any intenture, linked via informed_by relation
  • Knowledge Card Type — extensible category system: each domain defines its own card types with specific field schemas
  • informed_by relation — directed link from intenture to Knowledge Card (and between cards) for building knowledge graphs
  • Knowledge Card Lifecycle — four states: Draft → Active → Stale → Archived, with staleness period per card type
  • Information Source — extended data origin markers: [fact], [hypothesis:human], [hypothesis:ai], [research] (with source and date), [to-collect], [unknown]
  • Knowledge Cards section in AI-facing form — new section between Readiness Layer and Linked Intenture
  • AI-facing form canonical architecture updated to 7 sections: Core Definition, Supporting Context, Development Layer, Readiness Layer, Knowledge Cards, Linked Intenture, Linked Artifacts
  • Canvas Evidence block can reference Knowledge Cards via [see: card_type/card_name]
  • Readiness influence — if a linked Knowledge Card is Stale or Draft, PM warns the human and suggests updating before Realizable transition
  • Canonical Knowledge Card template formalized: header, typed fields with Information Source tags, Change Log
  • 2 new semantic formulas (17-18) for informed_by relation
  • 19 core relations (added informed_by), 18 core entities (added Knowledge Card)
  • New section 13 in Master Release Document: Knowledge Cards (13.1-13.9)
v1.52026-03
  • Intenture Portfolio - graph of related intenture with 5 typed inter-intenture relations: depends_on, enables, conflicts_with, shares_constraint_with, shares_actor_with
  • Linked Intenture - new section in AI-facing form for declaring inter-intenture relations
  • Portfolio Dependencies Gate - 3rd level in four-level Readiness model: blocking dependencies must be Realizable or above
  • Intenture Portfolio Map - new diagram type in Visual Notation for visualizing inter-intenture relations
  • Inter-intenture visual styles - 5 line styles for relation types in diagrams
  • 5 new semantic formulas (12-16) for inter-intenture relations
  • 18 core relations (added 5 inter-intenture relation types)
  • AI-facing form canonical template updated with Linked Intenture section
  • Lifecycle Transitions Table - Structured to Realizable requires Portfolio Dependencies Gate
  • Specialized Readiness Matrix - all patterns updated with Portfolio Dependencies Gate
  • PM Exploratory Mode - new responsibility: building Intenture Portfolio Map
  • Four-level Readiness model (was three-level): Universal CRT + Assumption Gate + Portfolio Dependencies Gate + Specialized Readiness
v1.42026-03
  • Assumption Gate - mandatory checkpoint: intenture cannot reach Realizable while any Canvas block has Assumed by AI status
  • Accepted Assumption - sixth Canvas block status for consciously accepted AI assumptions
  • Three resolution paths for Assumed by AI - Confirm (Answered), Accept (Accepted Assumption), or Reject (Unknown Yet); Accept path forbidden for [safety] and [legal] Constraints
  • Step 7 Confirm Assumptions - new step in AI Interpretation Protocol between Stress-Test and Decide Readiness
  • Lifecycle Transitions Table - Structured to Realizable transition requires Assumption Gate passed
  • PM Operating Modes - Structuring Mode updated with Assumption Gate responsibilities and exit criteria
  • Entry Patterns - all three patterns updated to include Confirm Assumptions step
  • [resource] - new Constraint type for people, infrastructure, tools, licenses
  • Structured Constraint Format - optional machine-readable fields (amount, currency, deadline, flexibility, etc.) for [budget], [timeline], and [resource] constraints
  • AI-facing form canonical template updated with structured constraint examples
  • Realization Mode - PM tracks spend and deadlines when structured [budget] and [timeline] constraints are present
  • Removed per-section version numbers - all sections are part of the unified language version
v1.32026-03
  • Intent Vocabulary - 8 canonical verbs (create, improve, maintain, restructure, explore, extend, migrate, retire)
  • Constraint Type Vocabulary - 7 types with priority levels
  • Conflict Resolution Protocol - 3 strategies (Escalate, Propose Alternative, Request Prioritization)
  • Development Layer syntax formalized (States, Transitions, Signals)
  • Conception vs Vision distinction clarified
  • Evidence markers: [fact], [to-collect], [assumed]
  • Metrics with targets: [target: value] or [target: TBD]
  • Entry Patterns: Greenfield, From Concept, Takeover
  • Reverse Explication term added
  • Language Policy - canonical terms always in English
  • Partially Answered block status added
  • Vulnerabilities & Roadmap document added
v1.22026-02
  • PM Operating Modes (4 modes: Exploratory, Structuring, Realization, Evolution)
  • Specialized Readiness Matrix for 3 patterns
  • Explication Record Versioning Policy
  • Intenture Independence Principle - removed VSM dependency
  • Visual Notation v1.0 - formalized 11 primitives, 5 diagram types, 3 reference diagrams
  • Lifecycle Transitions Table cleaned and formalized
v1.12026-01
  • Lifecycle Transitions Table added
  • AI Protocol integrated with Canvas
  • Explication (process) separated from Explication Record (entity)
  • Canvas established as Single Source of Truth
  • Quick Start and Practical Usage guides updated
v1.02025-12
  • Initial release candidate
  • Canonical Definition and Manifesto
  • Glossary v1, Meta-Model v1 (17 entities, 16 relations, 10 formulas)
  • Syntax v0.1, Lifecycle Model v1 (8 states, 11 transitions)
  • Visual Notation v0.1, Canvas v1, Object Card v1
  • Readiness Checklist, AI Interpretation Protocol v1
  • Pattern Library v1 (3 patterns), 3 end-to-end examples