diff --git a/visualization/diagramascode/2x-aC/term.md b/visualization/diagramascode/2x-aC/term.md
index e5e9389d..172d5970 100644
--- a/visualization/diagramascode/2x-aC/term.md
+++ b/visualization/diagramascode/2x-aC/term.md
@@ -18,7 +18,7 @@
 Это к тому, что код (скрипт) - таблица или иной формализм для построения схемы - все это DaC \ 1х-aC. 
 Также, часто вместо схемы достаточно построить граф, и это будет "Граф как код". 
 
-### 2 Mining
+##### 2 Mining
 Как было сказано [Проблемы EA и BPM - схожие](https://habr.com/ru/articles/1009402/comments/#comment_29658294)  
 Та же самая проблема, когда «as is» отличается от «as-really-is», см. [Инструментальный Цифровой двойник](https://habr.com/ru/articles/927360/)
 
@@ -33,7 +33,9 @@
 2х-aC = 1х-aC + Autodiscover,  
 т.е. классический DaC + какая-либо технология класса «as-really-is».
 
-Однако не нужно путать это с "обратной технологией", когда по схеме генерится код, например, как в исполняемом BPMN (BPMN-engine)
+Если mining - это как бы "обратная разработка", то варинат "прямой разработки" класса 2х-aC, это когда по схеме генерится код, например, как в исполняемом BPMN (BPMN-engine, Camunda, Activiti, jBPM, Runa). Да, и там по схеме генерится только часть кода (нет пока реального "no-code"), поэтому для "архитктура как код" класса 2х-aC вполне достаточно генерации скелета кода, классов и т.п. Кстати это в 2000 году делал ARIS из нотации EPC (генерировал скелет кода на С).  
+
+Таким образом, 2х-aC в версии "прямая разработка" - это MBSD, где модель процесса (архитектуры) является активным реальным артефактом, управляющим поведением программы, а не просто красивой картинкой в спецификации. В случае 2х-aC в версии "обратная разработка" - это mining \ Autodiscover. В обоих случаях - это как правило "графика" с промежуточным скриптовым представлением (dot\plantUML или даже RDF\OWL) или таблицей. 
 
 ### link
 Архитектура как код - это не про визуализацию нарисованной модели,