mirai-graph 1.3.0 → 2.1.0

package/standard/lifecycle-readiness.md

@@ -1,159 +0,0 @@
-# Mirai Graph Lifecycle And Readiness
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Lifecycle and readiness rules describe how Mirai Graph objects, relations,
-context packs and standard sections move from early ideas to accepted canonical
-state.
-
-Readiness is not the same as task status. It records whether a graph element is
-mature enough to be used as trusted context, implementation input or governance
-evidence.
-
-## Core Readiness Values
-
-### `draft`
-
-The element exists but is incomplete, unreviewed or exploratory.
-
-Use for:
-
-- early graph-seed objects;
-- unreviewed relations;
-- initial examples;
-- newly imported material.
-
-### `review_ready`
-
-The element is structured enough for review.
-
-Use for:
-
-- candidate objects with evidence;
-- candidate relations with clear source and target;
-- context packs prepared for human review;
-- standard sections ready for critique.
-
-### `accepted`
-
-The element has passed the relevant review or governance gate and may be used
-as canonical state.
-
-Use for:
-
-- stable objects;
-- approved relations;
-- accepted evidence records;
-- reviewed standard sections.
-
-### `blocked`
-
-The element cannot progress until a blocker is resolved.
-
-Use for:
-
-- missing evidence;
-- unresolved contradiction;
-- privacy or licensing issue;
-- governance approval requirement;
-- unsafe action boundary.
-
-### `deprecated`
-
-The element remains traceable but should not be used for new work.
-
-Use for:
-
-- superseded objects;
-- old relation types;
-- obsolete profiles;
-- retired context-pack rules.
-
-## Lifecycle Flow
-
-Typical flow:
-
-```text
-draft -> review_ready -> accepted
-draft -> blocked -> draft
-review_ready -> blocked -> review_ready
-accepted -> deprecated
-accepted -> blocked
-```
-
-An accepted element may become blocked if new evidence creates a serious
-conflict or governance issue.
-
-## Object Lifecycle
-
-An object may move to `review_ready` when it has:
-
-- stable `id`;
-- `kind`;
-- `title`;
-- `summary`;
-- readiness value;
-- profile;
-- evidence boundary or explicit reason why evidence is not yet available.
-
-An object may move to `accepted` when:
-
-- it has been reviewed for meaning;
-- its evidence is sufficient for the current use;
-- it does not duplicate another accepted object;
-- privacy and public-safety rules are satisfied.
-
-## Relation Lifecycle
-
-A relation may move to `review_ready` when it has:
-
-- stable `id`;
-- relation `type`;
-- existing `source` object;
-- existing `target` object;
-- evidence or explicit rationale;
-- directionality checked.
-
-A relation may move to `accepted` when:
-
-- source and target are correct;
-- relation type is appropriate;
-- direction is correct;
-- evidence is sufficient;
-- contradiction handling is complete.
-
-## Context-Pack Lifecycle
-
-A generated context pack starts as `draft` unless it is produced by an accepted
-and validated generation procedure.
-
-A context pack may be `accepted` only for a specific task, time and evidence
-boundary. It must not replace canonical graph state.
-
-## Governance Lifecycle
-
-Governance gates can block:
-
-- canonical updates;
-- public release;
-- generated context use;
-- automated action;
-- claims about validation or readiness.
-
-When a governance gate blocks progress, record:
-
-- blocked element;
-- reason;
-- owner or reviewer;
-- required evidence;
-- next review point.
-
-## Anti-Patterns
-
-- Treating `draft` graph elements as authoritative.
-- Using generated context as canonical state.
-- Marking elements `accepted` without evidence or review.
-- Hiding contradictions by deleting blocked elements.
-- Reusing a context pack outside its task boundary.

package/standard/multi-agent-coordination.md

@@ -1,50 +0,0 @@
-# Multi-Agent Coordination
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Multi-agent coordination defines how several humans, agents or services can
-work on one graph-governed system without duplicating ownership, overwriting
-canonical state or creating hidden coupling.
-
-## Coordination Principle
-
-Parallel work is allowed only when each worker has:
-
-- a reservation;
-- a bounded scope;
-- an execution branch or workspace;
-- allowed files or allowed actions;
-- evidence path;
-- proposal path;
-- coordinator ownership;
-- conflict-resolution rule.
-
-No worker should own canonical graph writes by default.
-
-## Coordination Objects
-
-- coordination contract;
-- work reservation;
-- branch or workspace reservation;
-- evidence pack;
-- sync proposal;
-- review result;
-- approval or release decision.
-
-## Locking Rules
-
-- one active owner per bounded execution scope;
-- no parallel canonical updates without coordinator review;
-- cross-scope changes require impact analysis before execution;
-- conflicting proposals are resolved by coordinator decision;
-- reservations must be releasable, supersedable or recoverable.
-
-## Schema
-
-Machine-readable coordination contracts can be validated with:
-
-```text
-schemas/multi-agent-coordination.schema.json
-```

