Vedic Mindset 2

आर्ष अर्थसिद्धि पद्धति : Implementation page

भूमिका : इस दूसरे पृष्ठ का प्रयोजन

यह दूसरा पृष्ठ पहले पृष्ठ में स्थापित सिद्धान्तों को actual implementation में उतारने के लिये है। यहाँ उद्देश्य दार्शनिक वाद-विवाद नहीं, बल्कि एक ऐसे implementable package की क्रमबद्ध रचना है जिसे अनुसन्धान-दल मिलकर विकसित कर सके। इस कारण यहाँ prose का रूप scientific paper की शैली के अधिक निकट रखा गया है: परिभाषाएँ स्पष्ट होंगी, चरण क्रमबद्ध होंगे, और प्रत्येक technical term का संक्षिप्त अर्थ सामने रखा जायेगा।

इस पृष्ठ में बार-बार आनेवाले technical शब्द

Canonical Store

वह database layer जहाँ structured truth versioned और reviewed रूप में रखी जाती है।

Graph Store

वह layer जहाँ concepts, passages, relations, और clusters traversal तथा neighborhood inspection के लिये रखे जाते हैं।

Review Queue

उन semantic objects की क्रमबद्ध सूची जिन्हें human review की आवश्यकता है।

Promotion

किसी branch को comparison और benchmark के बाद higher status देना।

Rollback

किसी previously promoted branch से सुरक्षित रूप से पूर्व अवस्था में लौटना।

Runtime Query Flow

actual query आने पर system के modules किस क्रम से चलेंगे, उसका स्पष्ट विधान।

Python implementation blueprint

actual folder structure, package selection, service breakdown, first scripts, और end-to-end कार्य-क्रम

भूमिका

अब हम उस चरण पर पहुँच गये हैं जहाँ सिद्धान्त को actual software-रूप देना है।
अब प्रश्न यह नहीं कि architecture कैसा होना चाहिए; अब प्रश्न यह है कि:

कौन-सा Python stack लिया जाये,
कौन-से packages प्रथम दिन से रखे जायें,
कौन-से modules पहले लिखे जायें,
कौन-सी files किस क्रम में बनें,
और पहली जीवित system किस क्रम में खड़ी हो।

मैं पहले ही स्पष्ट कह देता हूँ:

इस project के लिये एक विशाल monolithic codebase मत बनाइये।
पहले एक disciplined modular system बनाइये।

इस blueprint का ध्येय है:

code कम हो, पर सही दिशा में हो,
हर चरण testable हो,
हर branch traceable हो,
और आगे चलकर machine-learning जोड़ना सरल रहे।

पूर्वपक्ष

कौन-सा Python stack लेना चाहिए?

मेरे मत में project के लिये यह stack सबसे उपयुक्त है:

Python = main language
FastAPI = service layer और internal API layer
Pydantic = request/response validation और typed schemas
SQLAlchemy 2.0 style ORM = PostgreSQL access
Psycopg 3 = PostgreSQL driver
Alembic = schema migrations
Neo4j Python Driver = graph writes and graph queries
Uvicorn = API serving
pytest = tests

यह चयन मनमाना नहीं है।
FastAPI अपनी official tutorial में typed Python APIs के लिये structured path देता है, और bigger applications के लिये multi-file organization भी दिखाता है। SQLAlchemy की official docs 2.0 style querying और ORM/Core unified usage पर बल देती हैं। Psycopg 3 की official docs binary install, DB-API usage, row factories, pooling, और concurrent operations के विषय में स्पष्ट मार्गदर्शन देती हैं। Neo4j official Python driver docs connection और query execution के लिये सीधी विधि देती हैं। Pydantic official docs BaseModel और validators के माध्यम से typed data validation और JSON schema generation की सुविधा देती हैं। Alembic official docs migration environment और autogenerate workflow बताती हैं। pytest official docs test discovery, fixtures, parametrization, और configuration के लिये स्थिर मार्ग देती हैं।

क्यों यही stack?

FastAPI

यहाँ हमें external public API नहीं, पहले internal service API चाहिए।
अर्थात्:

source register करना,
normalization चलाना,
extraction pipeline trigger करना,
review queue खोलना,
benchmark run करना।

इसके लिये FastAPI उपयुक्त है क्योंकि typed endpoints, automatic docs, और larger multi-file application structure इसकी official docs में प्रथम श्रेणी के रूप में दिये गये हैं।

SQLAlchemy + Psycopg

क्योंकि canonical truth relational होगी।
SQLAlchemy 2.0 style querying, ORM mapping, और select()-based style इस project के लिये सुव्यवस्थित आधार देगा, और Psycopg 3 official driver के रूप में binary install, standard DB-API usage, row handling, transactions, और concurrency support देता है।

Neo4j driver

क्योंकि graph operational layer है, canonical truth नहीं।
Neo4j official Python driver docs connection, verify_connectivity(), और execute_query() आधारित usage स्पष्ट रूप से दिखाती हैं।

Pydantic

क्योंकि system में typed data contracts आवश्यक हैं।
Pydantic official docs BaseModel, validators, JSON Schema, और model-level validation देती हैं। यह request bodies, review payloads, benchmark payloads, तथा branch metadata के लिये अत्यन्त उपयोगी है।

Alembic

क्योंकि PostgreSQL schema जीवित रहेगा और बदलेगा।
Alembic official docs migration environment, init, revision scripts, autogenerate, और schema migration workflow का स्पष्ट मार्ग देती हैं।

pytest

क्योंकि बिना tests के यह project शीघ्र ही drift करेगा।
pytest official docs test running, fixtures, parametrization, configuration, और structured testing का पूर्ण ढाँचा देती हैं।

उत्तरपक्ष

अब कुछ सहज किन्तु अशुद्ध विकल्पों का निरसन आवश्यक है।

विकल्प १ — केवल notebooks

यह प्रारम्भिक प्रयोगों के लिये चल सकता है, पर main system के लिये नहीं।
Notebooks में:

hidden state रहता है,
branch traceability नहीं रहती,
tests ढीले हो जाते हैं,
rollback कठिन होता है।
विकल्प २ — केवल scripts, कोई API नहीं

यह भी दीर्घकाल में कठिनाई देगा।
क्योंकि:

review UI को structured service चाहिए,
benchmark runner को standard entry चाहिए,
graph export, queue creation, branch promotion — सबको reusable service चाहिए।
विकल्प ३ — पहले ML, बाद में structure

यह उल्टा क्रम है।
पहले foundation modules बनेंगे:

ingest
normalize
segment
extract
review
benchmark

फिर ML layer जुड़ेगी।

सन्धि

अब सम्यक् रूप यह है:

Python codebase को चार वलयों में बनाइये:
वलय १ — Core data layer

database models, config, migrations

वलय २ — Pipeline layer

ingestion, normalization, segmentation, extraction, graph export

वलय ३ — Service layer

FastAPI endpoints, review queues, benchmark API, branch API

वलय ४ — ML / experiment layer

embeddings, classifiers, rerankers, relation extractors, active learning

इसीसे discipline भी रहेगा और growth भी।

सन्धान — actual blueprint

अब मैं actual folder structure, file names, module boundaries, और first working sequence देता हूँ।

चरण १ — Project folder structure

(इन सभी पायथन स्क्रिप्ट फाइलों को सही पथ सहित डाउनलोड करने के लिंक इस वेबपृष्ठ के अन्त में दिये गये हैं ।)

मैं यह structure recommend करता हूँ:

corpus_brain/
pyproject.toml
README.md
.env.example

migrations/
alembic.ini

app/
init.py

core/
init.py
config.py
logging.py
constants.py
enums.py
paths.py

db/
init.py
base.py
session.py
models/
init.py
source.py
work.py
normalization.py
document.py
passage.py
entity.py
qualifier.py
operator.py
discourse.py
assertion.py
rule.py
review.py
benchmark.py
branch.py
deployment.py

repositories/
init.py
source_repo.py
passage_repo.py
entity_repo.py
assertion_repo.py
review_repo.py
benchmark_repo.py
branch_repo.py

schemas/
init.py
source.py
passage.py
entity.py
qualifier.py
operator.py
assertion.py
review.py
benchmark.py
branch.py

services/
init.py
ingest_service.py
normalize_service.py
segment_service.py
extract_entity_service.py
extract_qualifier_service.py
extract_operator_service.py
detect_form_service.py
assemble_assertion_service.py
assemble_rule_service.py
review_service.py
graph_export_service.py
benchmark_service.py
branch_service.py

pipelines/
init.py
ingest_pipeline.py
normalize_pipeline.py
segmentation_pipeline.py
extraction_pipeline.py
benchmark_pipeline.py

graph/
init.py
neo4j_client.py
graph_exporter.py
graph_queries.py

validation/
init.py
rdf_export.py
shacl_runner.py

api/
init.py
deps.py
routers/
init.py
sources.py
normalization.py
passages.py
extraction.py
review.py
graph.py
benchmarks.py
branches.py

ml/
init.py
embeddings/
init.py
embedder.py
classifiers/
init.py
passage_classifier.py
qualifier_target_model.py
operator_role_model.py
rerankers/
init.py
reranker.py
active_learning/
init.py
queue_builder.py
sampling.py

cli/
init.py
main.py

tests/
unit/
integration/
benchmark/
क्यों यह structure?

क्योंकि यह architecture को code में भी प्रतिबिम्बित करता है:

db = canonical truth
services = business logic
pipelines = long-running workflows
graph = Neo4j layer
validation = constitutional legality
api = controlled service entry
ml = later specialist growth

चरण २ — pyproject.toml में क्या रखें

Python package base modern होना चाहिए।
pyproject.toml रखें, requirements.txt सहायक रूप में बाद में चाहें तो रख सकते हैं।

Recommended top dependencies
fastapi
uvicorn
pydantic
sqlalchemy
psycopg[binary]
alembic
neo4j
pytest

Psycopg official docs विशेषतः pip install "psycopg[binary]" को quick start के लिये बताती हैं। FastAPI और Uvicorn official docs programmatic running और app serving का मार्ग देती हैं।

Optional later dependencies
httpx
rich
orjson
pandas
pyarrow
networkx
rdflib
pyshacl
sentence-transformers
torch

इन सबको प्रथम दिन से लेना आवश्यक नहीं।

चरण ३ — app/core/config.py

यह file पूरे project की केन्द्रीय configuration पढ़ेगी।

इसमें क्या हो?
database URLs
Neo4j URL and credentials
file paths
branch defaults
review queue sizes
benchmark directories
deployment mode
debug flags
क्यों?

क्योंकि hard-coded paths और secrets code में नहीं होने चाहिए।

Example fields
POSTGRES_URL
NEO4J_URI
NEO4J_USER
NEO4J_PASSWORD
RAW_DATA_DIR
NORMALIZED_DATA_DIR
DEFAULT_BRANCH
ACTIVE_BENCHMARK_VERSION

Pydantic BaseSettings style configuration यहाँ उपयोगी रहेगी क्योंकि official docs typed models and validation की शक्ति इसी लिये देती हैं।

चरण ४ — app/db/base.py और session.py

base.py

SQLAlchemy declarative base यहीं defined होगी।

session.py
engine creation
session factory
transactional helpers

SQLAlchemy official tutorial और ORM quickstart 2.0 style ORM use के लिये यही मार्ग सुझाते हैं। Psycopg 3 PostgreSQL driver के रूप में underlying connection देगा।

Rule

सारी database access repository/service layer से जाये, raw SQL scattered न हो।

चरण ५ — SQLAlchemy model files

हर मुख्य domain table के लिये अलग model file रखिये।
सब कुछ models.py में मत भरिये।

source.py

Source, SourceWorkLink

work.py

Work

normalization.py

NormalizationBranch

document.py

Document

passage.py

Passage

entity.py

Entity, EntityVariant, PassageEntityMention

qualifier.py

Qualifier, PassageQualifierMention

operator.py

Operator, PassageOperatorMention

discourse.py

DiscourseForm, PassageForm

assertion.py

Assertion, RuleAssertion

review.py

Review

benchmark.py

Benchmark, BenchmarkRun, ErrorRecord

branch.py

Branch

deployment.py

Deployment

क्यों?

क्योंकि यह domain boundaries स्पष्ट रखेगा।

चरण ६ — Alembic migrations

Alembic official docs कहती हैं कि migration environment application source code के साथ maintained रहना चाहिए, और init से एक migration environment बनता है। Autogenerate candidate migrations बना सकता है, किन्तु उन्हें blindly accept नहीं करना चाहिए।

Practical rule
Alembic init once
हर schema change → new migration
autogenerate use करें, पर human review करें
destructive migration बिना backup न करें
Migration policy
canonical tables पहले
experimental tables बाद में
ML experiment tables अलग namespace में रख सकते हैं

चरण ७ — Pydantic schemas

अब app/schemas/ की भूमिका समझिये।

SQLAlchemy models database representation हैं।
Pydantic schemas API contracts हैं।

Example schema files
source.py
SourceCreate
SourceRead
passage.py
PassageRead
PassageContextRead
entity.py
EntityProposal
EntityMentionRead
assertion.py
AssertionProposal
RuleProposal
review.py
ReviewDecisionIn
ReviewDecisionOut
benchmark.py
BenchmarkRunRequest
BenchmarkReportRead

Pydantic official docs models, validators, और model-level validation के लिये यही pattern देती हैं।

चरण ८ — Repository layer

अब repositories क्यों?

यदि services सीधे ORM queries लिखेंगी, तो:

code repetition बढ़ेगा,
testing कठिन होगी,
branch-specific filtering बिखर जायेगी।
Example repositories
source_repo.py
passage_repo.py
entity_repo.py
assertion_repo.py
review_repo.py
benchmark_repo.py
branch_repo.py
Example methods
passage_repo.py
get_passage_by_id
get_passage_window
list_passages_by_branch
save_passage_batch
review_repo.py
create_review_decision
list_review_queue
get_pending_conflicts
branch_repo.py
create_branch
set_branch_status
list_candidate_branches

चरण ९ — Service layer

यही project का वास्तविक business logic होगा।
यहीं “काम” होगा।

ingest_service.py
source register
raw path validate
checksum store
work link create
normalize_service.py
N0 → N1
N1 → N2
layout normalization
safe corrections only
segment_service.py
headings पहचानना
speaker markers अलग करना
verse segmentation
3-verse / 7-verse windows बनाना
extract_entity_service.py
lexicon lookup
span proposals
type proposals
extract_qualifier_service.py
qualifier lexicon
local target suggestions
extract_operator_service.py
operator hits
role suggestions
scope hints
detect_form_service.py
discourse-form rules
classifier hooks later
assemble_assertion_service.py
simple assertion assembly
assemble_rule_service.py
multi-condition rule assembly
review_service.py
queue generation
decision writeback
conflict escalation
graph_export_service.py
reviewed records → Neo4j export
benchmark_service.py
benchmark selection
run orchestration
result aggregation
branch_service.py
branch create
promotion checklist
rollback record

चरण १० — Pipeline layer

Services छोटे units हैं।
Pipelines longer flows हैं।

ingest_pipeline.py

source → raw preserve → manifest save

normalize_pipeline.py

source → N1 → N2 → branch records

segmentation_pipeline.py

normalized document → passages + windows

extraction_pipeline.py

passages → entity proposals → qualifier proposals → operator proposals → discourse forms → assertions → rules

benchmark_pipeline.py

branch → selected suites → report

क्यों?

क्योंकि pipeline repeatable unit है।
CLI और API दोनों इन्हें invoke कर सकते हैं।

चरण ११ — FastAPI routers

अब service layer को API से expose करना है।

routers/sources.py
register source
upload raw metadata
list sources
routers/normalization.py
run normalization
list branches
compare branches
routers/passages.py
get passage
get passage context
search passage by work/chapter
routers/extraction.py
run entity extraction
run qualifier extraction
run operator extraction
run assertion assembly
routers/review.py
get queue
review decision
batch decision
unresolved conflicts
routers/graph.py
export graph
get entity neighborhood
get doctrinal path
routers/benchmarks.py
run benchmark
list reports
regression summary
routers/branches.py
create branch
promote candidate
rollback
deployment status

FastAPI official docs bigger applications pattern के अनुसार routers द्वारा application को multi-file structure में रखना बहुत उचित है।

चरण १२ — main.py / Uvicorn entry

App का entrypoint बहुत सरल होना चाहिए।

app/api/main.py or app/main.py
FastAPI app create
routers include
metadata define
startup hooks
health check

Uvicorn official docs programmatic uvicorn.run() style दिखाती हैं, पर production में command-line launch भी रखा जा सकता है।

Example run command
uvicorn app.main:app —reload

Development के लिये पर्याप्त है।

चरण १३ — CLI layer

सब कुछ API से मत चलाइये।
Long-running jobs के लिये CLI भी बनाइये।

app/cli/main.py

यह Typer या argparse से बन सकता है। आरम्भ में argparse भी पर्याप्त है।

Commands
register-source
normalize
segment
extract
review-queue-build
export-graph
run-benchmarks
क्यों?

क्योंकि:

कुछ jobs API से चलाना अनावश्यक होगा,
serverless/offline mode चाहिए,
scheduled batch runs सरल होंगे।

चरण १४ — Neo4j client module

app/graph/neo4j_client.py

यहाँ:

driver initialize
verify_connectivity
query execution helpers
transaction helpers

Neo4j official docs GraphDatabase.driver(…), verify_connectivity() और execute_query() आधारित pattern दिखाती हैं।

Rule

Neo4j logic scattered न हो।
सारा access graph module के भीतर से हो।

चरण १५ — Graph exporter

app/graph/graph_exporter.py

यह module PostgreSQL से reviewed truth लेकर Neo4j में डालेगा।

Export क्रम
Work nodes
Chapter nodes
Passage nodes
Entity nodes
Qualifier nodes
Operator nodes
Assertion nodes
Rule nodes
edges
क्यों यह क्रम?

क्योंकि nodes पहले, relations बाद में।

Rule

only reviewed or constitutionally accepted items export हों
raw proposals नहीं।

चरण १६ — RDF / SHACL validation modules

app/validation/rdf_export.py

selected graph content का RDF export

app/validation/shacl_runner.py

SHACL shapes चलाना, pass/fail report बनाना

क्यों selected content?

क्योंकि पूरा graph हर बार RDF mirror करना भारी हो सकता है।
पहले constitutional subset validate करें:

top-level ontology trunks
legal edge types
reviewed assertion structures
branch candidate changes

चरण १७ — ML module boundaries

अब app/ml/ की भूमिका।

embeddings/embedder.py
passage embedding
batch processing
store vectors
classifiers/passage_classifier.py
passage labels
discourse-form support
classifiers/qualifier_target_model.py
qualifier attachment सहायता
classifiers/operator_role_model.py
operator role and scope सहायता
rerankers/reranker.py
query-passage reranking
active_learning/queue_builder.py
uncertainty-based sampling
disagreement queue
coverage queue
active_learning/sampling.py
selection strategies
Rule

ML modules never directly mutate canonical truth.
वे केवल proposals देंगे।

चरण १८ — Testing strategy

pytest official docs fixtures, parametrization, और test organization के लिये बहुत उपयुक्त हैं।

tests/unit/
config tests
normalization utility tests
lexicon matching tests
operator parser tests
tests/integration/
DB insert/retrieve
pipeline run tests
graph export tests
API tests
tests/benchmark/
benchmark runner correctness
regression comparisons
constitutional suite pass/fail logic
क्या पहले लिखना?

पहले unit tests लिखिये:

normalization
segmentation
entity extraction
assertion assembly

फिर integration tests जोड़िये।

चरण १९ — First five scripts you should actually write

अब मैं बहुत स्पष्ट क्रम देता हूँ।
अभी यही पाँच modules पहले लिखें।

Script 1 — ingest_pipeline.py

कार्य:

source manifest बनाना
raw file register करना
Script 2 — normalize_pipeline.py

कार्य:

N0 → N1
N1 → N2
Script 3 — segmentation_pipeline.py

कार्य:

headings, colophons, verses, windows बनाना
Script 4 — extract_entities.py (service or pipeline)

कार्य:

lexicon-based entity proposals
Script 5 — review_api.py

कार्य:

queue दिखाना
decision लिखना
क्यों यही पहले?

क्योंकि इनके बिना आगे का सब theoretical रहेगा।

चरण २० — First end-to-end milestone

मैं इस project का पहला यथार्थ milestone इस प्रकार रखूँगा:

Milestone M1
एक Garuḍa chapter ingest हो
उसका normalization branch बने
verse और 3-verse windows बनें
entity proposals आयें
qualifier/operator proposals आयें
review UI पर दिखें
कुछ reviewed assertions बने
Neo4j में export हो
एक benchmark run हो

यदि यह milestone पूरा हो गया, तो project वास्तव में जीवित हो चुका है।

चरण २१ — Z890 + dual RTX 5090 पर कौन-सा भाग कहाँ चले

CPU / RAM
FastAPI
PostgreSQL
Neo4j
normalization
segmentation
review UI
benchmark aggregation
GPU0
embedding generation
reranking
scholar-query support later
GPU1
classifier training
qualifier-target model
operator-role model
Practical note

Development के प्रारम्भिक 2–3 phases लगभग पूर्णतः CPU-centric होंगे।
GPU जल्दी मत जोड़िये।
पहले canonical structure खड़ा कीजिये।

चरण २२ — First environment setup

अब initial environment की practical सूची देता हूँ।

Step A

Windows host पर:

PostgreSQL
Neo4j Desktop या server
Python/WSL access
Step B

WSL Ubuntu में:

Python virtual environment
git repo
project folder
package install
Recommended install order
fastapi
uvicorn
pydantic
sqlalchemy
psycopg[binary]
alembic
neo4j
pytest

यह official docs के अनुकूल stable foundation देगा।

चरण २३ — Documentation discipline

Code लिखते समय ये files भी साथ-साथ बनाइये:

README.md
docs/architecture.md
docs/normalization_policy.md
docs/review_policy.md
docs/benchmark_policy.md
docs/branch_promotion.md
क्यों?

क्योंकि बाद में यही project की institutional memory बनेगी।

चरण २४ — What not to write first

आरम्भ में यह सब न लिखिये:

giant LLM integration
full text semantic search UI
public-facing polished website
auto graph neural learning
automatic ontology mutation engine
end-to-end autonomous retraining

ये सब बहुत बाद के चरण हैं।
पहले stable canonical pipeline बनाइये।

निष्कर्ष

अब project का actual Python blueprint स्पष्ट है।

FastAPI देगा internal service layer
Pydantic देगा typed schemas
SQLAlchemy + Psycopg देंगे canonical PostgreSQL layer
Alembic देगा schema evolution discipline
Neo4j driver देगा operational graph connectivity
pytest देगा testing backbone
modular folders देंगे दीर्घकालिक नियंत्रण

और build order यह होगा:

foundation
normalization
segmentation
extraction
review
assertions
graph export
benchmarks
branch discipline
ML integration later

यही सही क्रम है।
इसी क्रम से system robust बनेगी।

उत्कर्ष

अब तक की पूरी श्रृंखला को software-रूप में रखिये:

Amarakośa = महा-अर्थ-विन्यास
Primary corpus = जीवित constitutional order
PostgreSQL = स्मृति
Neo4j = संचार
FastAPI = क्रियापथ
Review = प्रमाण
Benchmark = परीक्षा
Branch law = विकास
SHACL = मर्यादा
Python modules = यन्त्र-देह

