mirai-graph 1.3.0 → 2.1.0

package/standard/graph-embryo.md

@@ -1,69 +0,0 @@
-# Mirai Graph Embryo
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-A Graph Embryo is the first candidate graph state generated from a Graph Seed.
-
-It is reviewable and disposable until accepted. It should be small enough for
-human review and structured enough to show the likely growth direction.
-
-## Definition
-
-A Graph Embryo contains candidate graph elements before canonical write:
-
-- candidate objects;
-- candidate relations;
-- uncertain objects;
-- missing evidence;
-- rejected or deferred candidates;
-- review questions;
-- growth-gap notes.
-
-## Relationship To Canonical State
-
-The embryo is not canonical state.
-
-Flow:
-
-```text
-Graph Seed -> Graph Embryo -> Review -> Accepted Canonical Graph State
-```
-
-Only reviewed and accepted candidates should move into canonical graph state.
-
-## Minimum Embryo Metadata
-
-```json
-{
-  "schema_version": "0.1.0",
-  "embryo_id": "embryo.example",
-  "seed_id": "seed.example",
-  "generated_at": "2026-05-28",
-  "candidate_objects": [],
-  "candidate_relations": [],
-  "uncertain_items": [],
-  "review_questions": [],
-  "stop_conditions_triggered": []
-}
-```
-
-## Review Questions
-
-A useful embryo should help reviewers answer:
-
-- Which candidate objects belong in the graph?
-- Which candidates should be rejected or deferred?
-- Which relations are unsupported?
-- Which evidence is missing?
-- Which stop conditions were triggered?
-- What should be accepted into canonical state?
-
-## Anti-Patterns
-
-- Treating the embryo as accepted graph state.
-- Generating too many candidates for practical review.
-- Hiding uncertain or rejected candidates.
-- Dropping evidence gaps.
-- Using embryo output as runtime context before review.

package/standard/graph-seed.md

@@ -1,122 +0,0 @@
-# Mirai Graph Seed
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-A Graph Seed is the controlled starting package for growing a Mirai Graph model.
-
-Complex systems should not start as large hand-authored graphs. They should
-start from a small seed that defines purpose, source boundaries, growth rules,
-review gates and stop conditions.
-
-## Definition
-
-A Graph Seed is a machine-readable growth contract.
-
-It answers:
-
-- what graph should exist;
-- why it should exist;
-- which profile shapes it;
-- what sources may be used;
-- which object and relation families are allowed;
-- what must be reviewed before canonical write;
-- when growth should stop.
-
-## Growth Flow
-
-```text
-graph seed
--> profile expansion
--> candidate extraction
--> graph embryo
--> review packet
--> canonical accept
--> generated indexes/context/reports
--> readiness score
--> seed evolution
-```
-
-## Minimum Seed Fields
-
-```json
-{
-  "schema_version": "0.1.0",
-  "seed_id": "seed.example",
-  "target_graph_id": "example.graph",
-  "purpose": "Why this graph should exist.",
-  "target_profile": "profile.software_specification",
-  "target_mode": "discovery",
-  "graph_dna": {
-    "purpose": "Parent DNA draft.",
-    "evolution_vector": "How the graph should develop.",
-    "non_negotiable_principles": []
-  },
-  "source_boundaries": {
-    "allowed_sources": [],
-    "excluded_sources": [],
-    "canonical_write_allowed": false
-  },
-  "growth_rules": {
-    "allowed_object_families": [],
-    "allowed_relation_families": [],
-    "max_initial_objects": 20,
-    "depth_mode": "light"
-  },
-  "review_gates": [
-    "human_review_before_canonical_write",
-    "validate_before_generated_context"
-  ],
-  "generated_views": [
-    "seed_preview",
-    "candidate_object_list",
-    "growth_gap_report"
-  ],
-  "stop_conditions": []
-}
-```
-
-## Target Modes
-
-Initial target modes:
-
-- `discovery`: understand a messy domain;
-- `canonical`: prepare reviewed canonical graph state;
-- `pilot`: support measured pilot work;
-- `controlled_runtime`: support bounded runtime use with fallback;
-- `production_runtime`: broad runtime use after repeated evidence.
-
-## Human Control Rule
-
-The user should not need to inspect the full graph first.
-
-The seed should produce controlled views:
-
-- seed summary;
-- candidate objects;
-- candidate relations;
-- evidence gaps;
-- risk view;
-- readiness view;
-- next-action view.
-
-## Stop Conditions
-
-Stop seed expansion when:
-
-- purpose is vague;
-- target profile is missing;
-- source boundaries are unclear;
-- candidate count exceeds growth budget;
-- relation families are invented ad hoc;
-- generated preview cannot explain why objects belong;
-- canonical write is requested before review.
-
-## Anti-Patterns
-
-- Starting with the whole organization as one graph.
-- Letting AI extraction write directly to canonical state.
-- Expanding sources beyond the seed boundary.
-- Treating a seed as the full graph.
-- Ignoring stop conditions because the generated output looks useful.