package/standard/multi-source-quality-feedback.md

@@ -1,71 +0,0 @@
-# Multi-Source Quality Feedback
-
-Multi-Source Quality Feedback is a Mirai Graph pattern for combining quality signals from tests, validators, cockpit instruments, human review, runtime feedback, and Kaizen into one classified transition input.
-
-It exists because passing tests alone can miss process violations, semantic gaps, unsafe assumptions, and technology drift.
-
-## Pattern
-
-```text
-work evidence
--> source-specific feedback
--> normalized findings
--> classification
--> blocking decision
--> transition route
--> Kaizen or proposal path
-```
-
-## Sources
-
-Recommended feedback sources include:
-
-- automated tests;
-- static or schema validators;
-- process-transition validation;
-- technology quality feedback;
-- development cockpit signals;
-- feature implementation traceability;
-- human expert review;
-- runtime observations;
-- user or stakeholder feedback.
-
-Each source should declare evidence references and limitations. A source can support a decision, but no single source silently overrides the required gate.
-
-## Finding Classification
-
-Findings should be classified with reusable categories:
-
-- `accepted`;
-- `work_fix_required`;
-- `test_gap`;
-- `spec_gap`;
-- `graph_update_proposal`;
-- `process_improvement`;
-- `release_blocker`;
-- `security_blocker`;
-- `defer_with_reason`.
-
-Blocking findings stop the transition they block. Non-blocking findings must still declare a route: continue, fix, defer, proposal, or Kaizen.
-
-## Transition Use
-
-A multi-source feedback report should make the transition decision explicit:
-
-- `accepted_for_transition`;
-- `changes_requested`;
-- `blocked`;
-- `defer_with_reason`;
-- `proposal_required`.
-
-The report can calibrate a decision, but it is not a canonical update and does not replace approval.
-
-## Kaizen Use
-
-When feedback reveals a repeatable weakness in the work technology, it should route to Kaizen:
-
-```text
-finding -> classified improvement -> prevention mechanism -> next governed cycle
-```
-
-The prevention mechanism should be durable: checklist update, validator change, template improvement, reviewer instruction, gate refinement, or documented limitation.

package/standard/object-model.md

@@ -1,167 +0,0 @@
-# Mirai Graph Object Model
-
-Status: 1.1 stable standard section
-
-## Purpose
-
-The object model defines the stable entities that a Mirai Graph implementation
-tracks inside canonical graph state.
-
-Objects are not free-form notes. They are addressable units of system state
-that can be linked, evidenced, reviewed, matured and governed.
-
-## Object
-
-An object is a stable graph entity.
-
-Examples:
-
-- project;
-- product;
-- requirement;
-- feature;
-- decision;
-- risk;
-- task;
-- component;
-- policy;
-- stakeholder;
-- evidence item;
-- governance gate.
-
-## Minimum Fields
-
-A Mirai Graph object should include:
-
-```json
-{
-  "id": "object.unique_id",
-  "kind": "feature",
-  "title": "Short human-readable title",
-  "summary": "Brief description of the object",
-  "readiness": "draft",
-  "evidence": [],
-  "profile": "core",
-  "created_at": "2026-05-28",
-  "updated_at": "2026-05-28"
-}
-```
-
-## Field Semantics
-
-### `id`
-
-A stable unique identifier. The identifier should remain stable across file
-moves, generated context packs and implementation exports.
-
-### `kind`
-
-The object category. Core kinds should be standardized; profiles may add
-domain-specific kinds.
-
-### `title`
-
-A short label for humans.
-
-### `summary`
-
-A concise explanation of what the object represents.
-
-### `readiness`
-
-The maturity state of the object. Early values may include:
-
-- `draft`;
-- `review_ready`;
-- `accepted`;
-- `blocked`;
-- `deprecated`.
-
-### `evidence`
-
-References to evidence records or source materials. Evidence links should not
-embed private data directly in public examples.
-
-### `profile`
-
-The profile that defines or specializes the object. The default profile is
-`core`.
-
-### `created_at` And `updated_at`
-
-Dates or timestamps used for lifecycle tracking.
-
-## Core Object Kinds
-
-Initial core kinds:
-
-- `system`;
-- `goal`;
-- `requirement`;
-- `feature`;
-- `decision`;
-- `risk`;
-- `task`;
-- `component`;
-- `evidence`;
-- `context_pack`;
-- `governance_gate`;
-- `profile`;
-- `owner`, `role`;
-- `capability`, `process`;
-- `resource`, `source`;
-- `check`, `gate`, `constraint`;
-- `access_requirement`.
-- `project_dna`, `stage`, `batch`;
-- `method`, `lesson`, `regression_case`.
-
-The additional domain-neutral kinds support Project Technology traversal. A
-consumer may display them using its own vocabulary without changing their
-canonical meaning.
-
-Portable continuity uses these existing domain-neutral kinds. A verified task
-result is evidence plus a regression case; an inferred reusable method remains
-a lesson proposal until its promotion rule is satisfied.
-
-## Object Boundary Rules
-
-An object should be created when the item needs at least one of:
-
-- stable identity;
-- relations to other objects;
-- evidence;
-- readiness tracking;
-- governance control;
-- generated context inclusion;
-- reuse across tasks.
-
-An object should not be created for:
-
-- a one-off sentence with no reuse value;
-- raw private data copied without review;
-- generated AI text that has not been accepted into canonical state;
-- a vague idea with no boundary or owner.
-
-## Public Example
-
-```json
-{
-  "id": "feature.notify_after_approval",
-  "kind": "feature",
-  "title": "Notify after approval",
-  "summary": "Send a notification when a content item is approved.",
-  "readiness": "draft",
-  "evidence": ["source.content_workflow"],
-  "profile": "software_specification",
-  "created_at": "2026-05-28",
-  "updated_at": "2026-05-28"
-}
-```
-
-## Open Questions
-
-- Should `owner`, `status` and `readiness` be separate fields?
-- Should evidence be modeled as first-class objects only, or also as inline
-  references?
-- Which object kinds belong to `core` and which belong to profiles?
-- Should timestamps be ISO dates or full date-time strings?