प्रथम actual working skeleton

Python code द्वारा project का आरम्भिक देह-निर्माण
Amarakośa-सम्मत complete knowledge retrieval system के लिये प्रथम कार्ययोग्य software-रूप

भूमिका

अब सिद्धान्त से सीधे code पर आते हैं।
किन्तु यहाँ एक correction पहले ही स्पष्ट कर देना आवश्यक है।

यह skeleton किसी narrow extraction engine का आरम्भिक रूप नहीं होगा।
यह न तो astrology-centered होगा, न ही केवल entity-detection centered।
इसका ध्येय है — एक ऐसा प्रथम जीवित software-ढाँचा देना जिस पर आगे चलकर पूरा constitutional complete knowledge retrieval system खड़ा हो सके।

अतः इस प्रथम skeleton का उद्देश्य यह नहीं कि एक ही चरण में पूरा project बन जाये।
इसका उद्देश्य केवल यह है कि:

project folder सचमुच बन जाये,
PostgreSQL से संपर्क हो जाये,
FastAPI app उठ खड़ी हो,
source register हो सके,
normalization branches बन सकें,
document और passage का मूल canonical ढाँचा उपस्थित हो,
lexeme, sense, concept, passage-role, और relation के लिये जगह पहले से तैयार हो,
पहला normalize_pipeline.py और segment_pipeline.py चल सके,
और scholar-facing complete retrieval architecture की नींव रखी जा सके।

यही वह प्रथम देह है जिस पर आगे:

lexeme extraction,
sense candidate generation,
corpus concept extraction,
passage-role detection,
concept relation building,
cluster suggestion,
review queue,
graph export,
retrieval grouping,
benchmark system,
branch law

सब जुड़ेंगे।

पूर्वपक्ष

इस प्रथम code-skeleton का लक्ष्य अत्यन्त स्पष्ट है।

प्रथम कार्ययोग्य लक्ष्य
GET /health चले
POST /sources/register चले
POST /normalization/branches/create चले
POST /documents/create-from-source चले
POST /pipelines/normalize-document चले
POST /pipelines/segment-document चले

और इसके साथ यह भी सुनिश्चित हो कि database-schema का direction सही हो।
अर्थात् आगे का स्वाभाविक विकास गलत data model की ओर न मुड़े।

जब यह सब चलने लगेगा, तब project केवल लेख या योजना नहीं रहेगा; वह actual software बन जायेगा।

सन्धान — actual folder structure

इस corrected direction में प्रारम्भिक folder structure इस प्रकार होना चाहिए:

इस corrected direction में प्रारम्भिक folder structure इस प्रकार होना चाहिए:

यहाँ ध्यान दें कि:

अभी lexeme.py, sense.py, concept.py, passage_role.py placeholders के रूप में रखे जा रहे हैं,
किन्तु first working skeleton में भी schema का direction पहले से सही रखा जा रहा है,
ताकि आगे जाकर फिर से architecture बदलनी न पड़े।

१. pyproject.toml
Path inside the full Python bundle: pyproject.toml
यह प्रथम file है।
अभी minimal dependencies ही रखें।
पहले system उठे; बाद में retrieval, embeddings, graph, benchmark आदि की अतिरिक्त dependencies जोड़ी जा सकती हैं।

२. .env.example

यह केवल template है।
Actual .env अलग बनेगी।

---

APP_NAME=Corpus Brain
APP_ENV=dev
APP_DEBUG=true

POSTGRES_URL=postgresql+psycopg://postgres:postgres@localhost:5432/corpus_brain
RAW_DATA_DIR=./data/raw
NORMALIZED_DATA_DIR=./data/normalized

NEO4J_URI=bolt://localhost:7687
NEO4J_USER=neo4j
NEO4J_PASSWORD=neo4jpassword

---

३. app/core/config.py

यह केन्द्रीय configuration file है= app/core/config.py

४. app/core/enums.py

अब enums को भी corrected center पर रखना चाहिए।
यहाँ अभी minimal set रखिये = app/core/enums.py

५. app/db/base.py
app/db/base.py

६. app/db/session.py
app/db/session.py

७. app/db/models/work.py
app/db/models/work.py

यहाँ macro_level0_cluster की जगह constitutional_trunk अधिक उपयुक्त है।

८. app/db/models/source.py
app/db/models/source.py

९. app/db/models/normalization.py
app/db/models/normalization.py
यही model आगे पूरे normalization family को संभालेगा।

१०. app/db/models/document.py
app/db/models/document.py

११. app/db/models/passage.py
app/db/models/passage.py
यह model corrected direction में भी central रहेगा।
यही first living retrieval unit होगी।

१२. अभी placeholder models कौन-से रहेंगे?

पहले actual working skeleton में हम इनकी पूर्ण logic नहीं लिखेंगे,
किन्तु folder structure और future direction अभी से स्थिर रखेंगे।

app/db/models/lexeme.py
surface text
normalized surface
script
lemma hint
app/db/models/sense.py
lexeme-linked sense
sense description
constitutional trunk
app/db/models/concept.py
canonical concept
concept type
constitutional trunk
app/db/models/passage_role.py
passage to role assignment

अभी इनका full code नहीं दिया जा रहा, क्योंकि first day goal केवल foundational skeleton उठाना है।
किन्तु architecture का corrected direction अभी से स्थापित कर दिया गया है।

१३. app/db/models/init.py =

from app.db.models.work import Work
from app.db.models.source import Source, SourceWorkLink
from app.db.models.normalization import NormalizationBranch
from app.db.models.document import Document
from app.db.models.passage import Passage

अभी केवल यही पर्याप्त है।

१४. app/schemas/source.py => Rename the following as "source.py" (its path and contents are different from the file of same name above):-
app/schemas/source.py

१५. app/schemas/normalization.py Rename the following as "normalization.py" (its path and contents are different from the file of same name above):-
app/schemas/normalization.py

१६. app/schemas/document.py Rename the following as "document.py" (its path and contents are different from the file of same name above):-
app/schemas/document.py

१७. app/schemas/passage.py Rename the following as "passage.py" (its path and contents are different from the file of same name above):-
app/schemas/passage.py

१८. app/repositories/source_repo.py
app/repositories/source_repo.py

२०. app/repositories/document_repo.py
app/repositories/document_repo.py

२१. app/repositories/passage_repo.py
app/repositories/passage_repo.py

२२. app/services/ingest_service.py
app/services/ingest_service.py

२३. app/services/normalization_service.py
app/services/normalization_service.py
यहाँ अभी केवल safe normalization रहेगी।
अर्थात् कोई destructive normalization नहीं।

२४. app/services/segmentation_service.py
app/services/segmentation_service.py
यह प्रथम सरल segmentation है।
अभी केवल verse और 3-verse windows बनायेंगे।
पर ध्यान रहे — यह आगे scholar-facing retrieval का आधार बनेगा, न कि केवल extraction सुविधा।

२५. app/api/deps.py
app/api/deps.py

२६. app/api/routers/health.py
app/api/routers/health.py

२७. app/api/routers/sources.py
app/api/routers/sources.py

२८. app/api/routers/normalization.py Rename the following as "normalization.py" (its path and contents are different from the file of same name above):-
app/api/routers/normalization.py

२९. app/api/routers/documents.py
app/api/routers/documents.py

३०. app/api/routers/pipelines.py
app/api/routers/pipelines.py

३१. app/main.py
app/main.py

३२. tests/test_health.py
tests/test_health.py

३३. प्रारम्भिक database creation script

---

from app.db.base import Base
from app.db.session import engine
from app.db.models import * # noqa

if name == "main":
Base.metadata.create_all(bind=engine)
print("Tables created.")

---

३४. Actual run order
अब corrected first-day run order देता हूँ।

Step 1 — environment बनाइये

---

python -m venv .venv
source .venv/bin/activate
pip install -e .

---

Windows PowerShell में activation अलग होगा।
WSL में ऊपर का रूप ठीक है।

Step 2 — .env बनाइये

.env.example से .env बनाइये।

Step 3 — PostgreSQL database बनाइये

Database:
corpus_brain

Step 4 — tables बनाइये
python scripts/create_tables.py

Step 5 — FastAPI चलाइये
uvicorn app.main:app —reload

अब browser में:

/docs
/health

देखिये।

Step 6 — first normalization branches बनाइये

पहले:

n0_raw_primary
n1_unicode_primary
n2_layout_primary
n3_segmented_primary

Example payload:

{
"branch_name": "n0_raw_primary",
"parent_branch_id": null,
"branch_level": "N0_RAW",
"description": "Initial raw branch",
"created_by": "vinay"
}

Step 7 — first source register कीजिये

अब example को Jyotiṣa-specific न रखकर corpus-generic रखना अधिक उचित है।

{
"title": "Amarakosha Typed Source",
"work_name": "Amarakosha",
"corpus_tier": "tier0",
"source_type": "typed_text",
"script": "devanagari",
"language": "sa",
"provenance": "manual typed source",
"source_url_or_note": "local typed file",
"checksum": null,
"raw_file_path": "/absolute/path/to/file.txt",
"notes": "initial constitutional source"
}

या किसी महाभारत / रामायण / पुराण source को इसी रूप में register कीजिये।

Step 8 — document create कीजिये

{
"source_id": 1,
"work_id": null,
"branch_id": 1,
"document_type": "text_document",
"title_in_text": "अथ नामलिङ्गानुशासनम्",
"chapter_marker_raw": "1",
"document_order": 1,
"text_raw": "यहाँ वास्तविक पाठ दीजिये"
}

Step 9 — normalization चलाइये
POST /pipelines/normalize-document?document_id=1&target_branch_id=2
Step 10 — segmentation चलाइये
POST /pipelines/segment-document?document_id=2&branch_id=3

अब database में:

verses
3-verse windows

उपस्थित होंगे।

३५. इस skeleton के बाद अगला सही code-चरण क्या होगा?

अब corrected direction में अगला code-चरण यह होगा:

Lexeme model
Sense model
CorpusConcept model
PassageRole model
lexeme extraction service
sense candidate service
concept extraction service
passage-role detection service
first review queue API
first graph-export preparation

ध्यान दें:
यहाँ अगला स्वाभाविक विकास अब Entity / Qualifier / Operator नहीं, बल्कि:

Lexeme / Sense / CorpusConcept / PassageRole

है।

३६. अभी क्या जान-बूझकर नहीं लिखा गया?

मैंने अभी इनको जान-बूझकर नहीं जोड़ा:

Alembic migration files
full review system
sense disambiguation logic
concept extraction logic
passage-role detector
graph export code
benchmark runner
ML layer
authentication
user roles
branch governance

क्यों?

क्योंकि अभी प्रथम लक्ष्य है:
system को उठाना।

पहले यह निश्चित हो:

folder structure स्थिर हो,
database उठे,
ingestion चले,
normalization branch बने,
segmentation चले,
passages canonical रूप में दिखें।

उसके बाद ही ऊपर के semantic layers जोड़ना उचित है।

निष्कर्ष

अब आपके project के लिये एक corrected, वास्तविक, चलने योग्य, प्रारम्भिक Python code skeleton उपस्थित है।
यह अभी सम्पूर्ण नहीं, किन्तु यह पर्याप्त है ताकि:

project folder स्थिर हो,
database schema उठे,
source register हो,
normalization branches बनें,
normalized document बने,
passages segment हों,
और FastAPI app सचमुच चल पड़े।

यही वह प्रथम देह है जिस पर आगे पूरा constitutional complete knowledge retrieval system खड़ा होगा।

उत्कर्ष

अब अगला code-चरण स्वाभाविक रूप से यह होगा:

Lexeme / Sense / CorpusConcept / PassageRole models + extraction services + review queue API

क्योंकि अब text database में आ चुका है;
अगला कार्य है:

surface forms को canonical inventory में लाना,
polysemy-aware sense candidates बनाना,
corpus concepts की प्रथम संरचना बनाना,
passages को ज्ञान-कार्य के अनुसार role देना,
और फिर reviewed conceptual graph की ओर बढ़ना।

यही corrected और उचित अगला चरण है।

Lexeme / Sense / CorpusConcept / PassageRole models + extraction services + review queue API

DiscourseForm + Assertion + RuleAssertion + first graph export

corpus को keyword-store से उठाकर प्रथम जीवित structured knowledge system में बदलने की वास्तविक विधि

भूमिका

अब तक project में यह आधार बन चुका है:

source register
normalization branches
document creation
passage segmentation
primary PostgreSQL memory
first review discipline
constitutional orientation

किन्तु इस अवस्था में corpus अभी भी मुख्यतः text-bank है।
हाँ, passages हैं; normalization है; branch history है; पर अभी system का ज्ञान-तन्त्र जीवित नहीं हुआ।

किसी भी complete knowledge retrieval system में एक निर्णायक मोड़ आता है।
वह मोड़ यह नहीं कि embeddings बन गयीं,
न ही यह कि graph database install हो गया।
वह मोड़ यह है कि text से निकला हुआ material इस रूप में व्यवस्थित होने लगे कि:

surface word और अर्थ-रूप अलग पहचाने जायें,
concept परिवार उभरें,
passage किस प्रकार का ज्ञान-कार्य कर रहा है, यह चिह्नित हो,
passages से typed assertions बनने लगें,
जटिल स्थितियों में rule assertions बनें,
और reviewed items से पहला living graph खड़ा हो सके।

यही इस section का कार्य है।

मैं प्रारम्भ में ही फिर स्पष्ट कर देता हूँ:

अभी भी code conservative रहेगा,
अभी भी full automatic doctrine reconstruction का दावा नहीं होगा,
अभी भी human review मुख्य रहेगा,
अभी भी retrieval की canonical authority review-सम्मत structured memory ही रहेगी,
और अभी भी first graph को provenance-rich रखना होगा।

इस corrected section में मूल परिवर्तन यह है कि अब system का केंद्र entity mentions नहीं, बल्कि यह चार-स्तरीय semantic ladder है:

Lexeme
Sense
CorpusConcept
PassageRole

और इनके ऊपर:

DiscourseForm
Assertion
RuleAssertion
Graph export

यही वह क्रम है जहाँ corpus धीरे-धीरे “mentions की सूची” से उठकर “structured knowledge field” में बदलता है।

पूर्वपक्ष

अब तक क्या बन चुका है, और क्या अभी नहीं बना?

अब तक हमारे पास यह है:

source register
normalization branch
document
passage segmentation
canonical PostgreSQL tables
first working ingestion skeleton

किन्तु अभी system के पास ये बातें नहीं हैं:

surface form और sense के बीच भेद
concept-level canonical memory
passage की role-awareness
discourse-form-aware assertion assembly
cluster-ready relations
first reviewed graph export

इसीलिये अब अगला स्वाभाविक प्रश्न यह नहीं है कि “और कितने passages ingest करें?”
प्रश्न यह है:

ingest किये हुए passages को actual knowledge units में कैसे बदला जाये?

पुरानी भ्रामक दिशा यह थी कि:

entity mentions
qualifier mentions
operator mentions

को ही मुख्य मान लिया जाये।
अब correction यह है कि वे सब subordinate linguistic-analysis tables के रूप में रह सकते हैं, किन्तु main trunk नहीं होंगे।

Main trunk अब यह होगा:

Lexeme
Sense
CorpusConcept
PassageRole

और फिर उनसे ऊपर:

DiscourseForm
Assertion
RuleAssertion

यही corrected center है।

Lexeme क्यों प्रथम?

क्योंकि text में सबसे पहले जो मिलता है, वह concept नहीं, बल्कि surface word-form है।

उदाहरण के लिये यदि किसी passage में कोई शब्द आता है, तो machine को पहले यह जानना चाहिए कि:

visible form क्या है,
normalized form क्या है,
script क्या है,
उसका probable lemma क्या है,
और वह कितनी बार कहाँ-कहाँ आया है।

इसीलिए Lexeme आवश्यक है।

यदि Lexeme को छोड़ा गया, और सीधे concept पर jump किया गया, तो तीन बड़ी भूलें होंगी:

(क) polysemy collapse

एक ही शब्द-रूप के अनेक अर्थ होंगे, पर system उन्हें एक ही node बना देगा।

(ख) surface-variant blindness

variant spellings, orthographic forms, transliteration forms, OCR distortions—इन सबका सही हिसाब नहीं बन सकेगा।

(ग) retrieval distortion

user query कई बार concept-level नहीं, lexeme-level होती है।
यदि lexeme inventory नहीं हुई, तो exact and fuzzy lexical retrieval दोनों दुर्बल होंगे।

अतः first extraction layer में Lexeme inventory अनिवार्य है।

Sense क्यों दूसरा स्तर है?

क्योंकि किसी भी Ārṣa corpus में surface word और अर्थ सदा एक-एक के अनुपात में नहीं चलते।

एक ही lexeme:

अनेक contexts में भिन्न meanings ले सकता है,
कभी doctrinal, कभी cosmological, कभी narrative, कभी lexical role में आ सकता है,
और कभी वही form किसी wider concept family का केवल एक entry-point होता है।

अतः Sense table के बिना system या तो अति-flat रहेगा,
या बार-बार गलत concept assignment करेगा।

Sense का कार्य
lexeme के distinct अर्थ-रूपों की canonical inventory
context-sensitive disambiguation का आधार
same lexeme के contradictory or parallel usages का नियमन
retrieval में sense-aware grouping
क्यों अभी से?

क्योंकि यदि शुरुआत में sense-layer न रखी गयी, तो later migration अत्यन्त कठिन हो जायेगी।
System फिर surface-form-centric हो जायेगा।

CorpusConcept क्यों तीसरा, और वास्तव में central स्तर है?

अब हम corrected architecture के मुख्य केंद्र पर आते हैं।

CorpusConcept वही इकाई है जो corpus में पुनरावृत्त, संगठित, relation-bearing, cluster-forming, benchmark-relevant, retrieval-meaningful semantic unit बनती है।

यह न केवल word है, न केवल sense, न केवल modern topic-tag।
यह corpus-internal अर्थ-केन्द्र है।

CorpusConcept की विशेषताएँ
इसका canonical name होगा
इसका constitutional trunk होगा
इसका concept type होगा
इसके variants होंगे
passages इसे express कर सकते हैं
assertions इसे relation में रख सकते हैं
clusters इसे संगठित कर सकते हैं
क्यों “CorpusConcept” शब्द?

क्योंकि यह external ontology से आरोपित नहीं, बल्कि corpus-derived semantic center है।

यहाँ मुख्य correction यह है कि system को modern entity extraction के स्तर पर नहीं रुकना है।
उसे corpus के भीतर उभरते हुए अर्थ-केन्द्रों को canonical memory में रखना है।

PassageRole क्यों इतना निर्णायक है?

यह इस पूरे section की आत्मा है।

किसी passage का मूल्य केवल यह नहीं कि उसमें कौन-सा concept आया।
वास्तविक प्रश्न यह है कि passage क्या कर रहा है।

क्या वह:

definition दे रहा है?
classification कर रहा है?
lexical gloss दे रहा है?
procedure बता रहा है?
injunction दे रहा है?
prohibition दे रहा है?
exception बता रहा है?
result statement दे रहा है?
narrative exemplum दे रहा है?
metaphysical statement दे रहा है?
cosmological statement दे रहा है?
colophon है?

यदि यह role नहीं पहचाना गया, तो retrieval विफल होगी।

उदाहरण

यदि user को किसी concept की definition चाहिए, पर system narrative exemplum ऊपर दे दे, तो वह retrieval तकनीकी रूप से “relevant” होते हुए भी वास्तविक उपयोग में कमतर होगी।

अतः

PassageRole table केवल tagging सुविधा नहीं; यह retrieval-ordering, benchmark design, graph semantics, और constitutional evidence-ranking—इन सबका मूलाधार है।

DiscourseForm क्यों अभी भी आवश्यक है?

अब एक सम्भावित भ्रम दूर कर दूँ।

यह सही है कि अब system entity-main architecture से हट चुकी है।
किन्तु इसका यह अर्थ नहीं कि DiscourseForm अनावश्यक हो गया।

DiscourseForm passage की बाह्य-आकृति और संरचनात्मक mode को बताता है।
यह PassageRole से भिन्न किन्तु संबद्ध है।

उदाहरण
COLOPHON
DIALOGUE
ENUMERATION
PRESCRIPTION
PROHIBITION
MAPPING
RESULT_STATEMENT

अंतर समझिये
DiscourseForm = text का structural-discursive shape
PassageRole = passage का knowledge-function

अनेक बार दोनों मिलेंगे, पर सदा नहीं।

उदाहरण

एक passage structurally ENUMERATION हो सकती है,
किन्तु उसका role CLASSIFICATION हो सकता है।

एक passage structurally DIALOGUE block में हो सकती है,
किन्तु उसका role METAPHYSICAL_STATEMENT हो सकता है।

इसलिए DiscourseForm detection assertion assembly से पहले आयेगी;
किन्तु PassageRole ही अंतिम semantic ranking में अधिक निर्णायक होगी।

Assertion और RuleAssertion में corrected भेद

अब इस भाग को भी पुनःस्थिर करना आवश्यक है।

७.१ Simple Assertion

जब किसी passage से कोई अपेक्षाकृत compact typed statement निकल सके।

उदाहरणतः:

कोई concept किसी अन्य concept को define कर रहा है
कोई concept किसी family से belongs_to है
कोई passage किसी concept को lexical gloss के रूप में support कर रहा है
कोई concept किसी broader concept cluster का member है

यहाँ:

subject होगा
relation family होगी
object या value होगा
confidence होगा
provenance passage होगा
७.२ RuleAssertion

जब statement multi-condition, scoped, role-sensitive, or structurally layered हो।

उदाहरण:

condition set + resulting doctrinal implication
exception under specific circumstances
procedure with ordered steps
condition + prohibition
condition + result statement + exception window

यहाँ simple triple पर्याप्त नहीं।
इसलिए:

condition_json
scope_json
polarity
result concept / qualifier / effect
action / operation
notes

की आवश्यकता होगी।

corrected principle

Simple assertions और rule assertions दोनों रहेंगे,
किन्तु अब उनके examples narrow specialist rules के स्थान पर general corpus knowledge से लिये जायेंगे।

Graph export अभी क्यों?

क्योंकि reviewed conceptual memory का पहला graph शीघ्र देखे बिना system की त्रुटियाँ नहीं पकड़ी जा सकतीं।

विशेषतः यह प्रश्न तुरन्त सामने आते हैं:

क्या Lexeme और Concept का भेद सही बन रहा है?
क्या Sense गलत स्थानों पर collapse हो रहे हैं?
क्या PassageRole graph में साफ दिख रही है?
क्या DiscourseForm और Role confuse हो रहे हैं?
क्या relation family legal है?
क्या कोई concept cluster अनुचित रूप से फूल रही है?
क्या provenance हर edge के पीछे सुरक्षित है?

इसलिए first Neo4j export बहुत बाद की चीज़ नहीं।
यह early inspection tool है।

उत्तरपक्ष

अब कुछ सम्भावित आपत्तियाँ।

आपत्ति १

“पहले सीधे CorpusConcept निकालिये; Lexeme और Sense अनावश्यक जटिलता हैं।”

यह भूल है।
यदि surface और sense को छोड़ा गया, तो:

