mirai-graph 1.3.0 → 2.1.0

package/playground/demo-report.md

@@ -1,84 +0,0 @@
-# Mirai Graph Playground Demo Report
-
-Status: deterministic 1.0.0-rc.6 demo
-
-## Control Loop
-
-```text
-seed -> graph -> context -> launch -> transition explanation -> cockpit -> traceability -> multi-source feedback -> evidence -> kaizen -> baseline comparison
-```
-
-## Demo Inputs
-
-- Synthetic package: `benchmarks/synthetic-context-reduction-v0`
-- Objects: `12`
-- Relations: `8`
-- Context pack: `context_pack.task_notify_after_approval`
-- Launch record: `launch_record.synthetic_batch`
-- Transition request: `transition_request.release_ready_to_released`
-- Transition explanation: `transition_explanation.release_ready_to_released`
-- Process-control contract: `process_control_contract.synthetic_executable_process`
-- Development cockpit: `cockpit_report.synthetic_delivery`
-- Feature traceability: `trace_report.synthetic_feature_delivery`
-- Multi-source feedback: `feedback_report.synthetic_multi_source`
-- Baseline comparison: `baseline_comparison.synthetic_notify_after_approval`
-
-## Commands
-
-```bash
-npm run validate:minimal
-npm run seed:preview
-npm run context:generate
-npm run validate:launch-record
-npm run validate:process-transition
-npm run validate:process-transition-report
-npm run validate:process-control
-npm run validate:instrumentation-layer
-npm run validate:instrumentation-report
-npm run validate:implementation-control-cycles
-npm run validate:baseline-comparison
-```
-
-## Transition Explanation
-
-- Requested transition: `release_ready -> released`
-- Matched transition: `true`
-- Required evidence: `release_evidence`
-- Missing evidence: `0`
-- Kaizen decision: `satisfied`
-
-## Instrumentation
-
-- Cockpit production readiness: `not_ready`
-- Cockpit next action: `promote_to_review_ready_after_transition_validation`
-- Feature mappings: `1`
-- Evidence-backed mappings: `1`
-- Multi-source feedback verdict: `accepted_for_transition`
-- Blocking findings: `0`
-- Kaizen refs: `kaizen.synthetic_traceability_checklist`
-
-## Baseline Comparison
-
-- Baseline context units: `620`
-- Mirai Graph context units: `270`
-- Context reduction: `56.4516%`
-- Baseline missed dependencies: `2`
-- Mirai Graph missed dependencies: `0`
-- Verdict: `synthetic_mirai_graph_result_stronger_with_limits`
-
-## What This Demonstrates
-
-- Mirai Graph can validate a graph package.
-- Mirai Graph can generate task-specific context from graph state.
-- Launch records describe bounded work permission.
-- Process transitions are checked and explained against an executable state machine.
-- Process-control contracts bind launch, evidence, recovery and Kaizen policy.
-- Instrumentation connects cockpit signals, feature traceability and multi-source feedback.
-- Baseline comparison records synthetic measurement boundaries.
-
-## Boundaries
-
-- This is a public-safe synthetic demo.
-- Generated context is not canonical state.
-- Evidence and proposals do not authorize canonical updates.
-- Synthetic evidence is not broad scientific proof.

package/profiles/README.md

@@ -1,28 +0,0 @@
-# Mirai Graph Profiles
-
-Profiles adapt Mirai Graph to a domain without changing the core standard.
-Use [Profile Boundaries](../standard/profile-boundaries.md) before adding a new
-profile: most new ideas should become an extension, validator, example or
-proposal before they become another profile.
-
-Current release-candidate profiles:
-
-- [software-specification](software-specification/README.md)
-- [project-management](project-management/README.md)
-- [ai-employee](ai-employee/README.md)
-- [character-layer](character-layer/README.md)
-- [skill-runtime](skill-runtime/README.md)
-- [implementation-control](implementation-control/README.md)
-- [organization-governance](organization-governance/README.md)
-
-Proposal/experimental profile:
-
-- [societal-governance](societal-governance/README.md)
-
-Each release-candidate profile declares allowed object kinds, relation types,
-default readiness and governance gates. Proposal/experimental profiles are
-public-safe exploration surfaces and are not core `1.0.0-rc.1` conformance
-requirements.
-
-Executable profile examples and anti-examples are documented in
-[Profile Conformance Fixtures](../docs/adoption/profile-conformance-fixtures.md).

package/profiles/ai-employee/README.md