package/standard/hybrid-source-of-truth.md

@@ -1,91 +0,0 @@
-# Hybrid Source Of Truth
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Mirai Graph can act as the first machine-readable layer for routing, context,
-capability discovery, readiness, gates and evidence. That does not mean the
-graph replaces every original source.
-
-Hybrid Source Of Truth defines how a Mirai Graph implementation can use graph
-state for operational control while keeping domain source material authoritative
-for meaning, judgement and sensitive procedures.
-
-## Core Rule
-
-```text
-graph = routing, context, control, readiness and evidence layer
-raw source = authoritative methodology, judgement and sensitive rules
-```
-
-A generated graph view may select what to read first. It must not silently
-erase the authority of the source that created the meaning.
-
-## Source Classes
-
-A Mirai Graph implementation should classify sources before using them:
-
-- `canonical`: approved source material or canonical graph state;
-- `raw`: original source material that contains authoritative domain meaning;
-- `generated`: derived context, report, dashboard or proposal;
-- `evidence`: material used to support a claim or gate result;
-- `draft`: working material that may be useful but is not authoritative;
-- `deprecated`: material retained only for traceability.
-
-## Authority Boundary
-
-Canonical graph state may contain:
-
-- stable object identifiers;
-- typed relations;
-- readiness state;
-- evidence links;
-- governance gates;
-- adoption status;
-- runtime policy references;
-- generated view references.
-
-Raw sources remain authoritative for:
-
-- domain judgement;
-- long-form procedures;
-- sensitive runtime rules;
-- safety constraints;
-- legal, commercial or production-specific exceptions;
-- source-writing permission.
-
-Generated artifacts remain advisory unless an implementation explicitly accepts
-them through a governance gate.
-
-## Required Safeguards
-
-A Hybrid Source Of Truth implementation should preserve these safeguards:
-
-- generated context is not authorization;
-- a runtime decision is not an executed action;
-- feedback is not a canonical update;
-- profile conformance is not semantic preservation;
-- semantic preservation is not proof of effectiveness;
-- effectiveness is not runtime safety.
-
-## Graph-First Does Not Mean Graph-Only
-
-Graph-first operation is allowed only when the graph is used as the first
-navigation layer for a bounded task. It still requires fallback to raw sources
-when coverage is missing, the task is sensitive, or the runtime policy requires
-original source review.
-
-Graph-only runtime should be treated as unsafe by default.
-
-## Limited Claim
-
-Passing a Hybrid Source Of Truth gate supports this limited claim:
-
-```text
-The Mirai Graph implementation preserves the authority boundary between graph
-state, generated context and raw domain sources for the declared scope.
-```
-
-It does not prove semantic completeness, operational effectiveness or runtime
-safety.

package/standard/implementation-control-cycles.md