polysemy टूटेगी,
exact lexical retrieval कमजोर होगी,
later reviewer को पता नहीं चलेगा कि concept किस word-form से निकाला गया,
provenance धुँधला हो जायेगा।

आपत्ति २

“PassageRole बाद में जोड़ लेंगे; अभी discourse form काफी है।”

यह भी पर्याप्त नहीं।
क्योंकि discourse form structural है; role semantic है।
Complete knowledge retrieval role-aware हुए बिना mature नहीं होगी।

आपत्ति ३

“Assertion और RuleAssertion अभी बहुत शीघ्र हैं।”

नहीं।
यदि reviewed semantic suggestions को assertion रूप में structured न किया गया, तो system कभी graph-worthy memory नहीं बना पायेगी।

सन्धि

अब corrected synthesis यह है:

Extraction का सही क्रम
Lexeme detection
Sense candidate formation
CorpusConcept proposal
PassageRole proposal
DiscourseForm detection
Assertion assembly
RuleAssertion assembly
review
first graph export

और यह सब तीन शक्तियों के संयुक्त प्रयोग से होगा:

deterministic rules
ML-assisted proposals
human review

यही मध्यम मार्ग है।
यही पूर्णतया manual भी नहीं, और अनियन्त्रित automatic भी नहीं।

सन्धान — वास्तविक कार्य-विधि

अब actual implementation direction को corrected रूप में रखता हूँ।

चरण १ — नयी files कौन-सी जोड़नी हैं?

अब इस section की corrected file-list यह होगी:

app/
db/
models/
lexeme.py
sense.py
concept.py
passage_role.py
discourse.py
assertion.py

schemas/
lexeme.py
sense.py
concept.py
passage_role.py
discourse.py
assertion.py
graph.py

repositories/
lexeme_repo.py
sense_repo.py
concept_repo.py
passage_role_repo.py
discourse_repo.py
assertion_repo.py

services/
extract_lexeme_service.py
extract_sense_service.py
extract_concept_service.py
detect_passage_role_service.py
detect_form_service.py
assemble_assertion_service.py
assemble_rule_service.py
graph_export_service.py

graph/
neo4j_client.py
graph_exporter.py

api/
routers/
extraction.py
review.py
graph.py

ध्यान दें:

entity.py, qualifier.py, operator.py अभी समाप्त नहीं किये जा रहे;
वे subordinate linguistic-analysis tables के रूप में बाद में या parallel layer में रह सकते हैं।
किन्तु central trunk अब यही है:
lexeme.py
sense.py
concept.py
passage_role.py
discourse.py
assertion.py

चरण २ — corrected models का मूलरूप

यहाँ मैं full code नहीं दे रहा, क्योंकि अभी section rewrite का लक्ष्य conceptual correction है।
किन्तु models का रूप स्पष्ट रखता हूँ।

lexeme.py

मुख्य fields:

lexeme_id
surface_text
normalized_surface
script
lemma_hint
notes
sense.py
sense_id
lexeme_id
sense_name
sense_description
constitutional_trunk
status
concept.py
concept_id
canonical_name
display_name
concept_type
constitutional_trunk
is_constitutional
status
notes
passage_role.py
role_assignment_id
passage_id
role_name
confidence
proposed_by
review_status
note
discourse.py
DiscourseForm
PassageForm
assertion.py
Assertion
RuleAssertion

अब corrected architecture में Assertion.subject_entity_id और object_entity_id की जगह मुख्य references concept-आधारित होने चाहिए।
यदि किसी step पर lexeme या sense needed हो, तो वह अलग provenance field में आये।

चरण ३ — extraction services की corrected भूमिका

३.१ extract_lexeme_service.py

यह passage-level surface forms निकालेगा:

exact lexeme matches
normalized variants
span positions
confidence

३.२ extract_sense_service.py

यह अभी final sense नहीं देगा;
केवल candidates देगा:

lexeme → possible senses
context-based ranking
review requirement

३.३ extract_concept_service.py

यह sense candidates, lexicon banks, and contextual cues से concept proposals बनायेगा।

३.४ detect_passage_role_service.py

यह passage का probable knowledge-function निकालेगा।

३.५ detect_form_service.py

यह अभी भी rule-based प्रारम्भिक discourse detector रहेगा।

३.६ assemble_assertion_service.py

यह concept-level simple assertions बनायेगा।

३.७ assemble_rule_service.py

यह multi-condition / scoped rule assertions बनायेगा।

चरण ४ — corrected extraction router flow

अब app/api/routers/extraction.py का corrected क्रम यह होना चाहिए:

POST /extraction/lexemes/run
POST /extraction/senses/run
POST /extraction/concepts/run
POST /extraction/passage-roles/run
POST /extraction/forms/run
POST /extraction/assertions/run
POST /extraction/rules/run

यह क्रम अब सही है।

पुराने क्रम में:

entities
qualifiers
operators

मुख्य trunk पर थे।
अब वे, यदि रहें, तो supporting analysis layer में रहेंगे।

चरण ५ — review queue का corrected रूप

अब review object types भी बदलेंगे।

old review objects
entity_mention
qualifier_mention
operator_mention
passage_form
assertion
rule_assertion
corrected review objects
lexeme_mention
sense_assignment
concept_mention
passage_role
passage_form
assertion
rule_assertion
later:
cluster_membership
retrieval_item
क्यों?

क्योंकि अब review का main work यही है:

क्या lexeme सही पकड़ा गया?
क्या sense-selection ठीक है?
क्या सही concept assign हुआ?
passage का role सही है?
assertion legal है?
rule assertion ठीक assemble हुई?

चरण ६ — Assertion assembly का corrected केंद्र

अब पुराने astrological-style mapping assertions हटाइये।
Assertion assembly अब इन प्रकार के outputs बनाए:

Type A — definitional assertion
passage expresses concept X as definition of concept Y
Type B — classificatory assertion
concept X belongs_to concept-family Y
Type C — lexical-gloss assertion
passage gives lexical support for concept X
Type D — support assertion
passage supports relation between concepts X and Y
Type E — contrast assertion
concept X contrasts_with concept Y

इनके लिये subject_concept_id और object_concept_id natural होंगे।

यदि value_literal चाहिए, तो वह रहे।
किन्तु center concept-level पर शिफ्ट होगा।

चरण ७ — RuleAssertion assembly का corrected केंद्र

अब RuleAssertion narrowly astrological नहीं, बल्कि corpus-wide scoped rules के लिये होगी।

examples

condition + prohibition
condition + injunction
condition + exception
condition + result
ordered procedure
role-conditioned doctrinal rule
possible fields
rule_kind
passage_id
action_concept_id
result_concept_id or result_value
polarity
condition_json
scope_json
confidence
review_status
important note

कुछ rules multi-concept होंगे;
कुछ operator-sensitive होंगे;
कुछ narrative conditions से निकलेंगे;
इसलिए first implementation conservative ही रहना चाहिए।

चरण ८ — first graph export का corrected रूप

Graph export अब इस corrected center पर होना चाहिए।

first exported node-types
Passage
Lexeme
Sense
Concept
PassageRole
Assertion
Rule
Work
first edges
Passage -[:MENTIONS_LEXEME]-> Lexeme
Passage -[:USES_SENSE]-> Sense
Passage -[:EXPRESSES_CONCEPT]-> Concept
Passage -[:HAS_ROLE]-> PassageRole
Passage -[:HAS_ASSERTION]-> Assertion
Passage -[:HAS_RULE]-> Rule
Assertion -[:SUBJECT]-> Concept
Assertion -[:OBJECT]-> Concept
Rule -[:ACTION]-> Concept
Rule -[:RESULT]-> Concept
क्यों conservative?

क्योंकि provenance-safe graph पहले बनना चाहिए।
बाद में high-confidence reviewed relations को direct semantic edges में promote किया जा सकता है।

चरण ९ — इस corrected section के बाद system क्या कर सकेगी?

इस section के बाद system इन कार्यों में समर्थ होगी:

passage-level lexeme detection
sense candidate generation
concept proposals
passage-role proposals
discourse-form detection
simple concept-level assertions
complex rule assertions
reviewed semantic items का first graph export

यही वास्तविक turning point है।
अब corpus केवल segmented text नहीं रहेगा;
वह first living semantic memory में बदलना आरम्भ करेगा।

चरण १० — corrected limits

यह section अभी भी सीमित है।
सीमाएँ स्पष्ट रखनी चाहिए।

सीमा १

Sense disambiguation अभी पूर्ण नहीं होगी; candidate-stage पर रहेगी।

सीमा २

PassageRole detection अभी largely rule-assisted या shallow ML-assisted होगी।

सीमा ३

Assertion assembly अभी conservative होगी; all possible relation families नहीं निकाले जायेंगे।

सीमा ४

RuleAssertion assembly अभी minimal होगी; multi-hop doctrinal inference बाद में आयेगा।

सीमा ५

Graph export reviewed objects पर केंद्रित रहेगा।

चरण ११ — आगे immediate improvements क्या होंगे?

इस corrected section के बाद अगला practical चरण होगा:

idempotency
deduplication
confidence scoring
review context UI
first benchmark runner

क्योंकि एक बार lexeme / sense / concept / role / assertion flow चल गयी,
अगला कार्य होगा:

duplicate रोकना,
confidence meaningful बनाना,
reviewer को context देना,
outputs का मापन करना।

चरण १२ — दो व्यावहारिक सावधानियाँ

(क) अभी भी E/Q/O को पूरी तरह न फेंकिये

Entity / Qualifier / Operator tables subordinate linguistic-analysis layer के रूप में उपयोगी रह सकती हैं।

उदाहरण:

qualifier attachment later rules में काम आयेगी
operator scope later rule assembly में काम आयेगी
named entities later retrieval groupings में सहायक होंगी

किन्तु उन्हें trunk न बनाइये।

(ख) review notes को अभी से गंभीरता दीजिये

क्योंकि later:

gold training comments
disagreement analysis
benchmark error taxonomy
constitutional exceptions

इन्हीं notes से निकलेगी।

इस section के Python files

Exact file paths inside the full Page-2 Python bundle

• app/core/config.py
• app/core/enums.py
• app/db/base.py
• app/db/session.py
• app/db/models/work.py
• app/db/models/source.py
• app/db/models/normalization.py
• app/db/models/document.py
• app/db/models/passage.py
• app/db/models/lexeme.py
• app/db/models/sense.py
• app/db/models/concept.py
• app/db/models/passage_role.py
• app/db/models/discourse.py
• app/db/models/assertion.py
• app/db/models/__init__.py
• app/schemas/source.py
• app/schemas/normalization.py
• app/schemas/document.py
• app/schemas/passage.py
• app/schemas/lexeme.py
• app/schemas/sense.py
• app/schemas/concept.py
• app/schemas/passage_role.py
• app/schemas/discourse.py
• app/schemas/assertion.py
• app/repositories/source_repo.py
• app/repositories/normalization_repo.py
• app/repositories/document_repo.py
• app/repositories/passage_repo.py
• app/repositories/lexeme_repo.py
• app/repositories/sense_repo.py
• app/repositories/concept_repo.py
• app/repositories/passage_role_repo.py
• app/repositories/discourse_repo.py
• app/repositories/assertion_repo.py
• app/services/ingest_service.py
• app/services/normalization_service.py
• app/services/segmentation_service.py
• app/services/match_utils.py
• app/services/extract_lexeme_service.py
• app/services/extract_sense_service.py
• app/services/extract_concept_service.py
• app/services/detect_passage_role_service.py
• app/services/detect_form_service.py
• app/services/assemble_assertion_service.py
• app/services/assemble_rule_service.py
• app/services/graph_export_service.py
• app/api/deps.py
• app/api/routers/health.py
• app/api/routers/sources.py
• app/api/routers/normalization.py
• app/api/routers/documents.py
• app/api/routers/pipelines.py
• app/api/routers/extraction.py
• app/api/routers/graph.py
• app/graph/neo4j_client.py
• app/graph/graph_exporter.py
• app/main.py
• scripts/create_tables.py

निष्कर्ष

इस corrected 12th section का सार यह है:

पहले जो stage entity / qualifier / operator-centered समझी जा रही थी,
उसे अब पूरी तरह re-center किया जाना चाहिए:

old center
entity mention
qualifier mention
operator mention
corrected center
Lexeme
Sense
CorpusConcept
PassageRole
DiscourseForm
Assertion
RuleAssertion
first graph export

यही corrected semantic ladder है।
इसीसे project actual complete knowledge retrieval architecture की ओर आगे बढ़ेगा।

उत्कर्ष

अब corrected sequence यह हो गया:

source
normalization
segmentation
lexeme extraction
sense candidate generation
corpus concept proposals
passage-role detection
discourse-form detection
assertion assembly
rule assertion assembly
review
graph export

अब अगला स्वाभाविक rewritten section होगा:

Idempotency, Deduplication, Confidence scoring, Review context, और प्रथम Benchmark runner

और अब उसमें examples, queues, और benchmark targets भी इसी corrected center पर रखे जायेंगे —
concept / role / relation / retrieval quality, न कि narrow entity-rule drift पर।

Idempotency, Deduplication, Confidence Scoring, Review Context, और प्रथम Benchmark Runner

complete knowledge retrieval system की स्थैर्य-रचना

इस लेख में उस चरण की चर्चा है जहाँ corpus-system केवल पाठ-संग्रह या extraction-pipeline नहीं रहती, बल्कि एक उत्तरदायी, मापनयोग्य, और पुनरुत्पादन-सक्षम ज्ञान-यन्त्र बनना आरम्भ करती है। विषय वही है जिसे आपने अपने draft में रखा था, पर यहाँ उसे स्वतंत्र, एकरेखीय, और website-योग्य रूप में प्रस्तुत किया गया है।

भूमिका

जब किसी corpus पर आधारित ज्ञान-प्रणाली का प्रारम्भिक ढाँचा खड़ा हो जाता है, तब पहले कुछ सुखद लक्षण दिखाई देते हैं। पाठ normalize होने लगते हैं। passages अलग होने लगते हैं। lexeme दिखाई देने लगते हैं। sense candidates निकलने लगते हैं। corpus concepts बनने लगते हैं। passage roles पहचाने जाने लगते हैं। discourse forms प्रस्तावित होने लगते हैं। assertions और rule assertions का निर्माण आरम्भ हो जाता है। पहली दृष्टि में लगता है कि अब system चल निकली।

किन्तु यहीं से वास्तविक संकट भी जन्म लेता है।

यदि यही pipeline पुनः चलाई जाये और उसी passage पर वही lexeme mention दूसरी बार बन जाये, वही sense assignment फिर से बैठ जाये, वही concept mention पुनरावृत्त हो जाये, वही passage-role बार-बार जुड़ता जाये, और वही assertions graph में दुहराने लगें, तो system की semantic memory शीघ्र ही अविश्वसनीय हो जायेगी। ऐसी दशा में बाद की सारी उन्नति—active learning, review queue, retrieval metrics, benchmark reports, branch comparison—सब विकृत हो जाती है।

इसी कारण इस स्तर पर पाँच तत्त्व अनिवार्य हो जाते हैं:

Idempotency
Deduplication
Confidence Scoring
Review Context
Benchmark Runner

ये पाँच किसी software-शिल्प की सजावटी सुविधाएँ नहीं हैं। यही वे आधार-स्तम्भ हैं जिन पर system की विश्वसनीयता टिकी रहेगी।

पूर्वपक्ष

Idempotency का यथार्थ अर्थ

Idempotency का मूल अर्थ यह है कि एक ही input, एक ही normalization branch, एक ही नियम-समूह, और एक ही extraction logic पर pipeline दुबारा चलाने से database में नया semantic कूड़ा न बने। इस सिद्धान्त का आशय यह नहीं कि system कभी नया ज्ञान ग्रहण न करे। आशय केवल इतना है कि same computation should yield the same stored result.

यदि किसी document_id पर lexeme extraction चलाकर तीन mentions निकलीं—मान लीजिये लोक, काल, धर्म—तो उसी document पर उसी logic के साथ वही सेवा फिर चलने पर तीन से छह mentions नहीं होनी चाहिए। यही नियम sense assignments, concept mentions, passage roles, discourse forms, assertions, और rules—सभी पर लागू होगा।

यह आवश्यकता विशेष रूप से इस प्रकार के project में अधिक गंभीर है, क्योंकि यहाँ reprocessing स्वाभाविक है। normalization branch बदल सकती है। role model बदल सकता है। review के बाद rerun करना पड़ सकता है। benchmark reports फिर से बन सकती हैं। branch comparisons हो सकती हैं। यदि idempotency नहीं होगी, तो system हर rerun पर थोड़ी-थोड़ी दूषित होती जायेगी और अंततः उसका कोई semantic count विश्वसनीय नहीं रहेगा।

Deduplication का स्तरबद्ध स्वरूप

Duplicate को केवल same row समझ लेना भूल है। यहाँ duplicate प्रायः semantic object का duplicate होता है, केवल database row का नहीं। इसलिए deduplication भी स्तरबद्ध होगी।

पहला स्तर lexeme-level dedup है। एक ही passage में, एक ही span पर, एक ही lexeme mention बार-बार नहीं बैठनी चाहिए। दूसरा स्तर sense-level dedup है। एक ही lexeme-span पर वही sense assignment दुहरायी नहीं जानी चाहिए। तीसरा स्तर concept-level dedup है। एक ही passage में वही concept, उसी scope और उसी provenance के साथ पुनः न जुड़े। चौथा स्तर assertion और rule-level dedup है। एक ही passage से वही relation या वही rule दुहराकर न निकले। पाँचवाँ passage-role dedup है। एक passage पर वही role अनेक बार attach न हो।

अतः deduplication केवल SQL distinct का विषय नहीं। वह semantic fingerprinting का विषय है। जब तक हर extracted object का एक deterministic fingerprint नहीं बनेगा, तब तक semantic duplicates का नियंत्रण नहीं होगा।

Confidence Scoring क्यों अनिवार्य है

प्रारम्भिक विकास-चरणों में high / medium / low जैसे labels उपयोगी हो सकते हैं, पर system बढ़ने पर वे अपर्याप्त हो जाते हैं। reviewer को यह जानना होता है कि किस item को पहले देखना चाहिए। active learning को यह चुनना होता है कि कौन-से cases सबसे अधिक शिक्षाप्रद होंगे। benchmark error analysis को यह देखना होता है कि confidence कहाँ गलत बैठी। branch comparison को यह समझना होता है कि कोई नया model वास्तविक improvement ला रहा है या केवल अधिक confidence व्यक्त कर रहा है।

इसलिए प्रत्येक semantic object के साथ दो स्तरों की confidence होनी चाहिए:

confidence label
confidence score

ये objects होंगे:

lexeme mentions
sense assignments
concept mentions
passage roles
discourse forms
assertions
rule assertions

Confidence scoring का प्रयोजन machine को अंतिम authority देना नहीं है। इसका प्रयोजन यह है कि human review बुद्धिसंगत क्रम में चले और system अपने ही अनुमान की गुणवत्ता को मापने योग्य रूप में रखे।

Review Context की आवश्यकता

यदि reviewer को केवल यह दिखाया जाये कि:

concept_mention_id = 38
surface_text = लोक
concept = world_region

तो वह कैसे निर्णय करेगा कि यह ठीक है? शब्द एक है, अर्थ अनेक हो सकते हैं। वह तभी निर्णय कर सकेगा जब उसके सामने पूरा संदर्भ उपस्थित हो।

उसे raw text देखना होगा। normalized text देखना होगा। previous और next passages देखने होंगे। verse-window देखना होगा। lexeme mentions, sense assignments, concept mentions, passage roles, discourse forms, assertions, rules—सब एक साथ देखने होंगे। तभी वह निश्चय करेगा कि यहाँ लोक cosmological है, social है, या किसी अन्य concept-family का द्योतक है। तभी वह देख सकेगा कि passage वास्तव में CLASSIFICATION है या केवल ENUMERATION। तभी वह यह भी जान सकेगा कि assertion वास्तव में defines है या केवल supports।

इसलिए review context कोई luxury नहीं। वह constitutional human judgment की अनिवार्य भूमि है।

Benchmark Runner शीघ्र क्यों

यह प्रश्न स्वाभाविक है कि benchmark runner इतनी आरम्भिक अवस्था में क्यों जोड़ी जाये। क्यों न पहले और extraction layers जोड़ ली जायें?

उत्तर यह है कि जब तक measured truth नहीं, stable test cases नहीं, और repeatable reports नहीं, तब तक “system सुधर रही है” यह वाक्य अर्थहीन है। Benchmark runner ही वह साधन है जो किसी branch, किसी model, या किसी pipeline step को मापनयोग्य बनाता है। प्रारम्भिक runner छोटा होगा; किन्तु वही आगे regression detection, branch comparison, constitutional gating, और deployment discipline का आधार बनेगा।

उत्तरपक्ष

अब कुछ आपत्तियों पर विचार आवश्यक है।

पहली आपत्ति यह कि idempotency बाद में जोड़ सकते हैं, अभी features बढ़ाने चाहिए। यह मत भ्रमपूर्ण है। Features बिना idempotency के बढ़ेंगे, तो cleanup असाध्य हो जायेगा। System में semantic clutter इस प्रकार जमा होगा कि बाद में सत्य और दूषण अलग करना कठिन होगा।

दूसरी आपत्ति यह कि duplicate rows हटा देना ही पर्याप्त है। नहीं। Duplicate semantic object का प्रश्न है, केवल row duplication का नहीं। यदि fingerprinting नहीं हुई, तो एक ही relation थोड़े-से स्वरूपांतर के साथ अनेक बार बैठ सकता है और system उसे नया समझती रहेगी।

तीसरी आपत्ति यह कि confidence score machine का निजी अनुमान है, उसका क्या उपयोग। यदि confidence नहीं होगी, तो review ordering अन्धी होगी, active learning असंगत होगी, और benchmark interpretation अधूरी रहेगी। Confidence की त्रुटि भी एक data point है; वही बाद में error analysis का आधार बनेगी।

चौथी आपत्ति यह कि review context बहुत भारी हो जायेगा। इसका उत्तर यह है कि quick cases और difficult cases अलग हैं। हल्के cases के लिये संक्षिप्त context पर्याप्त हो सकती है; पर polysemy, mixed-zone, role ambiguity, operator scope, या doctrinal conflict वाले cases में rich context अनिवार्य है। अतः context के भी स्तर होने चाहिए।

पाँचवीं आपत्ति यह कि benchmark manually scholars से करा लेंगे। यह भी अधूरा मार्ग है। Manual judgment आवश्यक है, किन्तु reproducible benchmark runner के बिना engineering discipline नहीं बनती। Scholar judgment और machine-run benchmark, दोनों का संयुक्त उपयोग ही उचित है।

सन्धि

अब समुचित संश्लेषण यह है कि ये पाँच तत्त्व system के semantic ladder को स्थिर रखते हैं।

Idempotency पुनरावृत्ति-दूषण से बचाती है। Deduplication semantic memory को स्वच्छ रखती है। Confidence scoring review और active learning को क्रम देती है। Review context human constitutional judgment को समर्थ बनाता है। Benchmark runner सुधार को मापनयोग्य बनाता है।

इन पाँच के बिना semantic ladder केवल प्रस्तावों का ढेर है। इनके साथ वही ladder एक स्थिर, क्रमशः परिपक्व होती ज्ञान-स्मृति बनती है।

