User Decision & Interaction Governance : Biligent#6

Overview of Biligent

 

Governance Spec Section 6: User Decision Rules Human-in-the-Loop 18 min read

Biligent User Decision & Interaction Governance: Behavioral Invariants, Routing Cascades & Placement Logic (DP-06)

How humans and autonomous agents co-create knowledge: 25 comprehensive User Decision Rules (UR-01 ~ UR-25) governing semantic feedback, structural edits, non-questionnaire interfaces, batch draft application, and fault-tolerant routing cascades.

🐺 Democratic Coordination in the Pack: African Wild Dogs (Painted Wolves) make high-stakes group decisions through subtle, democratic signaling and synchronized communication before taking collective action. The Biligent architecture implements an identical balance: agents propose and pre-assign, while humans hold definitive confirmation authority through structured consensus rules.

Table of Contents

• 6-1. Behavioral Rules (UR-01 ~ UR-21)
• 6-2. Dynamic Routing & Cascade Rules (UR-22 ~ UR-25)
• 6-3. Structural Placement & Boundary Rules

6-1 Behavioral Rules (UR-01 ~ UR-21)

Behavioral rules dictate the exact runtime interactions across modules. The corresponding receiving module is accountable for each rule, backed by milestone acceptance tests in the specified implementation rounds.

UR-01: No Questionnaire / Survey Interface Rounds R1 · R3 · R5

Specification: Eliminate all wizard/questionnaire forms—no questionnaire presentation, uploads, partial replies, or survey buttons. Semantic input previously handled via surveys is completely replaced by Node Opinions (UR-03~UR-05), raw document uploads (accept_prior_info), seed question uploads (accept_seed_questions), and calculation rule inputs (derived_data.define).

Implementation: ingest.user_input, ui Calculation Rule Input Screen.

UR-02: Screen Optimization & Minimal Menus Rounds R0 · R10

Specification: Strict upper bound on top-level navigation screens. All specialized operations and detailed interactions are delegated to contextual sliding panels rather than cluttered top-level views.

Implementation: ui (Principle Gate 4).

UR-03 ~ UR-05: Connectivity Graph Opinions & Incremental Semantic Learning Rounds R3 · R4 · R10

UR-03: Once connectivity is constructed, users provide semantic meaning via opinion entries on column names, key names, state values, and condition values. Renders as Tree, Star, or Mindmap views (connectivity.view, display_optimizer.recommend_layout).
UR-04: Displays existing semantic definitions alongside new opinion input fields. Column/Key nodes show value ranges; State/Condition nodes show discrete values.
UR-05: Additional user opinions are incrementally synthesized with existing knowledge by A7 (handling enhancements, condition additions, and contradiction detection) → verified by critic → held as candidate tiers awaiting human confirmation.

UR-06: Value Role Definition — State vs. Condition Rounds R3 · R4

Specification: State represents the internal state of the measurement target; Condition represents external environmental variables. If indistinguishable from data alone, assigned the highest-probability role marked with Needs Review while preserving candidate roles for user opinion entry.

Implementation: value_roles classification, A7 Node Detail Panel.

UR-07: Reference Data & Explicit Exclusion Reasons Rounds R0 · R1 · R3 · R5 · R10

Specification: Reference data displays both data rows utilized in the answer and excluded data rows along with precise reason codes. Exclusion extraction covers the entire question scope (evidence_view).

UR-08: Node Lifecycle States & Non-destructive Draft Pulldowns Rounds R3 · R4 · R8

4 Canonical States:

• Excluded (제외): Visible in map, but input of opinions is disabled; positioned at bottom.
• Removed (제거): Omitted from map, moved to Removed List for restoration; raw data is NEVER deleted.
• Unreflected (미반영): Default state awaiting future opinion.
• Semantic (의미): Assigned meaning by agent or user; sorted to top with tiers (Needs Review → Approved → Confirmed).

Draft Pulldown Invariant: Selecting Exclude/Remove in UI attaches a "Pending Exclusion/Removal" tag without immediate rearrangement. Changes are stored as drafts and applied in a single pass during Batch Apply (UR-15). Upstream status changes preview downwards to descendants. State transitions generate learning signals.

UR-09: Node Anatomy & Measurement Representation Rounds R3 · R4