package/standard/organization-governance.md

@@ -1,83 +0,0 @@
-# Organization Governance
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Organization governance extends Mirai Graph from project-level coordination to
-organization-level control. It describes how mission, strategy, portfolios,
-departments, policies, decision rights, risks, metrics, feedback and Kaizen can
-be connected without turning the graph into an unapproved command system.
-
-## Model
-
-```text
-mission
--> strategy
--> portfolio
--> department/program/project
--> policy and decision rights
--> risk controls
--> evidence and metrics
--> feedback
--> kaizen proposal
--> governed update
-```
-
-The graph is the coordination surface. It records dependencies, boundaries and
-evidence. It does not itself authorize organizational action.
-
-## Core Concepts
-
-- `mission`: durable reason for the organization to exist.
-- `strategy`: selected direction for allocating attention and resources.
-- `portfolio`: grouped initiatives, products, programs or projects.
-- `department`: accountable organizational unit.
-- `decision_right`: explicit owner of a decision class.
-- `policy`: rule or constraint that governs decisions and actions.
-- `risk`: possible organizational failure mode.
-- `control`: preventive, detective or corrective measure.
-- `metric`: signal used to review progress or risk.
-- `feedback`: observed response from operations, users, teams or environment.
-- `kaizen_item`: proposed process or governance improvement.
-
-## Required Boundaries
-
-Organization-governance graphs must preserve these boundaries:
-
-- generated context is not canonical organizational state;
-- evidence is not authorization;
-- feedback is not an automatic policy update;
-- readiness is not execution;
-- decision rights must be explicit before policy or portfolio changes;
-- high-impact changes require evidence and owner approval.
-
-## Minimum Gates
-
-- strategy alignment before portfolio change;
-- decision-right review before policy change;
-- risk-control review before cross-department action;
-- evidence review before governance decision;
-- Kaizen review before process promotion.
-
-## Use Cases
-
-- align projects with organization strategy;
-- show which department owns which capability or policy;
-- make decision rights and escalation paths explicit;
-- connect risks to controls and evidence;
-- route feedback into reviewed Kaizen items;
-- prepare organization-level status or governance context packs.
-
-## Non-Goals
-
-This alpha section is not:
-
-- a legal governance framework;
-- a replacement for corporate bylaws, public law or audit requirements;
-- proof that Mirai Graph can govern a country-scale system;
-- an autonomous management system.
-
-## Example
-
-See [Organization Governance Minimal](../examples/organization-governance-minimal/README.md).

package/standard/process-control-contract.md

@@ -1,53 +0,0 @@
-# Process Control Contract
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-A process-control contract binds implementation-control cycles to executable
-state machines, launch-record policy, evidence requirements, recovery behavior,
-risk controls, validators and Kaizen policy.
-
-It is the public Mirai Graph bridge between standards and fail-closed process
-validation.
-
-## Required Contract
-
-A process-control contract must define:
-
-- process id;
-- cycle id;
-- state machine id;
-- launch-record policy;
-- evidence requirements;
-- recovery behavior;
-- risk controls;
-- validators;
-- Kaizen policy;
-- technology quality feedback policy when significant work may move into
-  acceptance, approval or release states;
-- evidence references;
-- limitations.
-
-## Boundary
-
-The contract validates process movement. It must not execute destructive
-actions, grant release approval, perform canonical updates or treat generated
-context as authorization.
-
-Tests and evidence do not prove that the declared technology was followed. For
-significant work, the contract should require a technology quality feedback
-gate before transitions such as `review_ready`, `accepted`, `approved` or
-`released`.
-
-Technology quality feedback classifies process and work findings. It supports
-transition decisions, but it does not replace owner approval or canonical
-promotion.
-
-## Schema
-
-Machine-readable contracts can be validated with:
-
-```text
-schemas/process-control-contract.schema.json
-```