सन्धान

अब वास्तविक कार्य-विधि प्रस्तुत है।

Semantic Fingerprinting का नियम

हर महत्त्वपूर्ण extracted object के लिये deterministic fingerprint बनेगा। यही idempotency और deduplication का मूलाधार होगा। Fingerprint के निर्माण में प्रायः ये तत्त्व सम्मिलित होंगे:

passage_id
object type
primary ids
spans
normalized relation fields
normalized condition/scope payloads

उदाहरणतः एक lexeme mention का fingerprint passage_id, lexeme_id, surface_text, char_start, char_end, और object marker "lexeme" से बनेगा। Sense assignment का fingerprint passage_id, lexeme_id, sense_id, span information, और "sense" से। Concept mention में passage_id, concept_id, surface_text, और "concept" पर्याप्त हो सकता है। Passage role में passage_id, role_name, और "passage_role"। Assertion में passage_id, assertion_type, subject_concept_id, relation_type, object_concept_id, और value_literal। RuleAssertion में passage_id, rule_kind, action_concept_id, result_concept_id, polarity, canonicalized condition_json, और canonicalized scope_json।

यहाँ मूल बात यह है कि fingerprint किसी textual accident पर नहीं, बल्कि semantic identity पर आधारित हो।

Database स्तर पर Unique Constraints

Application-level dedup उपयोगी है, पर database-level safety भी आवश्यक है। कम से कम निम्न tables पर unique constraints या fingerprint-based uniqueness होनी चाहिए:

passage_lexeme_mentions
passage_sense_assignments
passage_concept_mentions
passage_roles
passage_forms
assertions
rule_assertions

यदि आगे multi-threaded runs, background jobs, या branch-compare scripts parallel चलें, तो DB-level uniqueness के बिना race-condition duplication होना निश्चित है।

Idempotent Repository Pattern

प्रत्येक repository में एक स्पष्ट pattern होना चाहिए।

पहला, exists(fingerprint) method।
दूसरा, create_many(payloads) method।
तीसरा, create_many केवल उन्हीं payloads को insert करे जिनका fingerprint पहले उपस्थित न हो।
चौथा, वह केवल वास्तव में created objects लौटाये।

यह छोटा दिखनेवाला नियम अत्यन्त महत्त्वपूर्ण है। यदि service layer हर बार payload length को created_count मान ले, तो logs, benchmark reports, और review metrics सब गलत होंगे।

Confidence Scoring का रचनात्मक स्वरूप

Confidence scoring को object-type wise सोचना होगा।

Lexeme mention में exact lexicon match होने पर score ऊँचा होगा। Normalized variant match पर कुछ कम। OCR-recovered अनुमान पर और कम। Sense assignment में यदि lexeme का केवल एक स्पष्ट candidate है, score ऊँचा। यदि कई possible senses हैं, तो top candidate मध्यम। Context weak होने पर score कम। Concept mention में यदि sense-to-concept mapping स्थिर है, score ऊँचा। यदि concept family broad है, score मध्यम। Mixed-zone या structurally ambiguous case में कम।

PassageRole के लिये cues, structure, and context के आधार पर score बनेगा। DiscourseForm प्रायः structural होने के कारण कुछ स्थिर हो सकती है। Assertions और RuleAssertions सबसे अधिक conservative scoring माँगते हैं। Simple assertions प्रायः medium confidence से ऊपर जा सकती हैं; जटिल RuleAssertions review के पूर्व low या medium पर रखी जानी चाहिए।

प्रारम्भिक label mapping इस प्रकार हो सकती है:

अन्यथा → low

यह पर्याप्त प्रारम्भिक व्यवस्था है, जिसे later calibration से refine किया जा सकता है।

Review Context API की रचना

Review context object में कम से कम निम्न fields हों:

Passage identity
passage_id
passage_type
chapter_no
verse_start
verse_end
Text views
text_raw
text_norm
previous_passage
next_passage
Lexical layer
lexeme mentions
Sense layer
sense assignments
Concept layer
concept mentions
Semantic role layer
passage roles
discourse forms
Structured output layer
assertions
rule assertions

इसीसे reviewer semantic ladder को एक साथ देख सकेगा। यही corrected review context का प्रयोजन है।

Review Queues का आयोजन

Review queues object-type wise हों:

lexeme_mention
sense_assignment
concept_mention
passage_role
passage_form
assertion
rule_assertion

आगे विस्तार में:

cluster_membership
retrieval_item
query_interpretation

प्रथम चरण में queue ordering created_at या confidence_score ascending पर हो सकती है। द्वितीय चरण में uncertainty, disagreement, या underrepresented work/role family के आधार पर routing जोड़ी जानी चाहिए।

प्रथम Benchmark Runner

पहला benchmark runner छोटा होना चाहिए, पर उसका center सही होना चाहिए। इस stage पर दो प्रकार पर्याप्त हैं:

assertion_exists
role_exists

इनसे यह जाँचा जा सकेगा कि section 12 में बने corrected outputs वास्तव में बन रहे हैं या नहीं। आगे:

retrieval grouping
constitutional priority
cluster integrity
sense selection

जैसे benchmarks जोड़े जा सकते हैं। पर प्रथम runner को बहुत बड़ा बनाना उचित नहीं।

Error Analysis की आरम्भिक तैयारी

यद्यपि full error taxonomy अगले स्तर पर विस्तृत होगी, अभी से benchmark logs में कम से कम यह record होना चाहिए:

object type
expected
observed
missing / wrong / duplicate
confidence at time of proposal

इसीसे आगे यह देखा जा सकेगा कि system कहाँ विफल हो रही है: concept पर, role पर, relation पर, या duplication discipline पर।

Graph Export पर प्रभाव

Idempotency और review status के बिना graph export विश्वसनीय नहीं हो सकती। इसलिए प्रथम नियम यह होना चाहिए कि graph export मुख्यतः reviewed objects पर आधारित हो। needs_review objects केवल debug mode में जाने चाहिए।

यदि low-confidence, unreviewed semantic objects unrestricted graph में चले गये, तो:

concept neighborhoods दूषित होंगे,
retrieval expansion गलत होगी,
benchmark reports मिथ्या होंगी।

इसलिए graph export discipline इस section का स्वाभाविक अंग है।

Actual Workflow

अब इस stage का पूर्ण corrected flow इस प्रकार है:

source register
normalization branch create
document create
normalize document
segment document
run lexeme extraction
run sense extraction
run concept extraction
run passage-role detection
run discourse-form detection
run assertion assembly
run rule assembly
review queue देखना
review context खोलना
decision देना
benchmark run करना
graph export करना

यही पहला जीवित semantic cycle है।

इस stage के Python files का वास्तविक प्रयोजन

इस stage की code-delivery में जो files आती हैं, उनका प्रयोजन अब स्पष्ट होना चाहिए।

Models
lexeme.py
sense.py
concept.py
passage_role.py
discourse.py
assertion.py
review.py
benchmark.py
Schemas
lexeme.py
sense.py
concept.py
passage_role.py
discourse.py
assertion.py
review.py
benchmark.py
Services
extract_lexeme_service.py
extract_sense_service.py
extract_concept_service.py
detect_passage_role_service.py
detect_form_service.py
assemble_assertion_service.py
assemble_rule_service.py
review_service.py
context_service.py
benchmark_service.py
fingerprints.py
confidence.py
Repositories
corrected idempotent repositories
Routers
extraction.py
review.py
benchmarks.py
graph.py

इन सबका सामूहिक प्रयोजन यह है कि semantic ladder बन सके, स्थिर रह सके, और मापनयोग्य हो।

अभी क्या शेष रहेगा

यह भी मानना चाहिए कि इस stage के बाद भी बहुत कुछ आगे के sections में विकसित होगा:

concept clusters
retrieval evidence groups
query interpretations
active learning queues
branch registry
deployment law
shadow promotion
constitutional test suite
hybrid retrieval scoring
embedding artifacts

किन्तु section 12–13 का सही आधार बने बिना वे सभी अस्थिर रहेंगे।

इस section के Python files

Exact file paths inside the full Page-2 Python bundle

• app/db/models/review.py
• app/db/models/benchmark.py
• app/schemas/review.py
• app/schemas/benchmark.py
• app/repositories/review_repo.py
• app/repositories/context_repo.py
• app/repositories/benchmark_repo.py
• app/services/fingerprints.py
• app/services/confidence.py
• app/services/review_service.py
• app/services/context_service.py
• app/services/benchmark_service.py
• app/api/routers/review.py
• app/api/routers/benchmarks.py

निष्कर्ष

इस लेख का सार यह है कि semantic ladder के निर्माण के साथ-साथ उसके स्थैर्य की युक्तियाँ भी उसी समय जोड़नी चाहिए। बाद में जोड़ने का विचार प्रायः महँगा और कभी-कभी असाध्य सिद्ध होता है।

अतः इस stage के पाँच स्थिर स्तम्भ हैं:

Idempotency = semantic memory की रक्षा
Deduplication = पुनरावृत्ति-दूषण का निरोध
Confidence Scoring = review और active learning की क्रमबद्धता
Review Context = human constitutional judgment की भूमि
Benchmark Runner = सुधार की मापन-रेखा

इन्हीं से system keyword-प्रस्तावों के ढेर से उठकर एक उत्तरदायी, अनुशासित semantic machine बनती है।

उत्कर्ष

अब तक की sequence इस प्रकार बनती है:

source → normalization → segmentation → lexeme extraction → sense candidates → corpus concepts → passage roles → discourse forms → assertions → rule assertions → idempotency → deduplication → confidence scoring → review context → benchmark runner → graph export

अब अगला स्वाभाविक लेख होगा:

Branch Registry, Promotion Workflow, Rollback Workflow, Benchmark Report Comparison, और Shadow Deployment Logic

और वहाँ केंद्र होगा:

concept / role / assertion / rule / benchmark branch behavior,
न कि कोई संकीर्ण extraction drift।

Branch Registry, Promotion Workflow, Rollback Workflow, Benchmark Report Comparison, और Shadow Deployment Logic

concept / role / relation / retrieval branches के शासन की वास्तविक रचना

भूमिका

अब तक की रचना में यह आधार बन चुका है:

source register
normalization branches
document और passage memory
lexeme / sense / corpus concept proposals
passage-role detection
discourse-form detection
assertion और rule assertion
review queues
first benchmark discipline
first graph export

इतना होते ही system “चलने” लगता है; किन्तु केवल चलना पर्याप्त नहीं।
अब अगला प्रश्न यह है कि system कैसे बढ़ेगी, कैसे सुधरेगी, और कैसे अनुशासित रहेगी।

क्योंकि अब से अनेक प्रकार के परिवर्तन होने लगेंगे:

concept assignment logic बदलेगी
sense disambiguation model बदलेगा
passage-role rules बदलेंगे
relation extraction branch बदलेगी
cluster construction विधि बदलेगी
retrieval fusion weights बदलेंगे
constitutional scoring में refinement होगा

इन सब परिवर्तनों से अनेक branches बनेंगी।
अब प्रश्न यह नहीं कि “नया version है”।
प्रश्न यह है:

कौन-सा branch केवल प्रयोग है?
कौन-सा branch benchmark में उत्तम है?
कौन-सा branch constitution-सम्मत है?
कौन-सा branch main system में लाया जा सकता है?
कौन-सा branch केवल shadow mode में चलना चाहिए?
यदि नया branch हानि करे तो वापसी कैसे होगी?

इसीलिए इस section का विषय है:

Branch Registry
Promotion Workflow
Rollback Workflow
Benchmark Report Comparison
Shadow Deployment Logic

यह सामान्य software-शासन नहीं है।
यह एक constitutional knowledge system के विकास का शासन-विधान है।

पूर्वपक्ष

Branch Registry क्यों आवश्यक है?

यदि कोई developer किसी model, rule-set, retrieval logic, या normalization logic में परिवर्तन करे और उसे बिना लिखित पहचान के system में ला दे, तो project का इतिहास टूट जाता है। बाद में कोई नहीं जान पाता:

क्या बदला था,
किसने बदला,
किस उद्देश्य से बदला,
किस parent version से निकला,
किस benchmark पर जाँचा गया,
और यदि हानि हुई तो दोष कहाँ है।

अतः हर महत्त्वपूर्ण परिवर्तन को named branch के रूप में जीना होगा।

branch किन-किन प्रकार के हो सकते हैं?

केवल ML model branches नहीं, बल्कि:

normalization branches
concept_model branches
role_model branches
relation_model branches
cluster_model branches
retrieval branches
ontology branches

अर्थात् जहाँ भी बदलने योग्य logic है, वहाँ branch discipline लागू होगी।

Branch Registry का कार्य

यह प्रत्येक branch की पहचान सुरक्षित रखेगी:

branch_name
branch_type
parent_branch_id
description
status
created_by
notes

यह केवल सूची नहीं। यही project की विकास-स्मृति है।

Branch Comparison का प्रयोजन

एक branch का अर्थ तभी है जब उसे किसी दूसरी branch से तुलना में देखा जाये।
तुलना के बिना branch केवल नाम है।

जब हमारे पास:

एक baseline branch
एक candidate branch
एक benchmark version

हो, तब comparison को यह बताना होगा:

pass-count बढ़ा या नहीं
fail-count बढ़ा या नहीं
constitutional pass बना रहा या नहीं
regression हुआ या नहीं
recommendation क्या है

यदि यह न हुआ, तो promotion केवल मनोवृत्ति पर आधारित होगा, प्रमाण पर नहीं।

benchmark_version क्यों आवश्यक है?

क्योंकि benchmark suite भी बदलती रहती है।
यदि एक branch v1 benchmark पर देखी गयी और दूसरी v3_constitutional पर, तो सीधी तुलना न्यायसंगत नहीं होगी।
अतः comparison record में benchmark_version अनिवार्य है।

recommendation के प्रारम्भिक रूप

प्रथम चरण में recommendation इतनी हो सकती है:

promote_to_candidate
promote_to_shadow
keep_in_sandbox

आगे जाकर अधिक सूक्ष्म recommendations जोड़ी जा सकती हैं।

Promotion Workflow क्या है?

Promotion का अर्थ केवल status field बदल देना नहीं है।
Promotion project के शासन-विधान में एक निर्णयात्मक कर्म है।

promotion के प्रकार
promote_to_shadow
promote_to_candidate
promote_to_main
reject
rollback
keep_in_sandbox
promotion stages क्यों?

क्योंकि semantic retrieval systems प्रायः सीधे sandbox से main में नहीं जाने चाहिए।
कभी branch इतनी अच्छी होती है कि candidate बन सकती है।
कभी वह promising होती है पर अभी shadow में देखी जानी चाहिए।
कभी वह कुछ tests में अच्छी है पर main के योग्य नहीं।
कभी वह संविधान-विरुद्ध सिद्ध होती है।

अतः बीच के चरण आवश्यक हैं।

promotion किन आधारों पर हो?

एक branch को तभी ऊपर उठना चाहिए जब:

benchmark में सुधार हो, या कम से कम हानिकारक regression न हो
constitutional suite pass हो
change explainable हो
reviewer burden असंगत न बढ़े
rollback path स्पष्ट हो
deployment सुरक्षित हो
rationale क्यों लिखना चाहिए?

हर promotion decision के साथ एक लिखित कारण होना चाहिए।
क्योंकि आगे चलकर वही बनेगा:

audit trail
debugging clue
governance memory
reviewer guidance
constitutional record

Shadow Deployment का यथार्थ अर्थ

Shadow deployment इस section का अत्यन्त महत्वपूर्ण भाग है।

Shadow का अर्थ

एक candidate branch:

उसी input पर चलती है,
output देती है,
पर main canonical output को प्रतिस्थापित नहीं करती।

वह साथ-साथ चलती है, ताकि उसकी तुलना की जा सके।

यह क्यों आवश्यक है?

क्योंकि कोई retrieval branch कुछ direct definition queries में बहुत अच्छी लग सकती है, पर:

indirect evidence grouping बिगाड़ दे,
mixed-zone passages को flatten कर दे,
primary corpus priority घटा दे,
role ordering बिगाड़ दे,
narrative support को definition से ऊपर कर दे।

ऐसी हानि कई बार benchmark में त्वरित रूप से नहीं पकड़ी जाती।
Shadow deployment इसी छिपी हुई हानि को देखने का चरण है।

कब shadow उपयोगी है?

जब:

benchmark में improvement है, पर पूर्ण विश्वास अभी नहीं
constitutional suite pass है, पर evidence-ordering संदिग्ध है
difficult queries पर्याप्त रूप से gold set में नहीं हैं
नया retrieval logic live pattern पर देखना है
reviewer feedback लेना है

Shadow mode इस project में optional सुविधा नहीं; वह एक वास्तविक शासन-चरण है।

Main Deployment कब?

Main deployment तभी होनी चाहिए जब branch अब main output को नियंत्रित करने योग्य मानी जाये।

इसके लिये चाहिए:
benchmark comparison
constitutional pass
recorded promotion decision
deployment record
rollback target या rollback plan
Deployment record में क्या हो?
deployment_phase
branch_id
deployed_by
deployment_mode
rollback_branch_id
notes

यदि main deployment बिना इस record के कर दी गयी, तो बाद में rollback केवल स्मृति पर निर्भर रहेगा, जो अनुचित है।

Rollback Workflow क्यों अनिवार्य है?

Rollback विफलता का चिह्न नहीं;
वह परिपक्वता का चिह्न है।

rollback कब उचित होगा?

जब:

promoted branch live या shadow analysis में regression दिखाये
broader corpus पर benchmark inconsistencies निकले
constitutional anomaly प्रकट हो
reviewer complaints बढ़ें
graph legality बिगड़े
retrieval evidence ordering में स्पष्ट हानि हो
cluster stability टूटे
Rollback क्या करेगा?
current deployment को rolled_back चिह्नित करेगा
affected branch की status बदलेगा
rollback branch को active deployment बनायेगा
rollback branch पहले से क्यों ज्ञात हो?

क्योंकि “पुराने state पर लौट चलो” एक अस्पष्ट वाक्य है।
सही शासन कहता है:

कौन-सा exact branch वापसी के लिये तैयार है?

Benchmark Report Comparison का शासनगत महत्व

Benchmark reports केवल dashboard सजाने के लिये नहीं हैं।
वे branch governance की प्रमाण-सामग्री हैं।

एक सार्थक comparison report में क्या होना चाहिए?
baseline_run_id
candidate_run_id
baseline_passed
candidate_passed
pass_delta
fail_delta
constitutional_pass
regression_detected
recommendation
यह क्यों पर्याप्त प्रारम्भिक रूप है?

क्योंकि इससे तुरन्त यह स्पष्ट हो जाता है:

candidate branch ने क्या सुधारा,
क्या बिगाड़ा,
constitution बची या नहीं,
और कौन-सा अगला शासन-चरण उचित है।
सावधानी

यदि pass_delta positive हो, तब भी branch main के योग्य नहीं हो सकती यदि:

constitutional pass fail हो,
fail_delta critical हो,
improvement बहुत narrow हो,
reviewer burden बहुत बढ़े।

इसलिए benchmark comparison आवश्यक है, पर अकेली निर्णायक नहीं।

उत्तरपक्ष

अब कुछ सामान्य भ्रान्तियों का निरसन करना चाहिए।

भ्रान्ति १

“developer को स्वयं पता है कि उसका change अच्छा है; branch registry अनावश्यक है।”

यह अल्पदृष्टि है।
व्यक्ति को अपनी स्मृति पर विश्वास हो सकता है; project को नहीं।
Project को traceable evolution चाहिए।

भ्रान्ति २

“benchmark score बढ़ गया, बस promote कर दो।”

यह अधूरा नियम है।
कोई branch एक metric सुधार सकती है और constitution बिगाड़ सकती है।

भ्रान्ति ३

“shadow stage समय नष्ट करती है।”

अनेक बार यही stage बड़े दोषों को main system में जाने से रोकती है।
विशेषतः retrieval systems में shadow अत्यन्त उपयोगी है।

भ्रान्ति ४

“rollback की बात बाद में सोचेंगे।”

यह विचार मुख्य deployment से पहले ही त्याज्य है।
जो branch rollback plan के बिना deploy हो, वह शासनहीन deployment है।

सन्धि

अब समुचित संश्लेषण यह है:

Branch Registry project की विकास-स्मृति है
Branch Comparison प्रमाण-सम्मत तुलनात्मक निर्णय का साधन है
Promotion Workflow branch की उन्नति का अनुशासित मार्ग है
Shadow Deployment सावधानीपूर्वक परीक्षण का चरण है
Rollback Workflow सुरक्षा और वापसी का विधान है
Benchmark Report Comparison शासन का लिखित प्रमाण है

ये सब मिलकर system के semantic evolution को lawful बनाते हैं।

सन्धान

अब वास्तविक कार्य-विधि क्रमबद्ध रूप में रखता हूँ।

चरण १ — Branch states की स्पष्ट सूची

कम से कम ये states रहनी चाहिए:

sandbox
shadow
candidate
promoted
rejected
rolled_back
अर्थ
sandbox = केवल प्रयोग
shadow = साथ-साथ चल रहा, पर canonical नहीं
candidate = गंभीर promotion consideration के योग्य
promoted = main या accepted scope में स्थापित
rejected = जान-बूझकर अस्वीकृत
rolled_back = पहले बढ़ा, बाद में लौटाया गया

यही स्पष्ट state-model branch-history को बोधगम्य बनाती है।

चरण २ — Branch types की सूची

प्रथम चरण में branch_type निम्न रह सकते हैं:

normalization
concept_model
role_model
relation_model
cluster_model
retrieval
ontology

यही corrected center है।
अब branch management narrow extraction tables पर नहीं, बल्कि concept / role / relation / retrieval पर केन्द्रित है।

चरण ३ — Branch record creation

जब भी कोई नया branch बने, यह fields भरें:

branch_name
branch_type
parent_branch_id
description
status = sandbox
created_by
notes
उदाहरण

यदि role detection model बदला:

branch_type = role_model

यदि retrieval scoring weights बदले:

branch_type = retrieval

यदि top-level ontology या relation legality बदली:

branch_type = ontology

चरण ४ — Comparison process

किसी candidate branch की baseline branch से तुलना करते समय:

Input
baseline_branch_id
candidate_branch_id
benchmark_version
Process
दोनों branches के latest benchmark runs लाओ
summary JSON पढ़ो
baseline और candidate का passed / failed count निकालो
constitutional_pass देखो
regression_detected का नियम लगाओ
recommendation बनाओ
First rule

यदि:

constitutional_pass = true
pass_delta > 0
regression_detected = false

तो recommendation:

promote_to_candidate

यदि:

constitutional_pass = true
pass_delta >= 0
पर subtle concerns शेष हैं

तो recommendation:

promote_to_shadow

अन्यथा:

keep_in_sandbox

चरण ५ — Promotion decision writing

Comparison report आने के बाद final promotion human-governed service द्वारा हो।

Decision payload में
branch_id
decided_by
target_decision
comparison_id
rationale
क्यों?

क्योंकि report recommendation देती है;
अन्तिम promotion अब भी शासन-सम्मत human decision होगी।

चरण ६ — Shadow deployment creation

जब branch shadow में भेजी जाये, deployment record बने:

deployment_phase
branch_id
deployed_by
deployment_mode = shadow
rollback_branch_id
notes
उदाहरणार्थ प्रयोजन
same query logs पर branch का output compare करना
reviewer feedback लेना
difficult cases में silent drift देखना

चरण ७ — Main deployment creation

जब branch main में जाये:

पहले promotion decision promote_to_main
फिर deployment record deployment_mode = main
और rollback target स्पष्ट

यह क्रम उल्टा नहीं होना चाहिए।

चरण ८ — Rollback process

जब rollback आवश्यक हो:

Input
deployment_id
decided_by
rationale
Process
deployment खोजो
देखो rollback_branch_id है या नहीं
current deployment को rolled_back mark करो
current branch को भी rolled_back mark करो
rollback branch का नया active deployment create करो

यही clean rollback है।

चरण ९ — Reports का उपयोग

हर governance report में यह स्पष्ट दिखना चाहिए:

किस branch की बात है
किस benchmark version पर बात है
क्या सुधरा
क्या बिगड़ा
constitution बची या नहीं
recommendation क्या है
final decision क्या हुआ

यह report project की स्मृति बनेगी।

चरण १० — Python scaffold files

इस section के लिये अलग zip में जो files रखी गयी हैं, उनका प्रयोजन इस प्रकार है:

Models
app/db/models/branch.py
app/db/models/deployment.py
Schemas
app/schemas/branch.py
app/schemas/deployment.py
app/schemas/comparison.py
Repositories
app/repositories/branch_repo.py
app/repositories/deployment_repo.py
Services
app/services/comparison_service.py
app/services/promotion_service.py
app/services/deployment_service.py
Routers
app/api/routers/branches.py
app/api/routers/deployments.py
Documentation
SECTION_14_MANIFEST.md
INTEGRATION_NOTES.md

इन files का केंद्र यही governance layer है।
ये section 12–13 के semantic objects पर आश्रित हैं, पर उनसे मिश्रित नहीं हैं।

चरण ११ — इस section की सीमाएँ

स्पष्ट रूप से यह भी लिखना चाहिए कि यह section अभी क्या नहीं करती।

अभी शेष
constitutional benchmark suite का full विस्तार
detailed graph query APIs
review frontend का expanded शासन रूप
retrieval disagreement dashboards
automated deployment health checks

ये आगे के sections में आयेंगे।

इस section के Python files

Exact file paths inside the full Page-2 Python bundle

• app/db/models/branch.py
• app/db/models/deployment.py
• app/schemas/branch.py
• app/schemas/deployment.py
• app/schemas/comparison.py
• app/repositories/branch_repo.py
• app/repositories/deployment_repo.py
• app/services/comparison_service.py
• app/services/promotion_service.py
• app/services/deployment_service.py
• app/api/routers/branches.py
• app/api/routers/deployments.py

निष्कर्ष

इस section का मर्म यह है कि semantic retrieval system का विकास केवल model training का प्रश्न नहीं।
वह शासन का प्रश्न भी है।

branch बिना registry के दिशाहीन होगी
comparison बिना benchmark के अधूरी होगी
promotion बिना rationale के हल्की होगी
shadow बिना discipline के व्यर्थ होगी
rollback बिना पूर्व-लिखित मार्ग के संकट बनेगी

अतः यह section project के लिये विकास-विधान का कार्य करती है।

उत्कर्ष

अब corrected sequence इस प्रकार आगे बढ़ती है:

source
normalization
segmentation
lexeme / sense / concept / role
assertions / rules
idempotency / dedup / confidence / benchmark
branch registry
promotion workflow
rollback workflow
benchmark comparison
shadow deployment

अब अगला स्वाभाविक section होगा:

Actual benchmark seed loader, constitutional benchmark suite, graph query APIs, और simple web review frontend

और वहाँ भी केंद्र यही रहेगा:

concept / role / relation / retrieval governance
न कि कोई संकीर्ण drift।

Actual benchmark seed loader, constitutional benchmark suite, graph query APIs, और simple web review frontend

concept / role / relation / retrieval governance को वास्तविक कार्य-रूप देने की विधि

भूमिका

अब तक system में यह सब बन चुका है:

source register
normalization branches
document और passage memory
lexeme / sense / corpus concept proposals
passage-role detection
discourse-form detection
assertion और rule assertion
idempotency
deduplication
confidence scoring
review context
प्रथम benchmark runner
branch registry
promotion workflow
rollback workflow
shadow deployment logic

किन्तु अभी भी एक महत्त्वपूर्ण कमी शेष रहती है।

यदि benchmark केवल database में हाथ से भरे गये records तक सीमित रहे,
यदि constitutional tests केवल सैद्धान्तिक चर्चा बनकर रह जायें,
यदि graph केवल export destination रहे और उससे actual queries न निकाली जायें,
और यदि review अभी भी raw JSON तक सीमित रहे,
तो project का बड़ा भाग practical scholarly use तक नहीं पहुँचेगा।

इसीलिए अब अगला अनिवार्य चरण है:

actual benchmark seed loader
constitutional benchmark suite
graph query APIs
simple web review frontend

यही वह स्तर है जहाँ backend engineering पहली बार scholar-facing usability की ओर बढ़ती है।

पूर्वपक्ष

Benchmark seed loader क्यों चाहिए?

यदि benchmarks केवल manually database में insert किये जायें, तो तीन हानियाँ होती हैं:

benchmark set reproducible नहीं रहता
versioning कठिन हो जाती है
branch comparison और deployment gating अनौपचारिक हो जाते हैं

अतः benchmark definitions को file-based, versioned, seedable रूप में रखना चाहिए।

seed loader का कार्य
JSONL seed file पढ़ना
existing benchmark check करना
duplicate seeds skip करना
new benchmarks insert करना
version-tag सुरक्षित रखना

यह छोटा कार्य दिखता है, पर governance layer को वास्तविक आकार यही देता है।

Constitutional benchmark suite अलग और स्पष्ट क्यों?

Ordinary benchmarks यह पूछती हैं:

expected role बना या नहीं
assertion निकली या नहीं
retrieval hit सही है या नहीं

किन्तु constitutional suite यह पूछती है:

primary corpus को constitutional priority मिली या नहीं
legal relation families ही main graph में हैं या नहीं
top-level semantic order dilute तो नहीं हुआ
mixed-zone flattening तो नहीं हुई
direct definition passages को narrative support ने अनुचित रूप से outrank तो नहीं किया

अतः constitutional suite ordinary benchmark का विस्तार नहीं; अलग शासन-स्तर है।

Graph query APIs क्यों अभी?

Graph export बन जाने मात्र से उपयोगिता सिद्ध नहीं होती।
Graph को पढ़ने, पूछने, और doctrinal neighborhoods देखने के लिये query APIs चाहिए।

scholar को क्या चाहिए?
किसी concept का neighborhood
किसी passage का graph profile
किसी cluster का semantic विस्तार
concept से जुड़े passages और roles
reviewed assertions का surrounding field

यदि यह न हुआ, तो Neo4j केवल backend storage बनकर रह जायेगा।

Simple web review frontend क्यों?

अब तक review APIs हैं, review context है, decisions हैं।
किन्तु यदि reviewer को सब raw JSON द्वारा ही करना पड़े, तो practical work धीमा और कष्टसाध्य होगा।

एक आरम्भिक web frontend पर्याप्त है यदि वह यह कर सके:

search
queue load
context view
decision buttons
reviewer note

अभी full production UI की आवश्यकता नहीं।
किन्तु minimal reviewer workbench अनिवार्य है।

उत्तरपक्ष

भ्रान्ति १

“Benchmark seeds बाद में डाल लेंगे; अभी manually काफी है।”

यह ठीक नहीं।
Manual benchmarks जल्दी ही अव्यवस्थित हो जाती हैं।
Versioned seed files से ही reproducibility बनी रहती है।

भ्रान्ति २

“Constitutional suite को अभी postpone कर दो।”

यह भी भूल है।
Ordinary benchmark पास करते हुए भी कोई branch constitutional drift ला सकती है।
अतः constitutional suite प्रारम्भिक चरण से ही उपस्थित होनी चाहिए, चाहे वह छोटी हो।

भ्रान्ति ३

“Graph APIs बाद में आयेंगी; अभी export ही पर्याप्त है।”

नहीं।
Graph का प्रारम्भिक लाभ inspection और exploration है।
यदि उससे प्रश्न ही नहीं किये जा सकते, तो उसका उपयोग आधा रह जायेगा।

भ्रान्ति ४

“Review frontend की आवश्यकता नहीं; API पर्याप्त है।”

यह केवल छोटे internal experiments के लिये सह्य है।
जैसे ही review volume बढ़ेगा, minimal web UI अत्यन्त उपयोगी सिद्ध होगी।

सन्धि

अतः समुचित रूप यह है:

seed loader benchmark memory को versioned और reproducible बनायेगा
constitutional suite सुधार को मर्यादा के भीतर रखेगी
graph query APIs graph को living exploratory layer बनायेंगी
simple web review frontend reviewer को usable workbench देगा

यही इस section का practical synthesis है।

सन्धान

अब actual corrected कार्य-विधि देता हूँ।

चरण १ — Benchmark seed files की रचना

Seed files को JSONL रूप में रखिये।
प्रत्येक line एक benchmark record हो।

recommended path
benchmarks/seeds/v1_core.jsonl
प्रत्येक seed record में fields
benchmark_type
name
description
priority
version_tag
benchmark_payload_json
Example benchmark types
role_exists
assertion_exists
constitutional_primary_priority_placeholder
constitutional_legal_relation_family
क्यों JSONL?

क्योंकि:

line-wise editing सरल है
version control में diff readable है
बड़े benchmark sets भी manageable रहते हैं

चरण २ — Seed loader script

एक standalone script हो जो:

seed file खोले
line-by-line JSON पढ़े
existing benchmark check करे
duplicate हो तो skip करे
नया हो तो insert करे
created / skipped count दे

यही loader benchmark memory को हाथ से भरी गयी अस्थिर तालिका से उठाकर वास्तविक reproducible infrastructure बनाती है।

इसका actual file

zip में:

scripts/seed_benchmarks.py

चरण ३ — Constitutional suite का प्रथम रूप

इस stage पर constitutional suite को अत्यधिक विशाल बनाने की आवश्यकता नहीं।
पहला रूप छोटा पर सिद्धान्ततः सही होना चाहिए।

Minimum constitutional tests
Test 1 — Primary priority placeholder

System में यह rule declared हो कि reviewed equivalent theme पर primary corpus को constitutional advantage होगा।

Test 2 — Legal relation family enforcement

Reviewed assertions में केवल allowed relation families हों।

allowed relation families के उदाहरण
defines
classifies
belongs_to
supports
contrasts_with
presupposes
is_exception_to
is_exemplified_by
is_glossed_by
is_temporally_related_to
is_spatially_related_to

यह अभी केवल आरम्भ है।
आगे:

mixed-zone preservation
direct evidence ordering
top-level trunk preservation
primary vs secondary ordering
operator sensitivity

जैसी tests भी जुड़ेंगी।

चरण ४ — Benchmark runner का corrected विस्तार

अब runner को केवल narrow extraction तक सीमित न रखकर role और constitutional tests तक बढ़ाइये।

runner को अभी यह करना चाहिए:
assertion_exists
role_exists
constitutional_primary_priority_placeholder
constitutional_legal_relation_family
summary में fields
total
passed
failed
constitutional_total
constitutional_passed
constitutional_pass
results

यही structure आगे branch comparison और deployment gating दोनों में प्रयुक्त होगा।

चरण ५ — Graph query APIs का corrected center

अब graph query APIs narrow astrological rule inspection तक सीमित नहीं रहेंगी।
वे concept / role / cluster centered होंगी।

API 1 — concept neighborhood

Input:

concept_id

Output:

concept से जुड़े passages
उन passages के roles
neighborhood evidence
API 2 — passage graph

Input:

passage_id

Output:

उस passage के concepts
roles
assertions
API 3 — cluster neighborhood

Input:

cluster_id

Output:

cluster के concepts
cluster के passages

यही corrected first graph exploration layer है।

चरण ६ — Neo4j read query design

अब graph queries को भी provenance-safe रखना चाहिए।

concept neighborhood query

Concept node से:

expressing passages
role nodes
limited neighborhood
passage graph query

Passage से:

expressed concepts
attached passage roles
assertion nodes
cluster neighborhood query

Cluster से:

member concepts
member passages
क्यों इतना conservative?

क्योंकि अभी early graph exploration है।
पहले readable, explainable, scholar-friendly neighborhood दीजिये।
Later complex path search जोड़िये।

चरण ७ — Simple web review frontend

अब एक minimal HTML frontend पर्याप्त है।

इसमें क्या होना चाहिए?
(क) Search box

passage search

(ख) Queue loader

object type चुनकर queue निकालना

(ग) Context panel

selected passage का review context

(घ) Reviewer controls
accept
accept_with_edit
reject
defer
(ङ) Reviewer note

free-text note

यह UI अभी production-level नहीं;
किन्तु scholarly review के लिये पहली usable surface है।

चरण ८ — Frontend object types

अब queue object types भी corrected center पर हों:

lexeme_mention
sense_assignment
concept_mention
passage_role
passage_form
assertion
rule_assertion

पुरानी narrow naming से बचना चाहिए।

चरण ९ — Review frontend और search का सम्बन्ध

Review UI में passage search होना चाहिए।
क्यों?

क्योंकि reviewer कई बार queue से नहीं, search से काम करना चाहेगा।

उदाहरण

यदि reviewer किसी doctrine, concept, या phrase की manually inspection करना चाहता है,
तो उसे direct passage search मिलना चाहिए।

इससे:

gold curation
benchmark verification
relation checking
cluster inspection

सब सुगम होंगे।

चरण १० — इस section के Python files

इस section के अलग zip में यह मुख्य files रखी गयी हैं:

Benchmarks
benchmarks/seeds/v1_core.jsonl
scripts/seed_benchmarks.py
app/repositories/benchmark_repo.py
app/services/benchmark_service.py
app/schemas/benchmark.py
Graph layer
app/graph/graph_queries.py
app/services/graph_query_service.py
app/api/routers/graph.py
app/schemas/graph.py
Review frontend
app/api/routers/review_ui.py
Documentation
SECTION_15_MANIFEST.md
INTEGRATION_NOTES.md

यह zip केवल section 15 के लिये है।
इसे section 12–14 के zip के साथ नहीं मिलाया गया है।

चरण ११ — यह section किन पूर्व sections पर निर्भर है?

यह section presuppose करती है कि पहले से यह मौजूद हैं:

benchmark models
passage table
concept table
passage role table
assertion table
review APIs
neo4j_client.py
basic graph export service

अर्थात् यह section foundational नहीं, बल्कि usability-and-governance expansion है।

चरण १२ — इस section की सीमाएँ

स्पष्ट रूप से यह भी लिखना चाहिए कि अभी क्या आगे रखा गया है।

अभी आगे शेष
advanced graph visualization UI
cluster browser UI
disagreement dashboards
constitutional SHACL frontend
authentication / role-based reviewer permissions
benchmark editing UI
retrieval evidence grouping UI

अतः यह section first usable surface देती है, पूर्ण mature scholarly platform नहीं।

इस section के Python files

Exact file paths inside the full Page-2 Python bundle

• app/graph/graph_queries.py
• app/services/graph_query_service.py
• app/api/routers/review_ui.py
• app/schemas/graph.py
• benchmarks/seeds/v1_core.jsonl
• scripts/seed_benchmarks.py

निष्कर्ष

इस section का corrected सार यह है:

यदि project को backend प्रयोग से आगे बढ़ाकर वास्तविक कार्य-तन्त्र बनाना है, तो:

benchmarks को seedable बनाना होगा
constitution को formal tests में उतारना होगा
graph को queryable बनाना होगा
review को minimal frontend देना होगा

इन्हीं चारों से system पहली बार ऐसी बनती है जिसे scholar, reviewer, और developer—तीनों व्यवहार में उपयोग कर सकें।

उत्कर्ष

अब corrected श्रृंखला इस प्रकार आगे बढ़ती है:

source
normalization
segmentation
lexeme / sense / concept / role
assertions / rules
idempotency / dedup / confidence / benchmark
branch registry / promotion / rollback / shadow
benchmark seed loader
constitutional suite
graph query APIs
simple web review frontend

अब अगला स्वाभाविक section होगा:

Editable review frontend, assertion editing endpoints, rule editing endpoints, passage search API, और first scholar-facing retrieval API

और वहाँ केंद्र होगा:

concept
role
relation
cluster
scholar retrieval
न कि कोई संकीर्ण drift।

Editable review frontend, assertion editing endpoints, rule editing endpoints, passage search API, और first scholar-facing retrieval API

concept / role / relation / cluster-centred scholarly workbench की वास्तविक रचना

भूमिका

अब तक की रचना में system के भीतर यह सब उपस्थित हो चुका है:

source register
normalization branches
document और passage memory
lexeme / sense / corpus concept proposals
passage-role detection
discourse-form detection
assertions और rule assertions
idempotency
deduplication
confidence scoring
review context
benchmark runner
branch registry
promotion workflow
rollback workflow
shadow deployment discipline
benchmark seed loader
constitutional benchmark suite
graph query APIs
simple web review frontend

किन्तु अभी system का reviewer और scholar-facing पक्ष अधूरा है।

अब भी reviewer यदि केवल accept / reject करे, पर actual semantic object को सुधार न सके, तो review अधूरी है।
यदि scholar केवल passage खोज सके, पर grouped doctrinal retrieval न मिले, तो retrieval अधूरी है।
यदि assertion गलत हो और उसे web surface से ही ठीक न किया जा सके, तो workflow भारी रहेगा।
यदि rule assertion का condition-json या scope logic सुधारना कठिन रहे, तो system की practical refinement धीमी होगी।

अतः अब अगला चरण यह है कि system reviewer और scholar—दोनों के लिये एक वास्तविक workbench बन सके।

इस section का ध्येय है:

यही वह स्थान है जहाँ system केवल reviewed memory नहीं, बल्कि एक usable intellectual instrument बनना प्रारम्भ करती है।

पूर्वपक्ष

Editable review frontend क्यों आवश्यक है?

Simple review frontend में queue, context, और accept / reject पर्याप्त थे।
किन्तु complete knowledge retrieval system में reviewer का कार्य इससे कहीं अधिक है।

Reviewer को कभी यह करना होगा:

गलत concept assignment बदलना
गलत passage-role ठीक करना
assertion का relation_type बदलना
wrong object concept सुधारना
rule assertion का polarity बदलना
condition या scope को refine करना
note जोड़ना
review status ठीक करना

यदि यह सब केवल backend edits द्वारा होगा, तो:

गति धीमी होगी
review flow टूटेगा
practical scholarly work कठिन होगा
और system पर विश्वास कम होगा

इसलिए editable frontend अनिवार्य है।

Editing endpoints अलग क्यों चाहिए?

बहुत-से लोग सोचते हैं कि reviewer UI में directly database update करा देंगे।
यह अनुचित है।

हर edit को:

validated होना चाहिए
typed request schema से गुजरना चाहिए
review history में अंकित होना चाहिए
fingerprint update करना चाहिए
review_status बदलना चाहिए
note के साथ सुरक्षित होना चाहिए

इसलिए editing के लिये पृथक endpoints चाहिए।

कौन-से मुख्य edit endpoints होंगे?
assertion edit
rule edit
concept mention edit
passage-role edit

आगे:

cluster membership edit
query interpretation edit
retrieval grouping edit

भी जोड़े जा सकते हैं।

Passage search API अभी भी क्यों आवश्यक है?

Review queue से मिलनेवाले objects पर्याप्त नहीं होते।
Scholars और reviewers दोनों को कई बार मुक्त रूप से passage search करनी होती है।

Search API के उपयोग
किसी शब्द / phrase की खोज
किसी concept family का manual inspection
benchmark gold set बनाना
relation verification
cluster boundary inspection
manuscript / recension तुलना
scholar note preparation

इसलिए एक सरल किन्तु reliable passage search API आवश्यक है।

यह search केवल exact match नहीं होगी।
यह:

text_raw
text_norm
text_search

इन textual views पर कार्य कर सके।

First scholar-facing retrieval API क्या करेगी?

यह अत्यन्त महत्त्वपूर्ण correction है।

Scholar-facing retrieval API का कार्य केवल search results लौटाना नहीं होगा।
उसे यह करना होगा:

query पढ़ना
lexical hits देना
probable concept candidates देना
optional graph expansion देना
concept-neighborhood के आधार पर related evidence दिखाना

अर्थात् यह एक first doctrinal retrieval surface होगी।

यह अभी embeddings या reranker वाली advanced layer नहीं होगी।
वह आगे आयेगी।
अभी यह section केवल इतना करेगी कि scholar query:

passages
concepts
graph-linked semantic hints

साथ में देख सके।

उत्तरपक्ष

भ्रान्ति १

“Simple review पर्याप्त है; editing बाद में जोड़ेंगे।”

यह व्यावहारिक रूप से गलत है।
जैसे ही system का semantic ladder थोड़ा समृद्ध होगा, reviewer को केवल yes/no से अधिक करना पड़ेगा।

भ्रान्ति २

“Passage search API तो ordinary database query है; इसे section का भाग क्यों बनायें?”

क्योंकि reviewer और scholar दोनों के लिये passage search एक मूलभूत कार्य है।
यदि वह ठीक नहीं बनी, तो retrieval और review दोनों असुविधाजनक रहेंगे।

भ्रान्ति ३

“Scholar-facing retrieval बाद में embeddings आने पर बनायेंगे।”

यह भी उचित नहीं।
पहला scholar-facing retrieval lexical + concept-neighborhood के साथ अभी से बनना चाहिए, ताकि interface और evidence grouping का प्रारम्भिक रूप विकसित हो।

भ्रान्ति ४

“Editing endpoints और review UI को अलग न रखो।”

नहीं।
UI surface और semantic update logic को अलग रखना ही सुरक्षित है।

सन्धि

अब सम्यक् synthesis यह है:

review frontend reviewer को usable कार्य-पटल देगा
editing endpoints structured, traceable semantic correction देंगे
passage search API मुक्त scholarly inspection देगी
scholar-facing retrieval API पहली बार concept-aware retrieval surface देगी

यही चार मिलकर system को backend experiment से आगे scholarly workbench में बदलते हैं।

सन्धान

अब actual corrected कार्य-विधि देता हूँ।

चरण १ — Editing schemas की रचना

हर editable semantic object के लिये पृथक request schema चाहिए।

१.१ AssertionEditRequest

इसमें fields होंगे:

assertion_type
subject_concept_id
relation_type
object_concept_id
value_literal
polarity
confidence
confidence_score
notes
reviewer_id
review_note
१.२ RuleEditRequest

यह अधिक जटिल होगा:

rule_kind
action_concept_id
result_concept_id
polarity
condition_json
scope_json
confidence
confidence_score
notes
reviewer_id
review_note
१.३ ConceptMentionEditRequest
concept_id
confidence
confidence_score
reviewer_id
review_note
१.४ PassageRoleEditRequest
role_name
confidence
confidence_score
reviewer_id
review_note

यह typed schema approach editing को uncontrolled mutation बनने से रोकती है।

चरण २ — Repository layer का corrected विस्तार

अब repositories को update methods देनी होंगी।