@@ -1,132 +0,0 @@
-# AI Employee Profile
-
-Status: 1.0 release-candidate profile
-
-## Purpose
-
-The `ai_employee` profile adapts Mirai Graph to AI employees, AI departments and
-federated AI-service systems.
-
-It treats an AI employee as a governed runtime over an evolutionary graph:
-
-- the graph stores canonical state, roles, skills, knowledge, memory, tools,
-  policies, workflows and lessons;
-- generated context helps a task;
-- runtime execution happens through tools, approvals and audit;
-- feedback proposes learning but does not mutate the graph automatically.
-
-## Object Kinds
-
-Initial allowed object kinds:
-
-- `ai_employee`;
-- `ai_department`;
-- `role`;
-- `specialization`;
-- `skill`;
-- `knowledge`;
-- `memory`;
-- `event`;
-- `signal`;
-- `action`;
-- `tool`;
-- `capability`;
-- `policy`;
-- `workflow`;
-- `automation_rule`;
-- `result`;
-- `feedback`;
-- `lesson`;
-- `delegation`;
-- `federation_endpoint`;
-- `governance_gate`.
-
-## Relation Types
-
-Initial allowed relation types:
-
-- `has_role`;
-- `has_specialization`;
-- `has_skill`;
-- `uses_knowledge`;
-- `requires_capability`;
-- `can_execute`;
-- `requires_approval`;
-- `triggered_by`;
-- `responds_to`;
-- `delegates_to`;
-- `escalates_to`;
-- `supervises`;
-- `learns_from`;
-- `updates_behavior`;
-- `belongs_to_department`;
-- `federates_with`;
-- `produces`;
-- `governs`;
-- `related_to`.
-
-## Governance Gates
-
-Initial gates:
-
-- `human_review_before_canonical_write`;
-- `approval_before_external_action`;
-- `feedback_learning_before_behavior_update`;
-- `public_safety_before_release`.
-
-## Runtime Boundary
-
-The profile does not make the graph a runtime by itself.
-
-Use this separation:
-
-```text
-canonical graph state
--> generated context
--> runtime decision
--> proposed action
--> approval gate
--> executed action
--> audited result
--> feedback
--> learning proposal
--> canonical graph update
-```
-
-## Minimal Useful Package
-
-A Level 1 AI-employee package should include:
-
-- one `ai_employee`;
-- one `role`;
-- one `skill`;
-- one `tool`;
-- one `capability`;
-- one `policy`;
-- one `workflow`;
-- one `action`;
-- one `result`;
-- one `feedback`;
-- one `lesson`;
-- one `governance_gate`;
-- evidence objects or source records where claims need support.
-
-## Current Limitations
-
-The profile does not yet standardize:
-
-- provider-specific LLM capabilities;
-- queue or worker implementation;
-- authentication and authorization runtime;
-- tool sandboxing;
-- long-term memory storage engines;
-- user interface requirements;
-- federation trust protocols.
-
-These belong to implementation profiles or future standard sections.
-
-## Example
-
-Minimal synthetic fixture:
-
-`examples/ai-employee-minimal/`

package/profiles/ai-employee/profile.json

@@ -1,58 +0,0 @@
-{
-  "id": "profile.ai_employee",
-  "name": "AI Employee",
-  "version": "0.1.0",
-  "description": "Profile for modeling AI employees, roles, skills, tools, policies, workflows, actions, feedback and learning gates.",
-  "allowed_object_kinds": [
-    "ai_employee",
-    "ai_department",
-    "role",
-    "specialization",
-    "skill",
-    "knowledge",
-    "memory",
-    "event",
-    "signal",
-    "action",
-    "tool",
-    "capability",
-    "policy",
-    "workflow",
-    "automation_rule",
-    "result",
-    "feedback",
-    "lesson",
-    "delegation",
-    "federation_endpoint",
-    "governance_gate",
-    "evidence"
-  ],
-  "allowed_relation_types": [
-    "has_role",
-    "has_specialization",
-    "has_skill",
-    "uses_knowledge",
-    "requires_capability",
-    "can_execute",
-    "requires_approval",
-    "triggered_by",
-    "responds_to",
-    "delegates_to",
-    "escalates_to",
-    "supervises",
-    "learns_from",
-    "updates_behavior",
-    "belongs_to_department",
-    "federates_with",
-    "produces",
-    "governs",
-    "related_to"
-  ],
-  "default_readiness": "draft",
-  "governance_gates": [
-    "human_review_before_canonical_write",
-    "approval_before_external_action",
-    "feedback_learning_before_behavior_update",
-    "public_safety_before_release"
-  ]
-}

package/profiles/character-layer/README.md