@@ -1,194 +0,0 @@
-# Implementation Control Cycles
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Implementation-control cycles define repeatable, governed work scenarios inside
-Mirai Graph. They make project movement explicit without treating generated
-context, feedback, evidence or runtime output as automatic permission to change
-canonical state.
-
-## Core Principle
-
-```text
-cycle = repeatable governed scenario
-gate = readiness, safety or approval check
-evidence = trace supporting a claim
-proposal = reviewable request for canonical change
-controlled update = approved canonical change
-```
-
-Cycles must define inputs, outputs, stages, gates, validators, recovery
-behavior, repeat condition and promotion path.
-
-`stages` describe the human-readable projection of work. Executable process
-movement must use state-machine fields such as `executable_states`,
-`state_mapping` and `state_machine_id`. Narrative stages are not enough to
-authorize state transitions.
-
-Cycle transitions define when one cycle may hand off to another. A cycle does
-not silently start the next cycle. It produces a transition decision with
-required outputs, required gates and a handoff artifact.
-
-## Standard Cycles
-
-### `human_projection_feedback`
-
-Purpose: create a human-readable projection from a graph baseline, review it
-for semantic gaps and convert accepted findings into explicit graph proposals.
-
-Typical stages:
-
-```text
-extract_baseline_context
--> generate_projection
--> semantic_review
--> classify_findings
--> create_sync_proposal
--> approval_gate
--> regenerate_projection
-```
-
-Promotion path: accepted review findings become sync proposals. The projection
-itself does not become canonical truth.
-
-### `implementation_planning`
-
-Purpose: convert a reviewed baseline, feature scope or project goal into a
-bounded work plan with owners, gates, allowed scope and evidence requirements.
-
-Promotion path: accepted plans create launch-ready batches, not executed work.
-
-### `bounded_work_batch`
-
-Purpose: execute only the scope approved by a launch gate.
-
-Promotion path: work output becomes evidence and possibly a sync proposal. It
-does not directly update canonical graph state.
-
-### `review_and_evidence`
-
-Purpose: verify implementation evidence, semantic acceptance, drift and
-proposal readiness before approval.
-
-Promotion path: accepted evidence may support approval, but evidence is not
-approval by itself.
-
-Significant work should also include technology quality feedback: a separate
-check that the declared method, process or technology was actually followed.
-Passing tests and complete evidence are not enough when the workflow itself
-drifted from the accepted technology.
-
-### `release_or_publish`
-
-Purpose: decide whether an artifact, package or public output is ready for
-release or publication.
-
-Promotion path: release readiness requires explicit gates and public-safety
-review when the artifact becomes public.
-
-### `runtime_feedback`
-
-Purpose: capture operational, user or runtime feedback and convert it into
-reviewable improvement items or graph proposals.
-
-Promotion path: feedback becomes a proposal or Kaizen item. It must not mutate
-canonical behavior automatically.
-
-### `kaizen_improvement`
-
-Purpose: evaluate completed cycles and convert lessons, regressions and
-improvement opportunities into controlled artifact, graph, process, validator,
-tooling or backlog changes.
-
-Typical stages:
-
-```text
-evaluate_result
--> classify_improvement
--> check_impact_and_risk
--> decide_accept_or_defer
--> validate_improvement_path
--> choose_next_transition
-```
-
-Kaizen is a meta-cycle. It is not a replacement for `runtime_feedback`:
-
-- `runtime_feedback` captures operational, user or runtime evidence;
-- `kaizen_improvement` reviews the quality of completed work and the quality
-  of the process that produced it.
-
-Kaizen blocks the next transition only for safety, quality, DNA alignment or
-critical drift findings. Other improvements are accepted locally or deferred to
-follow-up proposals.
-
-## Cycle Transitions
-
-The public cycle pattern is:
-
-```text
-cycle completed
--> transition decision
--> kaizen review
--> classified improvement
--> blocking/non-blocking decision
--> next governed cycle
-```
-
-Each transition must define:
-
-- source cycle;
-- target cycle;
-- trigger;
-- required outputs;
-- required gates;
-- handoff artifact;
-- owner;
-- failure behavior;
-- recovery behavior.
-
-Default rule: if a transition gate does not pass, the next cycle is not
-available. The source cycle must repeat, record a blocker or produce a handoff
-that explains the missing condition.
-
-Kaizen default rule: every major cycle records whether improvement was needed.
-If improvement is needed, it is classified before the next transition is
-chosen.
-
-Recommended Kaizen finding taxonomy:
-
-- `artifact_improvement`;
-- `graph_spec_improvement`;
-- `process_improvement`;
-- `validator_improvement`;
-- `tooling_improvement`;
-- `dna_alignment_issue`;
-- `quality_regression`;
-- `safety_regression`;
-- `critical_drift`;
-- `user_value_gap`.
-
-## Required Boundaries
-
-- `ready_to_execute` is not `executed`.
-- `ready_to_code` is not `implemented`.
-- Generated projection is not source of truth.
-- Evidence is not approval.
-- Passing tests are not acceptance.
-- Technology quality feedback supports acceptance; it is not acceptance by
-  itself.
-- Feedback is not canonical update.
-- Proposal is not controlled update.
-- Runtime decision is not executed action.
-
-## Schema
-
-Machine-readable cycle results can be validated with:
-
-```text
-schemas/implementation-control-cycle.schema.json
-```
-
-The schema validates public shape and traceability. It does not prove semantic
-truth, operational effectiveness or real-world safety.