AssertionRepository
get_assertion
get_rule
update_assertion
update_rule
ConceptRepository
update_concept_mention
PassageRoleRepository
update_assignment

इन update methods का नियम यह होगा:

object लाओ
केवल provided fields बदलो
commit करो
refreshed object लौटाओ

यही minimal reliable pattern है।

चरण ३ — EditService का corrected कार्य

EditService इस section का semantic केन्द्र है।
UI सीधे database को नहीं छुएगी; वह service layer से ही गुजरेगी।

३.१ assertion editing

जब assertion edit हो:

existing assertion लाओ
updated fields लो
नया fingerprint बनाओ
assertion update करो
review record बनाओ
review_status = reviewed करो
३.२ rule editing

जब rule edit हो:

existing rule लाओ
condition_json और scope_json canonicalize करो
नया fingerprint बनाओ
rule update करो
review record बनाओ
status reviewed करो
३.३ concept mention editing
concept_id update
confidence update
review record create
review_status reviewed
३.४ passage role editing
role_name update
confidence update
review record create
review_status reviewed
क्यों service layer?

क्योंकि later:

validation
audit rules
benchmark hooks
branch-aware mutation control

यहीं जोड़े जायेंगे।

चरण ४ — Assertion editing की corrected semantic सावधानी

यहाँ एक महत्त्वपूर्ण सावधानी लिखना आवश्यक है।

Assertion अब entity-centric नहीं, बल्कि concept-centric होनी चाहिए।

अतः fields:

subject_concept_id
object_concept_id

होंगी।

यदि कोई पुराने code में subject_entity_id या object_entity_id थे, तो उन्हें अब धीरे-धीरे concept-based memory की ओर migrate किया जाना चाहिए।

यही corrected center है।

चरण ५ — Rule editing की corrected semantic सावधानी

RuleAssertion narrow specialist-rule store नहीं है।
यह corpus-wide scoped semantic rule structure है।

इसलिए reviewer को केवल accept नहीं, बल्कि इन सबको सुधारने की सुविधा होनी चाहिए:

rule kind
action concept
result concept
polarity
condition set
scope
उदाहरण

किसी rule का literal retrieval strong हो, पर उसका doctrinal scope गलत निकला हो।
तब केवल rejection उचित नहीं; edit बेहतर है।

चरण ६ — Passage search API की रचना

अब corrected passage search API का minimal रूप यह होगा:

Input
query
work_id optional
passage_types optional
limit
offset
Search fields
text_search
text_norm
text_raw
Output
passage_id
work_id
passage_type
chapter_no
verse_start
verse_end
text_norm
क्यों यही पर्याप्त प्रारम्भिक रूप है?

क्योंकि अभी scholar को passage locate करना है,
न कि full hybrid ranking लेना।
वह अगले स्तर में refined होगी।

चरण ७ — Scholar-facing retrieval API का corrected design

अब scholar-facing retrieval को corrected center पर रखते हैं।

यह API करेगी:

lexical passage hits
probable concept candidates
optional graph expansion
Input
query
work_id
limit
include_graph_expansion
preferred_roles
Output structure
query
preferred_roles
lexical_hits
concept_candidates
graph_expansion
preferred_roles क्यों?

क्योंकि scholar कभी specifically चाहेगा:

definitions
classifications
procedures
exceptions
narrative support

यह field future refinement का बीज है।

चरण ८ — RetrievalService का corrected centre

RetrievalService को अभी embeddings पर निर्भर नहीं बनाना चाहिए।
इस section में उसका आधार होगा:

SearchService
concept candidate lookup
GraphQueryService
retrieval flow
passage search
concept candidate search by canonical name
selected concept neighborhoods fetch करना
structured response देना

यह अभी simple है; किन्तु practical scholar-facing surface बनने के लिये पर्याप्त है।

चरण ९ — Simple review frontend का विस्तृत रूप

अब frontend को केवल accept/reject UI से थोड़ा आगे बढ़ाते हैं।

इसमें क्या होना चाहिए?
(क) Search box

user free-form passage search कर सके।

(ख) Queue loader

object type चुनकर pending queue निकाल सके।

(ग) Context panel

selected passage का full review context देख सके।

(घ) Decision controls
accept
accept_with_edit
reject
defer
(ङ) Generic edit JSON box

हाँ, अभी structured form controls नहीं;
पहले चरण में generic JSON editor पर्याप्त है।

(च) Edit submit button

जो correct edit endpoint पर request भेजे।

यह minimal किन्तु usable scholarly workbench है।

चरण १० — Frontend के object types

अब corrected queue object types हों:

concept_mention
passage_role
passage_form
assertion
rule_assertion

पुरानी entity_mention-main naming से अब बचना चाहिए।

हाँ, यदि legacy support हो, तो backend layer में रखा जा सकता है;
पर article और corrected main trunk अब concept / role पर ही रहे।

चरण ११ — Search और review का संयोग

यह section की एक बड़ी practical उपलब्धि है।

अब reviewer:

queue से item चुन सकता है
या search द्वारा किसी passage को manually खोज सकता है

यह gold curation, benchmark verification, और doctrinal inspection—तीनों के लिये अत्यन्त उपयोगी है।

चरण १२ — इस section के Python files

अलग zip में रखे गये मुख्य files यह हैं:

Schemas
app/schemas/edit.py
app/schemas/search.py
Repositories
app/repositories/passage_repo.py
app/repositories/assertion_repo.py
app/repositories/concept_repo.py
app/repositories/passage_role_repo.py
Services
app/services/edit_service.py
app/services/search_service.py
app/services/retrieval_service.py
Routers
app/api/routers/edit.py
app/api/routers/search.py
app/api/routers/review_ui.py
Documentation
SECTION_16_MANIFEST.md
INTEGRATION_NOTES.md

यह zip केवल section 16 के लिये है।
इसे earlier sections के साथ intentionally नहीं मिलाया गया।

चरण १३ — यह section किन पूर्व sections पर निर्भर है?

यह section presuppose करती है कि पहले से यह सब मौजूद है:

Passage model
CorpusConcept / PassageConceptMention
PassageRoleAssignment
Assertion / RuleAssertion
Review table
review context API
graph query service

अतः यह section foundational नहीं, बल्कि scholar-facing usability expansion है।

चरण १४ — इस section की सीमाएँ

स्पष्ट रूप से अभी क्या शेष है:

cluster editing UI
structured role-specific edit forms
retrieval evidence grouping UI
disagreement dashboard
embedding-based hybrid retrieval
reranker integration
role-filtered scholar interface
query interpretation editor

ये अगले sections में आयेंगे।

इस section के Python files

Exact file paths inside the full Page-2 Python bundle

• app/schemas/edit.py
• app/schemas/search.py
• app/services/edit_service.py
• app/services/search_service.py
• app/services/retrieval_service.py
• app/api/routers/edit.py
• app/api/routers/search.py

निष्कर्ष

इस section का corrected सार यह है:

यदि review केवल decision तक सीमित रही, तो refinement धीमी होगी।
यदि search केवल backend utility रही, तो scholars system को स्वाभाविक रूप से उपयोग नहीं कर सकेंगे।
यदि retrieval केवल raw passage list दे, तो doctrinal workbench नहीं बनेगी।

अतः अब यह आवश्यक था कि:

reviewer actual semantic objects को edit कर सके
scholar passages खोज सके
query से concept candidates देख सके
graph expansion का प्रारम्भिक रूप पा सके
और frontend minimal किन्तु usable हो

इसीसे system पहली बार backend architecture से आगे बढ़कर scholar-facing semantic workbench बनती है।

उत्कर्ष

अब corrected sequence इस प्रकार आगे बढ़ती है:

source
normalization
segmentation
lexeme / sense / concept / role
assertions / rules
idempotency / dedup / confidence / benchmark
branch / promotion / rollback / shadow
benchmark seeds / constitutional suite / graph queries / review frontend
assertion edit
rule edit
passage search
first scholar-facing retrieval

Embeddings, Re-ranker, Active Learning, और Hybrid Scoring

lexical retrieval, dense retrieval, graph expansion, और annotation discipline के संयुक्त संचालन की वास्तविक रचना

भूमिका

अब तक की रचना में system के भीतर यह सब बन चुका है:

source register
normalization branches
documents और passages
lexeme / sense / corpus concept proposals
passage-role detection
discourse-form detection
assertions और rule assertions
review context
benchmark discipline
branch governance
graph query APIs

किन्तु अभी भी retrieval की एक सीमा है।

अभी scholar-facing retrieval मुख्यतः:

lexical search
concept candidates
graph neighborhood hints

पर आधारित है। यह आवश्यक था, किन्तु पर्याप्त नहीं।
क्योंकि complete knowledge retrieval system में अनेक बार relevant passages ऐसे होते हैं जो:

exact शब्द नहीं रखते,
surface similarity कम रखते हैं,
पर doctrinal रूप से निकट होते हैं,
indirect support देते हैं,
या broader semantic field के भीतर आते हैं।

यहीं Embeddings, Re-ranker, Active Learning, और Hybrid Scoring की आवश्यकता प्रकट होती है।

किन्तु यहाँ एक महत्त्वपूर्ण मर्यादा प्रारम्भ में ही स्थापित करनी होगी:

embedding model सत्य का canonical स्रोत नहीं है।
reranker अंतिम प्रमाण नहीं है।
dense similarity doctrine का विकल्प नहीं है।

ये सब proposing layers हैं, governing layers नहीं।

इस section का ध्येय है:

semantic candidate generation को समृद्ध करना
retrieval quality बढ़ाना
reviewer burden को बुद्धिसंगत बनाना
active learning के द्वारा annotation को लक्ष्यवेधी बनाना
और final ranking को lexical, dense, rerank, graph, तथा constitutional संकेतों के संयुक्त आधार पर गढ़ना

यही इस section का हृदय है।

पूर्वपक्ष

Embeddings की वास्तविक भूमिका

आजकल अनेक लोग यह भूल करते हैं कि embeddings आते ही search “बुद्धिमान” हो गयी।
यह विचार भ्रामक है।

Embeddings का वास्तविक कार्य है:

semantic candidate generation
approximate conceptual proximity
wording variation के पार passage recall बढ़ाना
indirect relevance खोजने में सहायता

अतः embedding layer को इस project में यह अधिकार नहीं दिया जायेगा कि वह canonical truth घोषित करे। उसका कार्य केवल यह होगा कि वह passages के एक बड़े pool में से सम्भाव्य passages आगे रखे।

Embeddings किस पर बनें?

हमारे project में embeddings raw chapter पर नहीं, बल्कि passage units पर बनेंगी:

verse
verse_window_3
verse_window_7
chapter_block

प्रथम चरण में verse_window_3 practical रूप से अच्छा आरम्भिक unit है, क्योंकि:

single verse बहुत संक्षिप्त हो सकती है
chapter_block बहुत व्यापक हो सकता है
3-verse window में local context आता है
Embedding artifact क्यों store करना?

यदि हर query पर पूरी corpus का embedding फिर से बने, तो system व्यर्थ भारी हो जायेगी।
इसलिए embeddings को artifact रूप में disk पर store करना चाहिए, और metadata PostgreSQL में रखना चाहिए।

Re-ranker की आवश्यकता

Dense retrieval candidate generation बढ़ा देती है, पर ranking अभी भी पूरी तरह संतोषजनक नहीं होती।
कई passages semantically निकट लगते हैं, किन्तु scholar query के लिये सभी समान रूप से उपयोगी नहीं होते।

यहीं Re-ranker का कार्य आता है।

Re-ranker क्या करेगी?

वह query और candidate passage को pairwise देखकर यह निश्चय करेगी कि:

इस specific query के लिये कौन-सा passage अधिक उपयुक्त है

Dense model प्रायः passage-space में nearest neighbors देती है।
Re-ranker query-passage pair को अधिक सूक्ष्म दृष्टि से परखती है।

क्यों आवश्यक?

क्योंकि scholar query कई बार यह चाहती है:

direct definition
classification
doctrinal support
exception
narrative exemplum

Dense similarity इन भेदों को पर्याप्त सूक्ष्मता से नहीं पकड़ती।
Re-ranker ranking को sharpen करती है।

Active Learning क्यों इस section में?

क्योंकि जैसे ही embeddings और reranking आयेंगे, model-assisted retrieval का विस्तार होगा।
ऐसी दशा में annotation का प्रश्न और भी अधिक महत्वपूर्ण हो जाता है।

यदि हर passage हाथ से label करनी पड़े, तो आधा जीवन चला जायेगा।
यदि models को uncontrolled छोड़ दिया जाये, तो drift होगा।
इसलिए active learning वह मध्य-पथ है जिसमें system स्वयं वे passages आगे लाती है जो annotation के लिये सबसे अधिक उपयोगी हों।

कौन-से cases useful होंगे?
low confidence concept mentions
low confidence passage roles
low confidence assertions
low confidence rules
lexical vs dense disagreement
reranker vs reviewer-history disagreement
underrepresented works
constitutional-friction zones

अतः active learning review-burden घटाने का साधन नहीं मात्र;
वह learning-value को अधिकतम करने की विधि है।

Hybrid Scoring की आवश्यकता

यदि final ranking केवल lexical score पर आधारित हो, तो wording-bound system बन जायेगी।
यदि केवल dense score पर आधारित हो, तो semantic drift का भय बढ़ेगा।
यदि केवल reranker score पर आधारित हो, तो initial candidate recall कम हो सकती है।
यदि graph proximity जोड़ दें, तो structural support दिखेगी; पर graph early stage में sparse भी हो सकती है।

इसलिए final ranking का उचित मार्ग है hybrid scoring।

Hybrid score किनसे बने?
lexical score
dense score
rerank score
graph score
आगे चलकर constitutional trust score

इस section में हम पहला practical hybrid बनाएँगे।
Constitutional trust score को अभी explicit अलग term के रूप में न जोड़कर, बाद के sections में और refined किया जा सकता है।

उत्तरपक्ष

भ्रान्ति १

“अब embeddings आ गयीं, इसलिए earlier lexical / role / concept architecture गौण हो गयी।”

यह असत्य है।
Embedding layer पहले से बनी semantic architecture पर आश्रित proposing layer है; उसका स्थान उसके ऊपर नहीं।

भ्रान्ति २

“Dense retrieval enough है; reranker अनावश्यक है।”

नहीं।
Dense retrieval recall बढ़ाती है, पर ranking refinement के लिये reranker अभी भी अत्यन्त उपयोगी है।

भ्रान्ति ३

“Active learning बाद में जोड़ेंगे; पहले models train कर लें।”

यह अनुचित है।
Model training के साथ ही annotation pressure बढ़ता है।
यदि active learning न हो, तो review queue असंतुलित हो जायेगी।

भ्रान्ति ४

“Final score एक ही model से आ जाना चाहिए।”

यह modern simplicity का मोह है।
इस प्रकार के doctrinal retrieval system में final score बहु-स्रोत होना चाहिए।

सन्धि

अब सम्यक् संश्लेषण यह है:

Embeddings candidate field विस्तृत करती हैं
Re-ranker ranking को सूक्ष्म बनाती है
Active Learning annotation को लक्ष्यवेधी बनाती है
Hybrid Scoring विभिन्न संकेतों को एकत्र कर final ranking गढ़ती है

इन चारों का संयुक्त उपयोग ही उचित है।
इनमें से कोई एक अकेला इस project के लिये पर्याप्त नहीं।

सन्धान

अब actual corrected कार्य-विधि क्रमशः रखता हूँ।

चरण १ — Embedding artifact layer

इस section में प्रथम नयी table होगी:

passage_embedding_artifacts

इसका कार्य होगा:

किस document पर embedding बनी
किस model से बनी
किस passage_type पर बनी
artifact file कहाँ रखी गयी
कितनी rows हैं
embedding dimension क्या है
status क्या है
क्यों PostgreSQL metadata + disk artifact?

क्योंकि embedding matrix बड़ी होगी।
उसे सीधे canonical relational store में घुसाना उचित नहीं।
Disk artifact + DB metadata better practical arrangement है।

मुख्य fields
artifact_id
document_id
work_id
branch_id
model_name
passage_type
artifact_path
row_count
embedding_dim
status
notes

यही प्रथम embedding memory होगी।

चरण २ — Embedding build service

अब एक service चाहिए जो:

document_id ले
target passage_type चुने
उसी document के passages निकाले
text list बनाए
embedding model load करे
embeddings generate करे
artifact save करे
metadata DB में register करे
मुख्य सावधानियाँ
reviewed passage unit से पहले unreviewed text भी embed हो सकती है; embedding canonical truth नहीं है
artifact versioned होना चाहिए
rebuild होने पर metadata update होना चाहिए
branch_id सुरक्षित रहना चाहिए
प्रारम्भिक model

इस stage पर multilingual sentence embedding model पर्याप्त है।
अभी final doctrinal fine-tuning आवश्यक नहीं।

चरण ३ — Background build

Embedding build कई बार भारी होगी।
इसलिए API call synchronous होकर user को प्रतीक्षा कराने के बजाय background task में schedule हो सकती है।

इसका लाभ
frontend blocked नहीं होगा
document-wise embedding generation queue में चल सकती है
later large corpus sharding सम्भव होगी

चरण ४ — Reranker service

अब reranker service pairwise scoring के लिये होगी।

Input
query
candidate passage list
Output
same candidates
rerank_score_raw
sorted order
ध्यान

यह score अभी raw हो सकती है।
Later calibration की जा सकती है।
किन्तु प्रथम चरण में ranking उपयोग ही मुख्य है।

चरण ५ — Hybrid retrieval service

यह section का सबसे महत्त्वपूर्ण service-layer है।

इसका flow होगा:

५.१ Lexical layer

पहले ordinary passage search से lexical hits लाओ।

५.२ Dense layer

Embedding artifacts में query embedding चलाकर semantic hits लाओ।

५.३ Merge layer

Lexical और dense candidates merge करो।

५.४ Pre-rerank ordering

एक साधारण प्रारम्भिक combined score से top candidates चुनो।

५.५ Rerank layer

इन top candidates पर reranker चलाओ।

५.६ Final hybrid scoring

अब final score बनाओ:

lexical score
dense score
rerank score
graph score
क्यों graph score अभी शून्य भी हो सकता है?

क्योंकि early stage में graph retrieval हर passage पर usable नहीं होगी।
किन्तु field architecture अभी से रखी जाये।

चरण ६ — Active learning queue table

इस section की दूसरी प्रमुख table होगी:

active_learning_queue_items

यह store करेगी:

queue_type
passage_id
score
reason
payload_json
fingerprint
status
queue_type examples
uncertainty_concept
uncertainty_role
uncertainty_assertion
uncertainty_rule

Later जोड़ सकते हैं:

retrieval_disagreement
constitutional_boundary
cluster_split_candidate

चरण ७ — Uncertainty-based active learning

प्रथम practical active learning का आरम्भ uncertainty से कीजिये।

क्यों?

क्योंकि:

यह सरल है
direct है
reviewed semantic ladder से तुरन्त जुड़ती है
किस पर?
concept mentions
passage roles
assertions
rules
rule

यदि confidence_score < threshold
और review_status == needs_review
तो queue candidate बनाओ।

score

सामान्य रूप से:
1.0 - confidence_score

जितनी कम confidence, उतना ऊँचा annotation priority।

चरण ८ — Future active learning directions

इस section में अभी implement नहीं, पर architecture तैयार रहे:

disagreement-based selection
diversity-based selection
coverage-based selection
constitutional-friction selection

अभी first scaffold uncertainty-based रखो।
यही practical है।

चरण ९ — Updated search router

अब search router में एक नया endpoint जोड़ा जाये:

POST /search/hybrid

यह scholar-facing hybrid retrieval देगा।

Input
query
work_id
passage_type
dense_top_k
rerank_top_k
limit
Output
merged and reranked items
final hybrid_score

यही earlier scholar-facing retrieval API का अगला परिपक्व रूप होगा।

चरण १० — ML router

अब एक ml router होगा:

POST /ml/embeddings/build

जो embedding generation schedule करेगा।

यह API reviewer-facing नहीं, infrastructure-facing है।
किन्तु project के कार्य-प्रवाह में अत्यन्त उपयोगी है।

चरण ११ — Active learning router

अब एक पृथक router होगा:

POST /active-learning/build

specific queue build करेगा

GET /active-learning/pending

pending queue items देगा

यही review discipline और ML discipline को जोड़ेगा।

चरण १२ — इस section के Python files

अलग zip में रखे गये मुख्य files यह हैं:

Models
app/db/models/embedding.py
app/db/models/active_learning.py
Schemas
app/schemas/ml.py
app/schemas/active_learning.py
app/schemas/search.py
Repositories
app/repositories/embedding_repo.py
app/repositories/active_learning_repo.py
Services
app/services/embedding_service.py
app/services/reranker_service.py
app/services/hybrid_retrieval_service.py
app/services/active_learning_service.py
Routers
app/api/routers/ml.py
app/api/routers/active_learning.py
app/api/routers/search.py
Documentation
SECTION_17_MANIFEST.md
INTEGRATION_NOTES.md

यह zip केवल section 17 के लिये है।
इसे earlier sections के zip के साथ intentionally नहीं मिलाया गया।

चरण १३ — इस section की dependencies

यह section presuppose करती है कि पहले से यह modules मौजूद हैं:

config.py with artifact/model paths
document_repo.py
passage_repo.py
search_service.py
graph_query_service.py
fingerprints.py
earlier semantic ladder tables

अतः यह section foundation नहीं, बल्कि retrieval-strengthening expansion है।

चरण १४ — इस section की सीमाएँ

स्पष्ट रूप से अभी क्या आगे रखा गया है:

multilingual reranker fine-tuning
embedding model fine-tuning
disagreement queues
constitutional trust score as separate term
graph-aware rerank enhancement
query interpretation aware hybrid routing
cluster-guided active learning

अतः यह section first practical ML-assisted retrieval देती है; final mature retrieval ecology नहीं।

इस section के Python files

Exact file paths inside the full Page-2 Python bundle

• app/core/retrieval_defaults.py
• app/db/models/embedding.py
• app/db/models/active_learning.py
• app/schemas/ml.py
• app/schemas/active_learning.py
• app/repositories/embedding_repo.py
• app/repositories/active_learning_repo.py
• app/services/embedding_service.py
• app/services/reranker_service.py
• app/services/hybrid_retrieval_service.py
• app/services/active_learning_service.py
• app/api/routers/ml.py
• app/api/routers/active_learning.py

निष्कर्ष

इस section का सार यह है:

यदि system को केवल lexical + graph hints तक सीमित रखा जाये, तो वह doctrinal retrieval में शीघ्र अपनी सीमा पर पहुँच जायेगी।
यदि dense retrieval को बिना constitutional discipline के छोड़ दिया जाये, तो drift होगा।
यदि reranker न हो, तो ranking dull रहेगी।
यदि active learning न हो, तो annotation pressure अनियन्त्रित होगा।
यदि hybrid scoring न हो, तो system एक ही संकेत पर निर्भर होकर असंतुलित हो जायेगी।

अतः:

embeddings candidate field खोलती हैं
reranker ranking सुधरती है
active learning annotation discipline बनाती है
hybrid scoring final retrieval balance गढ़ती है

इन्हीं के संयोग से system एक अधिक सक्षम scholar-facing retrieval यन्त्र बनती है।

उत्कर्ष

अब corrected sequence इस प्रकार आगे बढ़ती है:

source
normalization
segmentation
lexeme / sense / concept / role
assertions / rules
idempotency / dedup / confidence / benchmark
branch / promotion / rollback / shadow
benchmark seeds / constitutional suite / graph queries / review frontend
editable review / search / scholar retrieval
embeddings
reranker
active learning
hybrid scoring

Training data export, embedding training / fine-tuning set, reranker training set, और disagreement-based active learning

reviewed semantic memory को वास्तविक training corpus में बदलने की विधि

भूमिका

अब तक की corrected रचना में system के भीतर यह सब उपस्थित हो चुका है:

source register
normalization branches
document और passage memory
lexeme / sense / corpus concept proposals
passage-role detection
discourse-form detection
assertions और rule assertions
review context
benchmark discipline
branch governance
graph query APIs
scholar-facing retrieval API
embeddings
reranker
active learning का प्रथम uncertainty-based रूप
hybrid scoring

किन्तु अभी एक बड़ा अंतर शेष है।

अब तक system में reviewed semantic memory है, पर वह अभी तक पूर्ण अर्थ में training corpus नहीं बनी।
हाँ, reviewed passages हैं।
हाँ, corrected assertions हैं।
हाँ, benchmarked retrieval traces हैं।
किन्तु यदि इन्हें structured export में नहीं बदला गया, तो:

embedding model को क्या सिखाया जाये?
reranker को positive / hard negative pairs कहाँ से मिलेंगे?
passage-role classifier के लिये stable labels कैसे बनेंगे?
relation extractor किस reviewed memory पर fine-tune होगी?
disagreement-based active learning किन आधारों पर चलेगी?

इसीलिए अब अगला आवश्यक चरण है:

training data export
embedding training / fine-tuning set
reranker training set
disagreement-based active learning

यही वह स्तर है जहाँ reviewed semantic memory पहली बार actual model ecology को खिलाने लगती है।
यह project को केवल retrieval उपयोगिता से उठाकर self-improving but constitution-bound learning system की ओर ले जाती है।

पूर्वपक्ष

Training data export क्यों अनिवार्य है?

यदि reviewed semantic objects केवल database के भीतर पड़े रहें, तो वे:

retrieval में सहायक तो होंगे,
review history भी देंगे,
पर training corpus नहीं बनेंगे।

किसी model को सुधारने के लिये data को उस रूप में निर्यात करना पड़ता है जो उसके training objective से मेल खाये।

अलग-अलग models के लिये अलग data चाहिए
passage-role classifier को labeled passages चाहिए
assertion extractor को typed assertion targets चाहिए
reranker को query-passage positive / negative pairs चाहिए
embedding model को conceptually coherent positives चाहिए
disagreement-based active learning को multi-score conflict traces चाहिए

अतः “एक ही dataset सबके लिये” यहाँ ठीक नहीं।

export का अर्थ

Training export का अर्थ केवल CSV dump नहीं है।
वह यह है कि reviewed semantic memory को इस प्रकार निकाला जाये कि:

model-specific उपयोग सम्भव हो
provenance नष्ट न हो
later reproducibility बनी रहे
benchmark और training data में भेद स्पष्ट रहे

Embedding training / fine-tuning set का यथार्थ रूप

Embedding model का कार्य इस project में canonical truth देना नहीं, बल्कि:

semantic candidate generation
recall improvement
indirect relevance discovery

है।
इसलिए उसके लिये training set ऐसी होनी चाहिए जिसमें query और relevant passage families के बीच सकारात्मक निकटता निर्मित हो।

किस प्रकार की records उपयोगी होंगी?
query → reviewed relevant passages
concept name → definitional / classificatory passages
doctrinal phrase → primary passages
lexical variants → same concept family passages
narrative-doctrine bridge cases
embedding dataset का logic

यदि किसी query के लिये अनेक reviewed passages top evidence मानी गयी हैं, तो embedding fine-tuning set में:

वही passages positives बन सकती हैं
अन्य unrelated passages negatives नहीं, बल्कि future hard negatives pool का स्रोत बन सकती हैं

इसलिए embedding dataset simple binary नहीं;
वह positive support bundle की तरह अधिक उपयोगी है।

Reranker training set का यथार्थ रूप

Reranker pairwise judgment सीखती है।
उसे यह नहीं सीखना कि passage-space में कौन निकट है;
उसे यह सीखना है कि:

given a query, among many plausible passages, कौन-सा अधिक उपयुक्त है?

इसीलिए reranker dataset का मुख्य रूप होगा:

query
one positive passage
several hard negatives
hard negatives कहाँ से आयें?

यही सबसे सूक्ष्म बिन्दु है।

Hard negatives वे passages होंगी जो:

lexical रूप से निकट हों,
dense retrieval में ऊपर आयी हों,
पर reviewer ने उन्हें final evidence के रूप में lower value दिया हो,
या evidence-type ordering में नीचे रखा हो।

यही reranker को sharpen करेगा।

यदि hard negatives न हों

तो reranker shallow बन जायेगी।
वह केवल obvious positives सीखेगी, कठिन doctrinal distinction नहीं।

Disagreement-based active learning क्यों अगला आवश्यक चरण है?

Section 17 में uncertainty-based queue बनाई गयी थी।
वह उचित पहला चरण था।
अब अगला चरण है disagreement।

क्योंकि कई बार model confident होती है, फिर भी गलत होती है।
विशेषतः तब जब:

lexical retrieval कुछ और कहे,
dense retrieval कुछ और,
reranker कुछ और,
reviewer history कुछ और,
branch comparison कुछ और संकेत दे।

ऐसी दशा में केवल low confidence पर्याप्त संकेतक नहीं।
यहीं disagreement-based active learning आवश्यक है।

disagreement किनके बीच देखा जाये?
lexical score vs dense score
dense score vs rerank score
rerank score vs final hybrid score
reviewer history vs current retrieval ordering
role classifier vs discourse-form signal
assertion proposal vs reviewed relation family

ये disagreements annotation के लिये अत्यन्त शिक्षाप्रद होती हैं।

उत्तरपक्ष

भ्रान्ति १

“Reviewed database ही training corpus है; अलग export की क्या आवश्यकता?”

यह अधूरा विचार है।
Database human-facing canonical store है।
Training corpus model-facing structured export है।
दोनों का रूप अलग होगा।

भ्रान्ति २

“Embedding और reranker दोनों को एक ही JSONL से train कर देंगे।”

यह भी गलत है।
दोनों के उद्देश्यों में भेद है:

embedding = semantic proximity / candidate generation
reranker = fine relevance ordering

अतः dataset design भी अलग होगा।

भ्रान्ति ३

“Uncertainty-based active learning पर्याप्त है।”

प्रारम्भिक रूप में हाँ;
पर mature retrieval system में disagreement cases अधिक शिक्षाप्रद होती हैं, क्योंकि वे model ecology के भीतर conflict प्रकट करती हैं।

भ्रान्ति ४

“Reviewed positives पर्याप्त हैं; negatives बाद में देखेंगे।”

नहीं।
विशेषतः reranker के लिये hard negatives अभी से चाहिए।
वरना ranking dull रहेगी।

सन्धि

अतः सम्यक् संश्लेषण यह है:

training export reviewed semantic memory को model-usable रूप में बदलेगा
embedding dataset builder semantic support bundles बनाएगा
reranker dataset builder query-positive-hard negative संरचना देगा
disagreement-based active learning उन passages को आगे लायेगी जहाँ model ecology के भीतर संघर्ष है

इन्हीं चारों के संयोग से reviewed corpus पहली बार वास्तविक training engine को पोषित करती है।

सन्धान

अब actual corrected कार्य-विधि देता हूँ।

चरण १ — Training export types की सूची

सबसे पहले export types स्पष्ट कीजिये।
एक ही export mode पर्याप्त नहीं।

प्रारम्भिक export types
passage_roles
assertions
rules
retrieval_pairs
passage_roles

passage-level role classifier training के लिये

assertions

typed assertion extraction या evaluation के लिये

rules

rule assertion / structured condition learning के लिये

retrieval_pairs

embedding और reranker preparation के लिये

यही first useful division है।

चरण २ — TrainingRepository का corrected कार्य

अब एक dedicated repository चाहिए जो reviewed semantic memory को structured रूप में निकाले।

उसे क्या fetch करना होगा?
(क) reviewed passage roles
passage_id
work_id
text_norm
role_name
(ख) reviewed assertions
assertion_id
passage_id
text_norm
subject_concept_id
relation_type
object_concept_id
value_literal
(ग) reviewed rules
rule_id
passage_id
text_norm
rule_kind
action_concept_id
result_concept_id
condition_json
scope_json
polarity
(घ) retrieval pairs
query_id
raw_query
passage_id
text_norm
evidence_type
hybrid_score

यही later dataset builders का आधार बनेगा।

चरण ३ — TrainingExportService

अब एक service चाहिए जो:

export_type ले
उचित repository method चुने
JSONL file लिखे
output path return करे
count बताए
यह JSONL क्यों?

क्योंकि:

model training pipelines के लिये अनुकूल है
line-wise streaming सम्भव है
बड़े corpus पर manageable है
git / diff और audit के लिये readable है
output discipline

हर export run clearly versioned path में जानी चाहिए, जैसे:

artifacts/training_exports/passage_roles.jsonl
artifacts/training_exports/assertions.jsonl
artifacts/training_exports/rules.jsonl
artifacts/training_exports/retrieval_pairs.jsonl

चरण ४ — Embedding dataset builder

अब reviewed retrieval traces को embedding training / fine-tuning set में बदलना होगा।

इसका practical rule

प्रत्येक query के लिये top reviewed or high-hybrid passages को positives बनाइये।

output record का आरम्भिक रूप
query
positives

यह अभी minimal है, किन्तु usable है।

later refinement

आगे:

concept family tags
direct vs indirect evidence separation
primary vs secondary weighting
role filtering

जोड़े जा सकते हैं।

क्यों अभी simple?

क्योंकि पहले positive support bundles चाहिए।
Complex triplets बाद में refined किये जा सकते हैं।

चरण ५ — Reranker dataset builder

अब retrieval pairs को reranker dataset में बदलिए।

input

reviewed or high-quality retrieval traces

output
query
positive
negatives
negatives कहाँ से?

उसी query के lower-ranked, yet plausible passages से।
यही hard negatives का प्रथम व्यावहारिक रूप है।

negatives_per_query

एक configurable field रहे, जैसे:

3
5
10

प्रथम चरण में 5 पर्याप्त है।

क्यों?

क्योंकि reranker pairwise discrimination पर जीती है।
उसे obvious noise नहीं, बल्कि tempting but wrong passages चाहिए।

चरण ६ — DisagreementRepository

अब एक repository चाहिए जो retrieval traces में conflict ढूँढ सके।

उसे क्या fetch करना होगा?

कम से कम:

item_id
passage_id
text_norm
lexical_score
dense_score
rerank_score
hybrid_score

यही disagreement detection का आधार है।

चरण ७ — Disagreement-based active learning service

अब एक service बने जो:

retrieval items लाये
lexical / dense / rerank scores की spread देखे
gap compute करे
यदि gap threshold से अधिक हो, तो active learning candidate बनाए
disagreement gap

max(scores) - min(scores)

यदि gap बड़ा है

तो इसका अर्थ है कि model ecology एकमत नहीं है।
ऐसा passage annotation के लिये महत्त्वपूर्ण है।

queue record में क्या हो?
queue_type = retrieval_disagreement
passage_id
score = gap
reason
payload_json
fingerprint
status

यही section 17 की uncertainty queue का अगला परिपक्व रूप है।

चरण ८ — Preview mode और insert mode

प्रथम चरण में disagreement service दो modes में useful हो सकती है।

Preview mode

केवल बताए:

कितने disagreement candidates हैं
Insert mode

यदि queue repository दी गयी है, तो actual queue items insert करे

यह distinction practical है।

चरण ९ — Training router

अब एक नया router चाहिए:

POST /training/export

generic export

POST /training/build-embedding-dataset

embedding fine-tuning set

POST /training/build-reranker-dataset

reranker set

इससे training data generation backend scripts तक सीमित नहीं रहेगी; API-driven भी हो सकेगी।

चरण १० — Updated active learning router

अब एक नया endpoint जुड़ना चाहिए:

POST /active-learning-v2/build-disagreement

यह disagreement-based queue बनाएगा।

यह old uncertainty queue का replacement नहीं, expansion है।

चरण ११ — इस section के Python files

अलग zip में रखे गये मुख्य files यह हैं:

Schemas
app/schemas/training.py
app/schemas/active_learning.py
Repositories
app/repositories/training_repo.py
app/repositories/disagreement_repo.py
Services
app/services/training_export_service.py
app/services/embedding_dataset_builder.py
app/services/reranker_dataset_builder.py
app/services/disagreement_active_learning_service.py
Routers
app/api/routers/training.py
app/api/routers/active_learning.py
Scripts
scripts/export_training_data.py
Documentation
SECTION_18_MANIFEST.md
INTEGRATION_NOTES.md

यह zip केवल section 18 के लिये है।
इसे earlier section zips के साथ intentionally नहीं मिलाया गया।

चरण १२ — इस section की dependencies

यह section presuppose करती है कि पहले से यह सब मौजूद हैं:

reviewed passage roles
reviewed assertions
reviewed rule assertions
query interpretations
retrieval runs
retrieval evidence groups
retrieval group items
active learning queue table
fingerprints utility

अर्थात् यह section तभी अर्थपूर्ण है जब semantic memory पहले से काफ़ी हद तक reviewed हो चुकी हो।

चरण १३ — इस section की सीमाएँ

स्पष्ट रूप से अभी क्या आगे शेष है:

embedding triplet dataset refinement
multilingual reranker fine-tuning protocol
classifier training branches
relation extractor fine-tuning
graph specialist models
coverage-based and diversity-based active learning
constitutional-friction queue
full training run orchestration

अतः यह section training corpus construction का प्रारम्भ है; पूरा training ecosystem नहीं।

इस section के Python files

Exact file paths inside the full Page-2 Python bundle

• app/schemas/training.py
• app/repositories/training_repo.py
• app/repositories/disagreement_repo.py
• app/services/training_export_service.py
• app/services/embedding_dataset_builder.py
• app/services/reranker_dataset_builder.py
• app/services/disagreement_active_learning_service.py
• app/api/routers/training.py
• scripts/export_training_data.py

निष्कर्ष

इस section का corrected सार यह है:

जब तक reviewed semantic memory training-ready export में न बदले,
तब तक:

embedding सुधार सीमित रहेगी
reranker गहराई नहीं पकड़ेगी
model ecology reviewer-history से नहीं सीखेगी
active learning केवल uncertainty तक सीमित रहेगी

अतः अब यह अनिवार्य था कि:

reviewed data structured export बने
embedding positives तैयार हों
reranker hard negatives बने
disagreement-based queues उठें

इसीसे system पहली बार reviewed corpus → trainable corpus → improved retrieval के चक्र में प्रवेश करती है।

उत्कर्ष

अब corrected sequence इस प्रकार आगे बढ़ती है:

source
normalization
segmentation
lexeme / sense / concept / role
assertions / rules
idempotency / dedup / confidence / benchmark
branch / promotion / rollback / shadow
benchmark seeds / constitutional suite / graph queries / review frontend
editable review / search / scholar retrieval
embeddings / reranker / active learning / hybrid scoring
training data export
embedding fine-tuning set
reranker training set
disagreement-based active learning

Dynamic redesign protocol, redesign levels, branching policy, promotion gate, और corpus से “ancient sensibility” सीखने की विधि

constitution के अधीन self-restructuring knowledge architecture की वास्तविक रचना

भूमिका

अब तक की corrected रचना में system के भीतर यह सब उपस्थित हो चुका है:

source register
normalization branches
document और passage memory
lexeme / sense / corpus concept proposals
passage-role detection
discourse-form detection
assertions और rule assertions
benchmark discipline
branch governance
graph queries
scholar-facing retrieval
embeddings
reranker
active learning
hybrid scoring
training-data export
embedding और reranker training sets
disagreement-based active learning

यह सब मिलकर system को एक जीवित ज्ञान-यन्त्र बनाते हैं।
किन्तु अभी भी एक अत्यन्त सूक्ष्म और निर्णयकारी प्रश्न शेष है:

जब system स्वयं को बदलना आरम्भ करेगी, तब उसे कौन बाँधेगा?

यही इस section का विषय है।

यदि dynamic redesign को खुला छोड़ दिया गया, तो system:

नये labels बनायेगी,
concepts को चुपचाप split और merge करेगी,
graph में नये edge families लायेगी,
retrieval routing बदल देगी,
और धीरे-धीरे modern convenience या model bias के अधीन drift करने लगेगी।

यदि dynamic redesign को पूरी तरह रोक दिया गया, तो system:

जड़ हो जायेगी,
कठिन passages से सीख नहीं सकेगी,
under-broad concepts को refine नहीं कर सकेगी,
और corpus से वास्तविक “ancient sensibility” ग्रहण नहीं कर सकेगी।

अतः यहाँ एक मध्य-विधान चाहिए:

plasticity हो
पर constitution के भीतर हो
redesign हो
पर versioned branch में हो
induction हो
पर blind statistics से नहीं, reviewed structure से हो
नये distinctions उभरें
पर uncontrolled canonization न हो

इसीलिए इस section का ध्येय है:

dynamic redesign protocol
redesign levels
branching policy
promotion gate
structural invariant induction
main corpus से “ancient sensibility” सीखने की विधि

यही इस project का वास्तविक हृदय है।

पूर्वपक्ष

Dynamic redesign का यथार्थ अर्थ

Dynamic redesign का अर्थ uncontrolled self-modification नहीं है।
इसका अर्थ यह है कि system failure, review, benchmark, disagreement, और reviewed corpus patterns से सीखकर अपनी आन्तरिक रचना में versioned परिवर्तन प्रस्तावित कर सके।

redesign किन बातों में हो सकता है?
retrieval routing
label refinement
normalization refinement
ontology split / merge
model replacement
graph schema addition
किन बातों में नहीं?
constitution की top-level जड़ों में silent परिवर्तन
primary corpus के canonical अर्थ का बिना review पुनर्लेखन
gold labels का automatic replacement
secondary corpus के आधार पर primary law का उलटाव

अतः dynamic redesign को “plasticity under law” के रूप में समझना चाहिए।

Redesign levels क्यों आवश्यक हैं?

यदि हर परिवर्तन को समान महत्त्व दिया जाये, तो governance अव्यवस्थित हो जायेगी।
किसी score-weight को थोड़ा बदलना और top-level ontology trunk को बदलना—दोनों समान नहीं हो सकते।

इसीलिए redesign levels आवश्यक हैं।

Level 0 — Retrieval routing

यह सबसे हल्का स्तर है।
यहाँ परिवर्तन होंगे:

score weights
query routing
expansion policy
graph vs lexical balance

यह local व्यवहार बदलता है, constitution नहीं।

Level 1 — Label refinement

यहाँ:

labels जोड़ना
near-duplicates merge करना
role vocabulary refine करना

यह semantic refinement है, पर अभी trunk-level परिवर्तन नहीं।

Level 2 — Normalization redesign

यहाँ:

Unicode cleaning सुधारना
segmentation सुधारना
heading / chapter boundary detection सुधारना
canonical text views सुधारना

यह textual substrate को छूता है, इसलिए अधिक सावधानी चाहिए।

Level 3 — Ontology redesign

यहाँ:

किसी concept को split करना
दो concepts merge करना
नया sub-concept प्रस्तावित करना

यह बहुत गंभीर स्तर है, क्योंकि इससे retrieval, graph, और benchmarks—सब प्रभावित होंगे।

Level 4 — Model redesign

यहाँ:

नया passage-role model
नया concept model
नया relation extractor
नया reranker
नया cluster builder

आदि आते हैं।

Level 5 — Graph schema redesign

यह सबसे कठोर स्तरों में से एक है।
यहाँ:

नया node type
नया edge family
नया graph pattern
नया evidence structure

जोड़ा जा सकता है।

सिद्धान्त

जितना ऊँचा level, उतनी कठोर promotion test।

Branching policy का corrected स्वरूप

Dynamic redesign केवल branch में ही होनी चाहिए।
कभी भी live canonical memory में silent mutation नहीं।

उदाहरण branch names
retrieval_branch_fusion_v3
label_branch_role_refine_v2
norm_branch_boundary_fix_v5
ontology_branch_kala_split
model_branch_relation_v4
graph_branch_rule_edges_v2
इसका लाभ
हर redesign traceable होगी
comparison सम्भव होगा
rollback सम्भव होगा
benchmark discipline intact रहेगा
reviewer को पता रहेगा कि कौन-सा परिवर्तन किस branch से आया
नीतिगत वाक्य

No silent mutation.
यही branching policy का मूल नियम है।

Promotion gate क्यों अलग से सोचना होगा?

Section 14 में branch promotion law बन चुकी थी।
किन्तु redesign branches के लिये gate और कठोर होगा।

क्योंकि अब branch केवल “better model” नहीं, बल्कि “changed architecture” भी हो सकती है।

redesign gate किन आधारों पर होगा?
benchmark recall सुधरी या नहीं
noise threshold के भीतर है या नहीं
SHACL legality बनी रही या नहीं
constitutional queries regress हुईं या नहीं
reviewer change को interpret कर सकता है या नहीं

यदि ये सब संतोषजनक नहीं, तो redesign branch sandbox में ही रहेगी।

“Ancient sensibility” सीखने का प्रश्न

अब इस section का सबसे सूक्ष्म भाग आता है।

यदि system से पूछा जाये कि वह main corpus से “ancient sensibility” कैसे सीखेगी, तो उत्तर केवल keyword frequency नहीं हो सकता।
यह project का निर्णायक बिन्दु है।

“Ancient sensibility” का अर्थ यहाँ होगा:

recurring discourse forms
concept families जो अनेक works में coherent रहती हैं
स्थिर विरोध-जोड़ियाँ जैसे:
visible / invisible
manifest / unmanifest
binding / non-binding
narrative-doctrine transfer patterns
time-order की केन्द्रीयता
classification की केन्द्रीयता
cosmic entities और human action के बीच recurring mappings

अर्थात् system को corpus से structural invariants ग्रहण करने होंगे, केवल surface word counts नहीं।

उत्तरपक्ष

भ्रान्ति १

“Corpus अपने-आप सब सीख लेगी।”

यह सुनने में अच्छा लगता है, पर व्यवहार में यह गलत है।
यदि raw corpus statistics को अकेले निर्णायक बना दिया गया, तो system सीखेगी:

OCR distortions
repetition artifacts
genre imbalance
redaction bias
file-order noise

अतः corpus source है, पर sole judge नहीं।
Judge = corpus under constitution.

भ्रान्ति २

“पूरी corpus पर एक बड़ा model fine-tune कर दो; वही सब सीखेगा।”

यह भी उचित नहीं।
इससे fluent latent blur बनेगा, controlled architecture नहीं।
हमारी समस्या generation नहीं, बल्कि:

segmentation
extraction
graph formation
ontology growth
constitutional coherence
high-recall retrieval

है।
अतः giant monolith इस stage का समाधान नहीं।

भ्रान्ति ३

“Graph सब कुछ day one से बना दो।”