@@ -1,143 +0,0 @@
-# Character Layer Profile
-
-Status: 1.0 release-candidate profile
-
-## Purpose
-
-The `character_layer` profile adapts Mirai Graph to model-independent AI
-character governance.
-
-It treats character as graph state:
-
-- constitution;
-- principles;
-- character virtues;
-- character boundaries;
-- role character profiles;
-- reflection protocols;
-- fixtures;
-- violation patterns;
-- correction loops;
-- evidence and governance gates.
-
-## Non-Goals
-
-The profile does not:
-
-- train or fine-tune a base model;
-- prove alignment or behavior quality;
-- authorize tool use, external actions or canonical writes;
-- replace action gates, runtime policy or human approval;
-- replace the `ai_employee`, `skill_runtime` or `organization_governance`
-  profiles;
-- publish private operational constitution content.
-
-## Object Kinds
-
-Initial allowed object kinds:
-
-- `character_constitution`;
-- `character_principle`;
-- `character_virtue`;
-- `character_boundary`;
-- `role_character_profile`;
-- `character_decision_rule`;
-- `reflection_protocol`;
-- `character_fixture`;
-- `violation_pattern`;
-- `correction_loop`;
-- `governance_gate`;
-- `evidence`.
-
-## Relation Types
-
-Initial allowed relation types:
-
-- `defines_principle`;
-- `promotes_virtue`;
-- `sets_character_boundary`;
-- `specializes_character`;
-- `resolves_character_conflict`;
-- `uses_reflection_protocol`;
-- `tests_character`;
-- `describes_violation_of`;
-- `corrects_violation`;
-- `updates_character`;
-- `evidences_character`;
-- `governs_role`;
-- `governs_employee`;
-- `requires_escalation_to`;
-- `governs`;
-- `related_to`.
-
-## Governance Gates
-
-Initial gates:
-
-- `human_review_before_canonical_write`;
-- `approval_before_external_action`;
-- `feedback_learning_before_behavior_update`;
-- `public_safety_before_release`;
-- `scientific_claim_before_publication`.
-
-## Runtime Boundary
-
-The profile models character state and review boundaries. It does not make
-generated context an authorization source.
-
-Use this separation:
-
-```text
-canonical character graph
--> generated character context
--> runtime reflection
--> proposed answer or action
--> policy or action gate
--> output or execution
--> reviewed result
--> feedback
--> correction proposal
--> owner-approved canonical update
-```
-
-## Semantic Validation
-
-The reference validator applies additional fail-closed checks for this profile:
-relation directions must match the Character Layer contract, generated context
-or evidence cannot authorize action, feedback cannot automatically update
-canonical character state, `role_character_profile` cannot grant runtime/tool
-permission, and `correction_loop` must preserve owner or human review before
-canonical character updates.
-
-## Minimal Useful Package
-
-A Level 1 character-layer package should include:
-
-- one `character_constitution`;
-- several `character_principle` objects;
-- at least one `character_virtue`;
-- at least one `character_boundary`;
-- one `reflection_protocol`;
-- one `role_character_profile`;
-- one `character_fixture`;
-- one `violation_pattern`;
-- one `correction_loop`;
-- one `governance_gate`;
-- evidence objects or source records for the public boundary.
-
-## Current Limitations
-
-The profile does not yet standardize:
-
-- provider-specific behavior controls;
-- runtime policy enforcement engines;
-- human trust or calibration measurement;
-- cross-model evaluation;
-- product UI requirements;
-- private operational constitutions.
-
-## Example
-
-Minimal synthetic fixture:
-
-`examples/character-layer-minimal/`

package/profiles/character-layer/profile.json

@@ -1,46 +0,0 @@
-{
-  "id": "profile.character_layer",
-  "name": "Character Layer",
-  "version": "0.1.0",
-  "description": "Profile for modeling model-independent AI character, principles, character virtues, character boundaries, reflection protocols, fixtures, violations and correction loops.",
-  "allowed_object_kinds": [
-    "character_constitution",
-    "character_principle",
-    "character_virtue",
-    "character_boundary",
-    "role_character_profile",
-    "character_decision_rule",
-    "reflection_protocol",
-    "character_fixture",
-    "violation_pattern",
-    "correction_loop",
-    "governance_gate",
-    "evidence"
-  ],
-  "allowed_relation_types": [
-    "defines_principle",
-    "promotes_virtue",
-    "sets_character_boundary",
-    "specializes_character",
-    "resolves_character_conflict",
-    "uses_reflection_protocol",
-    "tests_character",
-    "describes_violation_of",
-    "corrects_violation",
-    "updates_character",
-    "evidences_character",
-    "governs_role",
-    "governs_employee",
-    "requires_escalation_to",
-    "governs",
-    "related_to"
-  ],
-  "default_readiness": "draft",
-  "governance_gates": [
-    "human_review_before_canonical_write",
-    "approval_before_external_action",
-    "feedback_learning_before_behavior_update",
-    "public_safety_before_release",
-    "scientific_claim_before_publication"
-  ]
-}

package/profiles/implementation-control/README.md