package/standard/implementation-control.md

@@ -1,102 +0,0 @@
-# Implementation Control
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Implementation control defines how Mirai Graph represents governed movement from
-project knowledge to implementation action without confusing generated context,
-feedback, proposals, approvals and canonical state.
-
-## Control Loop
-
-```text
-implementation baseline
--> generated projection view
--> semantic review
--> launch gate
--> workflow batch
--> evidence pack
--> sync proposal
--> approval gate
--> controlled update
--> drift check
--> updated baseline
--> improvement item
-```
-
-## Rules
-
-- Generated context is not authorization.
-- Human feedback is not an automatic canonical update.
-- Implementation evidence is not proof of approval.
-- A sync proposal must remain separate from an approved update.
-- Canonical updates require explicit governance gates.
-- `ready_to_execute` and `ready_to_code` are not `executed` or `implemented`.
-- Bounded work batches require a launch gate before writes or runtime actions.
-- Implementation state promotion requires evidence and drift review.
-- Public transfer requires public-safety review and synthetic examples unless
-  the source material is already public.
-
-## Relationship To Project Management
-
-Use `project-management` for goals, tasks, milestones, stakeholder coordination,
-ordinary decisions and high-level risks.
-
-Use `implementation-control` when the work crosses a control boundary:
-generated context becomes a human projection, a plan becomes a bounded work
-batch, evidence becomes an approval candidate, or feedback becomes a proposal
-for canonical graph change.
-
-The implementation-control profile is therefore stricter than ordinary project
-management. It models authorization boundaries, evidence boundaries, drift
-checks and controlled updates.
-
-## Cycles
-
-Reusable implementation-control cycles are documented in:
-
-```text
-standard/implementation-control-cycles.md
-```
-
-## Launch Records
-
-Launch records are bounded authorization artifacts for executable work
-batches. They are documented in:
-
-```text
-standard/launch-record.md
-```
-
-A launch record is not implementation proof, release approval or a canonical
-update.
-
-## Process Control Contracts
-
-Executable process-control contracts bind cycles, state machines, launch-record
-policy, evidence, recovery, risk controls, validators and Kaizen closure. They
-are documented in:
-
-```text
-standard/process-control-contract.md
-```
-
-## Profile
-
-Machine-readable profile:
-
-```text
-profiles/implementation-control/profile.json
-```
-
-## Schema
-
-The initial loop schema is documented at:
-
-```text
-schemas/implementation-control-loop.schema.json
-```
-
-It validates the shape of a loop result, not the semantic truth of the
-implementation.

package/standard/launch-record.md

@@ -1,53 +0,0 @@
-# Launch Record
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-A launch record is a durable authorization boundary for a bounded work batch.
-It says what may be attempted, which state transition is being requested, what
-evidence must be produced and when the work must stop.
-
-It is not implementation proof, acceptance evidence, release approval or a
-canonical update.
-
-## Required Contract
-
-A launch record must define:
-
-- workflow id;
-- process model id;
-- cycle id;
-- current state and target state;
-- allowed and forbidden files or scopes;
-- allowed actions;
-- required gates;
-- required evidence;
-- stop conditions;
-- owner role;
-- user approval flag;
-- evidence references;
-- limitations.
-
-## Execution Boundary
-
-```text
-plan
--> launch record
--> bounded work
--> evidence
--> review
--> approval candidate
-```
-
-The launch record permits only the declared work. If scope, owner, state,
-evidence requirements or stop conditions change, the launch record must be
-updated or replaced before continuing.
-
-## Schema
-
-Machine-readable launch records can be validated with:
-
-```text
-schemas/launch-record.schema.json
-```