यदि extraction दूषित हुई, तो graph दूषित होगी।
Graph authoritative दिखाई देती है, इसलिए bad edges बहुत खतरनाक होती हैं।
अतः graph growth भी reviewed assertions और controlled redesign के अधीन ही होनी चाहिए।

भ्रान्ति ४

“Dynamic redesign = uncontrolled self-training”

यही सबसे बड़ा खतरा है।
यदि uncontrolled self-training हुई, तो system:

नये clusters बनायेगी,
नये relations invent करेगी,
और धीरे-धीरे उन्हें scripture-adjacent truth की तरह मानने लगेगी।

यह कभी नहीं होने देना चाहिए।

सन्धि

अतः सम्यक् synthesis यह है:

redesign की अनुमति होगी
पर branch में होगी
redesign levels होंगे
हर level की अलग कठोरता होगी
promotion gate होगा
“ancient sensibility” keyword-count से नहीं, structural invariants से सीखी जायेगी
induction reviewed primary corpus से होगी
secondary corpus amendment proposer रहेगी, ruler नहीं

यही self-restructuring पर constitution की विजय है।

सन्धान

अब वास्तविक corrected कार्य-विधि क्रमशः रखता हूँ।

चरण १ — Redesign proposal layer

अब एक नई canonical table चाहिए:

redesign_proposals

इसका कार्य होगा:

redesign का नाम
redesign level
source branch
target branch name
proposal JSON
rationale
status
created_by
fields का प्रारम्भिक रूप
redesign_id
redesign_name
redesign_level
source_branch_id
target_branch_name
proposal_json
rationale
status
created_by
status values
proposed
eligible_for_branch
kept_in_sandbox
later:
promoted
rejected

यही redesign memory होगी।

चरण २ — Structural invariant layer

अब एक दूसरी table चाहिए:

structural_invariants

यही वह स्थान है जहाँ main corpus से सीखे गये recurring structural patterns safe रूप में store होंगे।

fields
invariant_id
invariant_name
invariant_type
evidence_json
confidence
review_status
notes
invariant types के उदाहरण
recurring_discourse_form
stable_opposition
concept_family_coherence
narrative_doctrine_transfer
time_order_centrality
classification_centrality
cosmic_human_mapping

ये invariants later:

redesign proposals
ontology split suggestions
cluster refinements
constitutional checks

में प्रयुक्त होंगी।

चरण ३ — RedesignService

अब एक service बने जो redesign proposal create करे।

Input
redesign_name
redesign_level
source_branch_id
target_branch_name
proposal_json
rationale
created_by
Output
redesign_id
redesign_name
redesign_level
status

यह service अभी branch create नहीं करेगी।
पहले proposal memory बनेगी।

चरण ४ — Gate check service

अब एक second-stage method चाहिए जो redesign proposal पर gate check लगाए।

Input
redesign_id
constitutional_pass
reviewer_interpretable
noise_within_threshold
Rule

यदि:

constitutional_pass = true
reviewer_interpretable = true
noise_within_threshold = true

तो:

eligible_for_branch

अन्यथा:

kept_in_sandbox

यह प्रारम्भिक gate है।
आगे benchmark_run_id, SHACL reports, regression summaries भी जोड़े जा सकते हैं।

चरण ५ — Sensibility induction service

अब “ancient sensibility” को actual record में बदलने के लिये एक service चाहिए।

यह क्या करेगी?
invariant_name लेगी
invariant_type लेगी
evidence_json लेगी
confidence और notes लेगी
structural_invariants table में store करेगी
क्यों आवश्यक?

क्योंकि यदि structural patterns केवल prose notes में रह गये, तो:

later redesign उनसे नहीं सीखेगी
benchmark उनसे नहीं बनेगी
ontology refinement उनसे नहीं जुड़ेगी

इसलिए induction को भी explicit data layer में बदलिए।

चरण ६ — Practical induction methods

अब main corpus से “ancient sensibility” सीखने की corrected practical विधियाँ रखता हूँ।

६.१ Co-occurrence graphs

Reviewed primary corpus passages से co-occurrence networks बनाइये।

इसका प्रयोजन
recurring concept adjacency देखना
family boundaries का आभास लेना
candidate clusters बनाना

किन्तु यह केवल संकेत है, final ontology नहीं।

६.२ Frequent typed subgraph mining

जब reviewed assertions पर्याप्त हो जायें, तब recurrent typed patterns निकालिये।

उदाहरण
Nakshatra -> Deity
Tithi + Vara -> Doṣa
Action -> SuitableUnder -> Condition
Karma -> Dormancy -> ManifestsWhen -> Condition

यह mining raw text पर नहीं, reviewed or high-confidence typed assertions पर होनी चाहिए।

६.३ Community detection

Graph communities doctrinal neighborhoods का संकेत दे सकती हैं।

किन पर चलायें?
reviewed edges
या very high-confidence edges
क्यों?

क्योंकि low-quality graph पर community detection भ्रमपूर्ण होगी।

६.४ Concept split proposals

यदि कोई concept बहुत heterogeneous हो जाये, तो split proposal उठाइये।

उदाहरण

KALA over-broad हो सकती है, और उसके भीतर अलग sub-concepts उभर सकते हैं:

cyclical time
admissibility time
ritual timing
calendrical units

किन्तु split automatic नहीं होगी।
वह redesign proposal बनेगी।

चरण ७ — Runtime redesign discipline

अब यह भी स्पष्ट करना चाहिए कि redesign कब उठेगी।

triggers
benchmark regression
repeated reviewer note pattern
concept heterogeneity बढ़ना
relation family confusion
cluster impurity
retrieval disagreement spike
constitutional conflict
इसका अर्थ

system blind evolution नहीं करेगी।
वह only triggered redesign propose करेगी।

चरण ८ — Section 19 के Python files

अलग zip में रखे गये मुख्य files यह हैं:

Models
app/db/models/redesign.py
Schemas
app/schemas/redesign.py
Repositories
app/repositories/redesign_repo.py
Services
app/services/redesign_service.py
app/services/sensibility_induction_service.py
Routers
app/api/routers/redesign.py
Documentation
SECTION_19_MANIFEST.md
INTEGRATION_NOTES.md

यह zip केवल section 19 के लिये है।
इसे earlier section zips के साथ intentionally नहीं मिलाया गया।

चरण ९ — इस section की dependencies

यह section presuppose करती है कि पहले से यह सब मौजूद हैं:

branches
benchmark runs
concept memory
reviewed assertions
cluster scaffolds
constitutional test discipline
review notes
graph export layer

अर्थात् यह section तभी अर्थपूर्ण है जब project पहले से एक जीवित reviewed corpus system बन चुकी हो।

चरण १० — इस section की सीमाएँ

स्पष्ट रूप से अभी क्या आगे रखा गया है:

automated redesign suggestion ranking
concept heterogeneity quantitative scoring
invariant mining pipelines
redesign dashboards
SHACL-linked redesign gates
cluster-split visualization tools

अतः यह section redesign governance का प्रथम canonical रूप देती है; पूर्ण mature redesign ecology नहीं।

इस section के Python files

Exact file paths inside the full Page-2 Python bundle

• app/db/models/redesign.py
• app/schemas/redesign.py
• app/repositories/redesign_repo.py
• app/services/redesign_service.py
• app/services/sensibility_induction_service.py
• app/api/routers/redesign.py

निष्कर्ष

इस section का corrected सार यह है:

यदि system को self-restructuring होना है, तो उसे blind self-modification की अनुमति नहीं दी जा सकती।
यदि उसे constitution-bound रहना है, तो redesign को explicit proposal बनना होगा।
यदि उसे main corpus से “ancient sensibility” सीखनी है, तो keywords नहीं, structural invariants ग्रहण करने होंगे।
यदि उसे plastic भी रहना है और मर्यादित भी, तो branching policy और promotion gate दोनों साथ चाहिए।

अतः:

redesign protocol देगा परिवर्तन की विधि
redesign levels देंगे कठोरता का क्रम
branching policy देगी traceability
promotion gate देगी वैधता
structural invariants देंगी corpus-native sensibility
induction methods देंगी practical मार्ग

इन्हीं से system वास्तव में self-restructuring होते हुए भी constitution-bound रह सकेगी।

उत्कर्ष

अब corrected sequence इस प्रकार आगे बढ़ती है:

source
normalization
segmentation
lexeme / sense / concept / role
assertions / rules
idempotency / dedup / confidence / benchmark
branch / promotion / rollback / shadow
benchmark seeds / constitutional suite / graph queries / review frontend
editable review / scholar retrieval
embeddings / reranker / active learning / hybrid scoring
training export / fine-tuning sets / disagreement queues
dynamic redesign protocol
redesign levels
structural invariant induction
promotion gate under constitution

Runtime query flow, automation boundary, objective function, और पूर्ण system के व्यवहार का अंतिम operational रूप

doctrinal traversal की वास्तविक चाल, automation की मर्यादा, और system के लक्ष्य-फलन की स्पष्ट रचना

भूमिका

अब तक की corrected रचना में system के भीतर यह सब उपस्थित हो चुका है:

source register
normalization branches
document और passage memory
lexeme / sense / corpus concept proposals
passage-role detection
discourse-form detection
assertions और rule assertions
benchmark discipline
branch governance
graph queries
scholar-facing retrieval
embeddings
reranker
active learning
hybrid scoring
training data export
disagreement-based queues
dynamic redesign protocol
structural invariant induction
promotion gate under constitution

इन सबके बाद भी एक अंतिम प्रश्न शेष रहता है:

जब user actual query पूछे, तब पूरी system वास्तव में कैसे चलेगी?

और इसके साथ दो और प्रश्न तुरंत उठते हैं:

system में क्या-क्या automate करना चाहिए?
और क्या-क्या कभी भी fully automate नहीं करना चाहिए?

यदि यह operational clarity नहीं बनी, तो architecture चाहे जितनी विशाल हो, व्यवहार में system या तो:

random pipeline का समूह बन जायेगी,
या convenience engineering की ओर drift कर जायेगी।

इसलिए इस section का उद्देश्य है:

final runtime query flow को स्पष्ट करना
automation boundary तय करना
objective function को explicit बनाना
और यह दिखाना कि पूरा system व्यवहार में किस क्रम से कार्य करेगी

यही इस project का final operational synthesis है।

पूर्वपक्ष

Runtime query flow क्यों explicit होना चाहिए?

किसी बड़े project में यह मान लेना कि “query आयी तो सब modules अपने-आप चल जायेंगे” बहुत बड़ी भूल है।
ऐसी दशा में system धीरे-धीरे opaque हो जाती है।
कोई नहीं जानता:

query पहले lexical layer में गयी या dense में
कौन-से ontology trunks activate हुए
graph expansion हुआ या नहीं
reranker कब लगी
result grouping किस आधार पर बनी
primary corpus preference कैसे लागू हुई

अतः runtime query flow को explicit चरणों में लिखना आवश्यक है।

यही वह बिन्दु है जहाँ search और doctrinal traversal में अन्तर स्पष्ट होता है।
Mere search केवल शब्द ढूँढती है।
Doctrinal traversal query को constitutional concepts में बदलकर, structured layers से ले जाती है, और grouped evidence field लौटाती है. यही आपके uploaded draft का भी स्पष्ट आशय है.

Automation boundary क्यों अलग विषय है?

बहुत-से projects एक subtle विनाशकारी भूल करते हैं।
वे जहाँ machine उपयोगी है, वहाँ भी human को अनावश्यक रोकते हैं;
और जहाँ human constitutional judgment अनिवार्य है, वहाँ machine को स्वतंत्र छोड़ देते हैं।

इस project में ऐसा नहीं हो सकता।

क्योंकि यहाँ system केवल passages rank नहीं कर रही।
यह:

concepts recover कर रही है,
relations build कर रही है,
graph grow कर रही है,
branches promote कर रही है,
और धीरे-धीरे civilizational memory structure गढ़ रही है।

अतः automation का प्रश्न तकनीकी नहीं; constitutional है।

Objective function क्यों explicit होनी चाहिए?

यदि objective function स्पष्ट न हो, तो project धीरे-धीरे convenience-driven हो जाती है।
कोई retrieval speed पर जोर देता है,
कोई benchmark pass-count पर,
कोई UI smoothness पर,
कोई graph size पर,
कोई training loss पर।

परन्तु complete knowledge retrieval system का लक्ष्य इन सबका mechanical योग नहीं हो सकता।

इसलिए objective function को explicit रूप से लिखना होगा:

maximize क्या करना है?
constitutional recall
structural extractability
interpretability
retrieval fidelity
graph coherence
minimize क्या करना है?
drift from primary-corpus constitution
unreviewed ontology growth
hallucinated relations
over-dependence on secondary texts
benchmark regression

यही discipline system को decay से बचायेगी. आपका draft इसी बात पर स्पष्ट बल देता है.

उत्तरपक्ष

भ्रान्ति १

“Runtime flow को इतनी विस्तार से लिखने की आवश्यकता नहीं; code से समझ में आ जायेगा।”

यह असत्य है।
Code implementation detail है; runtime flow operational doctrine है।
दोनों का लिखित पृथक्करण आवश्यक है।

भ्रान्ति २

“Automation जितनी अधिक होगी, system उतनी उत्तम होगी।”

नहीं।
Automation intelligence नहीं; केवल delegated procedure है।
यदि उसे constitutional सीमा के बिना बढ़ाया गया, तो वही drift का स्रोत बनेगी।

भ्रान्ति ३

“Objective function को formal लिखना academic luxury है।”

नहीं।
बिना explicit objective function के हर टीम, हर branch, हर model अपनी अलग सफलता परिभाषित करेगी।
यही disorder की शुरुआत है।

भ्रान्ति ४

“Query flow में graph expansion और reranking बाद में देखेंगे; पहले lexical + dense काफी है।”

यह केवल प्रारम्भिक search prototypes के लिये ठीक हो सकता है।
पर इस project का लक्ष्य doctrinal traversal है, इसलिए runtime flow में structural expansion और grouped evidence presentation प्रारम्भ से ही सोचना होगा।

सन्धि

अब सम्यक् synthesis यह है:

runtime query flow system के व्यवहार का explicit विधान है
automation boundary system की मर्यादा है
objective function system की दिशा है
और इन तीनों के संयोग से ही operational architecture पूर्ण होती है

यही section पूर्ववर्ती सारे sections को एक व्यवहारिक संपूर्णता देती है।

सन्धान

अब corrected operational विधि क्रमशः रखता हूँ।

चरण १ — Runtime query flow का पूर्ण क्रम

जब user कोई doctrinal query पूछे, तो system का व्यवहार निम्न क्रम में होना चाहिए।

Step 1 — Query parsing

raw query को:

normalized query
constitutional concepts
ontology trunk hints
preferred evidence types

में तोड़ा जाये।

Step 2 — Ontology trunk activation

यदि query में:

cosmic संकेत अधिक हैं, तो cosmic trunk
doctrinal संकेत अधिक हैं, तो doctrinal trunk
temporal संकेत अधिक हैं, तो temporal trunk

आदि activate हों।

Step 3 — Lexical candidate retrieval

पहले text_search, text_norm, और lexical forms पर passages निकाले जायें।

Step 4 — Dense candidate retrieval

Embedding artifacts से semantic candidates निकाले जायें।

Step 5 — Graph neighborhood expansion

Top candidate passages या core concepts के आधार पर graph neighborhoods खोली जायें।

Step 6 — Specialist reranking

Candidate pool पर reranker चले।

Step 7 — Grouping by discourse form / role

Results को इस प्रकार group किया जाये:

direct definitions
causal rules
narrative exempla
ritual exceptions
other structured support
Step 8 — Primary corpus preference

जहाँ suitable हो, primary corpus को preference दी जाये।

Step 9 — Final display

User को यह दिया जाये:

passages
extracted assertions
graph path / neighborhood hints
evidence grouping

यही doctrinal traversal है।
यही mere search से उसका भेद है.

चरण २ — Runtime orchestration service

अब इसके लिये एक dedicated service चाहिए:

RuntimeQueryService

इसका कार्य होगा:

query parse करना
constitutional hints निकालना
search service को call करना
hybrid retrieval service को चलाना
graph query service से expansion लेना
grouped result लौटाना

यह service कोई canonical mutation नहीं करेगी।
यह pure runtime orchestration layer होगी।

चरण ३ — Automation boundary का स्पष्ट विधान

अब यह explicit लिखना चाहिए कि system में क्या automate होगा, और क्या नहीं।

automate करें
normalization proposals
candidate extraction
uncertainty-driven annotation queues
embedding generation
graph insertion of reviewed items
benchmark reporting
branch comparison
SHACL legality checks
fully automate न करें
constitutional ontology roots
final promotion of new trunk concepts
replacement of gold labels
silent reinterpretation of primary corpus
canonical status of secondary-corpus proposals

यही intelligence और drift के बीच की रेखा है.

चरण ४ — AutomationPolicy layer

अब इस boundary को prose में छोड़ना पर्याप्त नहीं।
इसे code में भी explicit रखना होगा।

इसलिए एक policy layer हो:

AUTOMATE
DO_NOT_FULLY_AUTOMATE

यह later:

reviewer UI
governance checks
redesign gates
deployment policy

में उपयोगी होगी।

चरण ५ — Objective function का corrected रूप

अब objective function को स्पष्ट लिखते हैं।

maximize
constitutional_recall
structural_extractability
interpretability
retrieval_fidelity
graph_coherence
minimize
primary_corpus_drift
unreviewed_ontology_growth
hallucinated_relations
secondary_overdependence
benchmark_regression
इनका अर्थ
constitutional_recall

ऐसे सभी legally relevant passages recover हों जो query के लिये आवश्यक हैं।

structural_extractability

text को typed assertions, rules, roles, और graph-ready structures में बदला जा सके।

interpretability

हर promoted concept, relation, और edge reviewer और scholar के लिये बोधगम्य रहे।

retrieval_fidelity

कठिन doctrinal queries पर ranking उच्च कोटि की हो।

graph_coherence

graph में illegal या contradictory structures न पनपें।

primary_corpus_drift

main corpus constitution से drift न्यूनतम रहे।

unreviewed_ontology_growth

बिना review ontology की uncontrolled वृद्धि न हो।

hallucinated_relations

झूठी relations न्यूनतम रहें।

secondary_overdependence

secondary corpus main law पर अनुचित रूप से हावी न हो।

benchmark_regression

older benchmark suites पर गिरावट न्यूनतम हो।

चरण ६ — ObjectiveFunctionService

अब एक service चाहिए जो:

objective weights लौटाये
metrics लेकर उनका combined objective score निकाले

यह score final truth नहीं होगी,
पर branch comparison, redesign gating, और dashboard summaries में उपयोगी होगी।

चरण ७ — Runtime API

अब एक नया router चाहिए:

POST /runtime/query

यह पूरा doctrinal traversal चलायेगा।

GET /runtime/automation-policy

यह explicit automation boundary लौटायेगा।

GET /runtime/objective

यह objective function weights लौटायेगा।

यह API केवल developers के लिये नहीं; governance और inspection के लिये भी उपयोगी होगी।

चरण ८ — Grouped output का महत्व

Runtime output flat list में नहीं लौटनी चाहिए।
उसे grouped होना चाहिए।

Suggested groups
direct_definitions
causal_rules
narrative_exempla
ritual_exceptions
other

यह grouping आरम्भिक है।
Later richer evidence groups बन सकते हैं।
किन्तु अभी से group-aware return structure होना चाहिए।

चरण ९ — Runtime flow में graph expansion की भूमिका

Graph expansion को optional रखना चाहिए:

lightweight queries पर इसे छोड़ा जा सकता है
doctrinal कठिन queries पर इसे activate किया जा सकता है

इससे runtime usable भी रहेगी और richer भी।

क्यों optional?

क्योंकि हर query पर heavy graph traversal आवश्यक नहीं।
कुछ queries pure lexical definitional हो सकती हैं।
कुछ mixed queries graph विस्तार चाहेंगी।

चरण १० — इस section के Python files

अलग zip में रखे गये मुख्य files यह हैं:

Core
app/core/objective.py
Schemas
app/schemas/runtime.py
Services
app/services/runtime_query_service.py
app/services/automation_policy_service.py
app/services/objective_function_service.py
Routers
app/api/routers/runtime.py
Scripts
scripts/demo_runtime_flow.py
Documentation
docs/SECTION_20_MANIFEST.md
docs/INTEGRATION_NOTES.md

यह zip केवल section 20 के लिये है।
इसे earlier section zips के साथ intentionally नहीं मिलाया गया।

चरण ११ — इस section की dependencies

यह section presuppose करती है कि पहले से यह सेवाएँ मौजूद हैं:

SearchService
HybridRetrievalService
GraphQueryService
api/deps.py
earlier semantic ladder
reviewed graph export
branch governance

अर्थात् यह section final operational synthesis है, foundation नहीं।

चरण १२ — इस section की सीमाएँ

स्पष्ट रूप से अभी क्या आगे शेष है:

query interpretation editor
runtime dashboards
role-aware dynamic grouping
constitutional trust score as explicit runtime term
cluster-aware runtime expansion
dialogue / debate mode retrieval
scholar export renderer

अतः यह section final runtime doctrine का प्रथम practical रूप देती है; पूर्ण mature user platform नहीं।

इस section के Python files

Exact file paths inside the full Page-2 Python bundle

• app/core/objective.py
• app/schemas/runtime.py
• app/services/runtime_query_service.py
• app/services/automation_policy_service.py
• app/services/objective_function_service.py
• app/api/routers/runtime.py
• scripts/demo_runtime_flow.py
• pyproject.toml
• .env.example
• app/main.py
• app/api/deps.py
• scripts/create_tables.py
• scripts/preflight_check.py

निष्कर्ष

इस section का corrected सार यह है:

यदि runtime query flow explicit न हो, तो system opaque हो जायेगी।
यदि automation boundary explicit न हो, तो intelligence और drift का भेद टूट जायेगा।
यदि objective function explicit न हो, तो project convenience engineering में गिर जायेगी।

अतः अब यह आवश्यक था कि:

automation की मर्यादा code और policy दोनों में रखी जाये
objective function स्पष्ट रूप से परिभाषित हो
final operational behavior reproducible बनाया जाये

इसीसे system एक वास्तविक, constitution-bound, scholar-facing retrieval architecture बनती है।

उत्कर्ष

अब corrected sequence इस प्रकार पूर्णता की ओर पहुँचती है:

source
normalization
segmentation
lexeme / sense / concept / role
assertions / rules
idempotency / dedup / confidence / benchmark
branch / promotion / rollback / shadow
benchmark seeds / constitutional suite / graph queries / review frontend
editable review / scholar retrieval
embeddings / reranker / active learning / hybrid scoring
training export / disagreement-based learning
dynamic redesign protocol / structural invariants
automation boundary
objective function

यहीं पर project की complete theoretical-methodological arc अभी के लिये पूर्ण होती है।

Python files : full download bundle and master path list

इस पृष्ठ में ऊपर दिये गये सभी app/... और scripts/... paths इसी full bundle के भीतर उपलब्ध हैं। Dead individual links intentionally हटाये गये हैं, क्योंकि कई files के names समान थे और केवल path से ही उनकी सही पहचान सम्भव है। इस कारण नीचे full zip और master path list दी जा रही है।

Download bundle

Download the full Python Scripts implementation bundle

Master path list

Download the master list of exact file paths inside the above bundle