@@ -1,174 +0,0 @@
-# Implementation Control Profile
-
-Status: 1.0 release-candidate profile
-
-## Purpose
-
-The implementation-control profile adapts Mirai Graph to governed implementation
-workflows where generated context, human review, evidence, proposals and gates
-must be separated from canonical updates and executed actions.
-
-It is the profile to use when the hard question is not "what are the project
-tasks?" but "is this work allowed to move from knowledge or planning into
-bounded execution, implementation state, release readiness or canonical graph
-change?"
-
-It is useful when a project needs to coordinate:
-
-- implementation baselines;
-- generated human projections;
-- semantic reviews;
-- workflow batches;
-- implementation cycles;
-- technology contracts and technology quality feedback;
-- graph DNA alignment;
-- source boundary contracts;
-- work state machines;
-- recovery records;
-- risk controls;
-- multi-agent coordination contracts;
-- evidence packs;
-- graph sync proposals;
-- launch gates;
-- approval gates;
-- controlled canonical updates;
-- drift checks;
-- continuous-improvement items.
-
-## Core Pattern
-
-```text
-baseline
--> projection view
--> semantic review
--> launch gate
--> workflow batch
--> evidence pack
--> technology quality feedback
--> sync proposal
--> approval gate
--> controlled update
--> drift check
--> improvement item
-```
-
-`ready_to_execute` and `ready_to_code` are readiness states. They are not the
-same as `executed`, `implemented`, `evidence_ready` or `release_ready`.
-
-## Object Kinds
-
-Initial allowed object kinds:
-
-- `implementation_baseline`;
-- `projection_view`;
-- `semantic_review`;
-- `workflow_batch`;
-- `implementation_cycle`;
-- `technology_contract`;
-- `technology_quality_feedback`;
-- `quality_finding`;
-- `graph_dna`;
-- `component_dna`;
-- `dna_alignment`;
-- `source_boundary_contract`;
-- `source_boundary`;
-- `work_state_machine`;
-- `work_state`;
-- `recovery_record`;
-- `risk_control`;
-- `agent_reservation`;
-- `coordination_contract`;
-- `evidence_pack`;
-- `sync_proposal`;
-- `launch_gate`;
-- `approval_gate`;
-- `controlled_update`;
-- `implementation_state`;
-- `drift_check`;
-- `validator`;
-- `risk`;
-- `blocker`;
-- `review`;
-- `release_gate`;
-- `kaizen_item`;
-- `evidence`.
-
-## Relation Types
-
-Initial allowed relation types:
-
-- `derives_projection`;
-- `reviews_projection`;
-- `produces_evidence`;
-- `proposes_update`;
-- `requires_gate`;
-- `launches_batch`;
-- `requires_launch_record`;
-- `checks_transition`;
-- `checks_conformance_to`;
-- `classifies`;
-- `routes_to`;
-- `requires_technology_feedback`;
-- `requires_kaizen_closure`;
-- `approves_update`;
-- `updates_baseline`;
-- `checks_drift`;
-- `validates_cycle`;
-- `progresses_to`;
-- `promotes_feedback`;
-- `aligns_with`;
-- `owns_scope`;
-- `excludes_scope`;
-- `defines_boundary`;
-- `transitions_to`;
-- `resumes_from`;
-- `controls_risk`;
-- `reserves_scope`;
-- `coordinates_with`;
-- `blocks`;
-- `mitigates`;
-- `records_state`;
-- `requires_review`;
-- `requires_release_gate`;
-- `improves_process`;
-- `evidences`;
-- `related_to`.
-
-## Governance Gates
-
-Initial gates:
-
-- `semantic_review_before_sync_proposal`;
-- `evidence_pack_before_approval`;
-- `launch_gate_before_work_batch`;
-- `approval_before_canonical_update`;
-- `drift_check_before_state_promotion`;
-- `technology_quality_feedback_before_acceptance`;
-- `public_safety_before_public_transfer`;
-- `no_generated_context_as_authorization`;
-- `no_feedback_as_automatic_update`.
-
-## Relationship To Project Management
-
-Use `project-management` for ordinary project goals, tasks, risks, milestones
-and stakeholder coordination.
-
-Use `implementation-control` when the critical question is whether a proposed
-implementation or graph update is sufficiently evidenced, reviewed and approved
-to affect canonical state.
-
-In short: `project-management` coordinates work; `implementation-control`
-governs movement from plans and generated context into bounded action,
-evidence, approved updates and process learning.
-
-The shared [Project Technology](../../standard/project-technology.md) extension
-supplies inventory, task context and exact accepted-target verification. It
-does not replace this profile's launch, transition and evidence rules.
-
-## Public Example
-
-Executable example:
-
-```text
-examples/implementation-control-minimal/
-```