Specification: Nodes are strictly Column Names, Key Names, and State/Condition Values under keys. Numerical metrics (측정값) are NOT independent nodes—they are rendered as value ranges attached to column/key nodes.

UR-10: Structural Edit Verification Pipeline & 4 Outcomes Rounds R3 · R4 · R5 · R6 · R11

Pipeline: User Edit → A6 Data Verification (check_occurrence, check_format, check_link) → Evidence Report → Human Confirmation.

4 Verification Outcomes:
1. Confirmed: Fully proven by data → applied upon human confirmation.
2. Partially Confirmed: Discrepancy ratio reported → user chooses conditional confirmation.
3. Disproven: Contradicted by data → user can still force confirmation, marked "Data Disproven / User Specified" with lower confidence.
4. Indeterminate: Held as "User Proposed (Pending)" until new data arrives.

UR-11: Deterministic Node Drilldowns to Real Sample Rows Rounds R3 · R4 · R10

Specification: Clicking a node reveals real raw data rows with highlighted node positions (profile.sample_rows). Follows deterministic selection rules (min/mid/max values, boundary transitions, missing rows). Packed values are displayed in parallel with decoded values (meaning_structure.decode). Users can directly attach opinions from sample rows.

UR-12: Excluded & Removed Nodes in Computation Rounds R0 · R5 · R6 · R10

Specification: Excluded/Removed nodes are strictly omitted from answer computation with reason codes "Node Excluded" / "Node Removed". If an answer refers to such nodes, a disclaimer badge is rendered with a direct link to change node status. Query-scoped forced inclusions (UR-25) CANNOT override excluded/removed node states.

UR-13: Semantic Conflict Management (Cross-User vs. Same-User) Rounds R4 · R5 · R6 · R8 · R10

Cross-User Conflict: When conflicting opinions are submitted, A7 marks the rule as User-Scoped. The submitter sees their own rule marked "User Specified Meaning" while other users see the common meaning. Conflicts are escalated via meaning_conflict to the Domain Administrator. When adopted by the admin, it replaces all user-scoped rules as the common confirmed rule; when rejected, the user-scoped rule is revoked.
Same-User Conflict: Prompted with a mandatory selection modal; no changes occur until resolved.

UR-14 & UR-15: Under-Review Usage & Single-Pass Batch Apply Rounds R4 · R6 · R7 · R10

UR-14: Knowledge items transitioning to review remain operational with an explicit "Under Review" badge.
UR-15: Batch application pipeline triggered by a single button: "Batch Apply (State N · Distinction N · Opinions N)".
• Step 1: Status changes applied from top down (single map re-sort).
• Step 2: Distinction changes applied (A7 direct or A6 verification).
• Step 3: Opinions classified (enhancement, condition, contradiction) → critic check → human gate.

UR-16: User Modification of Node Distinction Rounds R3 · R4

Specification: Pulldown modifications between Column Name ↔ Key Name ↔ Value ↔ Metric. Column↔Key changes route via A6 structural verification (UR-10); State Value ↔ Condition Value changes route directly via A7 role updates.

UR-17: Instant Answers to Complex Queries with CalcPlan Rounds R1 · R5 · R6 · R10

Specification: Multi-step queries are computed and answered immediately. Answers visibly present the Calculation Plan (CalcPlan), chosen rationale, referenced data, and non-referenced data with exclusion reasons. If formulated without a pre-confirmed definition, it carries an "Inferred Calculation Plan (Unconfirmed)" badge. Users can promote valid plans to confirmed calculation rules.

UR-18: Thin End-to-End Vertical Slice First Rounds R0 ~ R12

Specification: The architecture strictly implements a thin vertical slice in Round 1 (Upload → Simple Map → 1 Semantic Definition → 1 Query → Evidence-backed Answer) before expanding and thickening individual layers in subsequent rounds.

UR-19: Reusability of Human-Confirmed Artifacts Rounds R8 · R9 · R11 · R12

Specification: Human-confirmed items (roles, states, structural edits, format rules, outlier criteria, calculation rules, verified data type assignments) are preserved with format signatures during domain resets or server migrations.

• Identical Signature: Confirmed tiers automatically re-applied with badge "Previous Confirmation Applied".
• Different Signature: Re-learned from scratch; previous confirmation retained as reference only.
• New Domain: Exact map signatures allow automated carryover; multi-domain conflicts prompt Domain Admin selection.

UR-20: Agent Pre-assignment ("Needs Review" Invariant) Rounds R3 · R4 · R8 · R11

Specification: When agents can deduce reasonable assignments, they pre-assign provisional values flagged as Needs Review. Humans retain exclusive confirmation authority. Applies to: (1) Data Type Assignment, (2) Ambiguous Value Roles (State vs. Condition), (3) Evaluation Question Sets.

UR-21: Autonomous Learning Rate Tuning with Auto-Rollback Rounds R4 · R7 · R11

Specification: A4 tunes operational thresholds (demand threshold, rejection repeat count, rejection harmonize weights) based on deterministic metric trends (quality_metrics.report).
Safeguards: Strict policy bounds (LEARNING_PARAM_BOUNDS) prevent out-of-range tuning. Parameter changes enter a mandatory observation window; if quality metrics deteriorate beyond tolerance, values are automatically rolled back.

6-2 Dynamic Routing & Cascade Rules (UR-22 ~ UR-25)

Rule ID	Routing Invariant & Operational Flow	Participating Modules
UR-22	Dynamic Opinion Routing: A0 evaluates free-form opinions from answers and row-level feedback: • Data Meaning: Dispatched to A7 via meaning_opinion. • Answer Evaluation / Exclusion Objection: Routed to feedback.submit. • Display Formatting: Dispatched to display_optimizer. • Row Inclusion: Handled via UR-25 recalculation. • Structure/Formatting: Recorded in user_input, sent to A6 (structure_edit). • Calculation Planning: Re-interpreted by A1 and validated by query_slots.	A0, A7, A6, A1, user_input, feedback, display_optimizer, evidence_view
UR-23	Semantic Change Cascade: When A7 alters a semantic rule, it emits meaning_changed(rule_ids, node_ids). Automatically triggers: (1) Graph update in connectivity, (2) Invalidation of dependent historical answers in conversation, (3) Quality metrics logging, (4) Transition of affected downstream knowledge to Under Review while keeping them operational.	A7, connectivity, conversation, quality_metrics, knowledge_policy
UR-24	Deterministic Exclusion Logging: Exclusions are recorded at the exact stage they occur with explicit reason codes: query_slots (out-of-bounds period/condition), grouping (condition mismatch, segmentation break, node exclusion/removal), algorithms (outliers, missing values, format errors). Stored in standardized format Batch{included, excluded[{ref, reason_code, step}]}.	contracts, query_slots, grouping, algorithms, evidence_view
UR-25	Forced Inclusion & Recalculation: Marking an excluded row as "Include" triggers A0 recalculation with forced inclusion flags. grouping respects forced inclusion with code "User Specified". Sent to feedback.submit as an exclusion objection; repeated objections escalate to A5 investigation demand. Applies strictly to the active query turn.	A0, conversation, query_slots, grouping, algorithms, feedback

6-3 Structural Placement & Boundary Invariants

📐 Architectural Placement Rationale

• Role Classification Placement: State and Condition are general abstractions (internal vs. external to the measurement target), residing in value_roles rather than hardcoded domain values. When data alone is ambiguous, A7 finalizes classification with user input.
• Direct Path for Node Opinions: Node opinions specify target nodes in the UI and route directly to A7 bypassing A0, satisfying the rule that only A6/A7 write to understanding.
• Separation of Fact vs. Fusion: Raw opinion text logging is deterministic (user_input), while fusing new opinions into existing semantics requires non-deterministic synthesis (A7).
• No Understanding → Knowledge Cycle: Node details are assembled solely from packages already used by A7. connectivity does NOT read semantic tiers, preventing circular dependencies.
• Human Supremacy on Final Confirmation: Agents never unilaterally promote items to the Confirmed tier (adhering to Principle Gate "Human Holds Confirmation Authority").
• Decoupled Knowledge Ordering: Sorting semantic nodes by tier in the UI is performed by querying knowledge_policy, and user-specific rule selection is performed by A0 via knowledge_policy.usable, maintaining strict acyclic dependency flow.

#HumanInTheLoop #UserDecisionRules #MultiAgentGovernance #Biligent #SoftwareArchitecture

© Biligent Architecture & Interaction Governance Series. All rights reserved.