Changes for page Requirements

Last modified by Robert Schaub on 2025/12/24 20:34

From 8.6 to 8.7

From version 1.1

edited by Robert Schaub
on 2025/12/11 18:37

Change comment: Imported from XAR

To version 8.6

edited by Robert Schaub
on 2025/12/16 20:28

Change comment: Renamed back-links.

Raw
Rendered

Summary

Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Parent

@@ -1,1 +1,1 @@
--FactHarbor.Specification.WebHome
++FactHarbor.Archive.FactHarbor V0\.9\.18.Specification.WebHome

Content

@@ -1,177 +1,372 @@
  = Requirements =
--This chapter defines all functional, non-functional, user-role, and federation requirements for FactHarbor.
++This page defines **Roles**, **Responsibilities**, and **Rules** for contributors and users of FactHarbor.
--It answers:
++== Roles ==
--* Who can do what in the system?
--* What workflows must FactHarbor support?
--* What quality, transparency, and federation guarantees must be met?
++=== Reader ===
------
++**Who**: Anyone (no login required).
--= User Roles =
++**Can**:
--== Reader ==
++* Browse and search claims
++* View scenarios, evidence, verdicts, and timelines
++* Compare scenarios and explore assumptions
++* Flag issues, errors, contradictions, or suspicious patterns
++* Use filters, search, and visualization tools
++* Create personal views (saved searches, bookmarks - local browser storage)
++* **Submit claims automatically** by providing text to analyze - new claims are added automatically unless equal claims already exist in the system
--Responsibilities:
++**Cannot**:
--* Browse and search claims
--* View scenarios, evidence, verdicts, and timelines
--* Compare scenarios and explore assumptions
--* Flag issues, errors, contradictions, or suspicious patterns
++* Modify existing content
++* Access draft content
++* Participate in governance decisions
--Permissions:
++**Note**: Readers can request human review of AI-generated content by flagging it.
--* Read-only access to all published claims, scenarios, evidence, and verdicts
--* Use filters, search, and visualization tools (“truth landscape”, timelines, scenario comparison, etc.)
--* Create personal views (saved searches, bookmarks, etc.)
++=== Contributor ===
--Limitations:
++**Who**: Registered and logged-in users (extends Reader capabilities).
--* Cannot change shared content
--* Cannot publish new claims, scenarios, or verdicts
++**Can**:
------
++* Everything a Reader can do
++* Submit claims
++* Submit evidence
++* Provide feedback
++* Suggest scenarios
++* Flag content for review
++* Request human review of AI-generated content
--== Contributor ==
++**Cannot**:
--Responsibilities:
++* Publish or mark content as "reviewed" or "approved"
++* Override expert or maintainer decisions
++* Directly modify AKEL or quality gate configurations
--* Submit claims
--* Propose new claim clusters (if automatic clustering is insufficient)
--* Draft scenarios (definitions, assumptions, boundaries)
--* Attach evidence (sources, documents, links, datasets)
--* Suggest verdict drafts and uncertainty ranges
--* Respond to reviewer or expert feedback
++=== Reviewer ===
--Permissions:
++**Who**: Trusted community members, appointed by maintainers.
--* Everything a Reader can do
--* Create and edit **draft** claims, scenarios, evidence links, and verdict drafts
--* Comment on existing content and discuss assumptions
--* Propose corrections to misclassified or outdated content
++**Can**:
--Limitations:
++* Review contributions from Contributors and AKEL drafts
++* Validate AI-generated content (Mode 2 → Mode 3 transition)
++* Edit claims, scenarios, and evidence
++* Add clarifications or warnings
++* Change content status: `draft` → `in review` → `published` / `rejected`
++* Approve or reject **Tier B and C** content for "Human-Reviewed" status
++* Flag content for expert review
++* Participate in audit sampling
--* Cannot *publish* or mark content as “reviewed” or “approved”
--* Cannot override expert or maintainer decisions
--* Cannot change system-level settings, roles, or federation configuration
++**Cannot**:
++* Approve Tier A content for "Human-Reviewed" status (requires Expert)
++* Change governance rules
++* Unilaterally change expert conclusions without process
++* Bypass quality gates
++
++**Note on AI-Drafted Content**:
++
++* Reviewers can validate AI-generated content (Mode 2) to promote it to "Human-Reviewed" (Mode 3)
++* For Tier B and C, Reviewers have approval authority
++* For Tier A, only Experts can grant "Human-Reviewed" status
++
++=== Expert (Domain-Specific) ===
++
++**Who**: Subject-matter specialists in specific domains (medicine, law, science, etc.).
++
++**Can**:
++
++* Everything a Reviewer can do
++* **Final authority** on Tier A content "Human-Reviewed" status
++* Validate complex or controversial claims in their domain
++* Define domain-specific quality standards
++* Set reliability thresholds for domain sources
++* Participate in risk tier assignment review
++* Override AKEL suggestions in their domain (with documentation)
++
++**Cannot**:
++
++* Change platform governance policies
++* Approve content outside their expertise domain
++* Bypass technical quality gates (but can flag for adjustment)
++
++**Specialization**:
++
++* Experts are domain-specific (e.g., "Medical Expert", "Legal Expert", "Climate Science Expert")
++* Cross-domain claims may require multiple expert reviews
++
++=== Auditor ===
++
++**Who**: Reviewers or Experts assigned to sampling audit duties.
++
++**Can**:
++
++* Review sampled AI-generated content against quality standards
++* Validate quality gate enforcement
++* Identify patterns in AI errors or hallucinations
++* Provide feedback for system improvement
++* Flag content for immediate review if errors found
++* Contribute to audit statistics and transparency reports
++
++**Cannot**:
++
++* Change audit sampling algorithms (maintainer responsibility)
++* Bypass normal review workflows
++* Audit content they personally created
++
++**Selection**:
++
++* Auditors selected based on domain expertise and review quality
++* Rotation to prevent audit fatigue
++* Stratified assignment (Tier A auditors need higher expertise)
++
++**Audit Focus**:
++
++* Tier A: Recommendation 30-50% sampling rate, expert auditors
++* Tier B: Recommendation 10-20% sampling rate, reviewer/expert auditors
++* Tier C: Recommendation 5-10% sampling rate, reviewer auditors
++
++=== Moderator ===
++
++**Who**: Maintainers or trusted long-term contributors.
++
++**Can**:
++
++* All Reviewer and Expert capabilities (cross-domain)
++* Manage user accounts and permissions
++* Handle disputes and conflicts
++* Enforce community guidelines
++* Suspend or ban abusive users
++* Finalize publication status for sensitive content
++* Review and adjust risk tier assignments
++* Oversee audit system performance
++
++**Cannot**:
++
++* Change core data model or architecture
++* Override technical system constraints
++* Make unilateral governance decisions without consensus
++
++=== Maintainer ===
++
++**Who**: Core team members responsible for the platform.
++
++**Can**:
++
++* All Moderator capabilities
++* Change data model, architecture, and technical systems
++* Configure quality gates and AKEL parameters
++* Adjust audit sampling algorithms
++* Set and modify risk tier policies
++* Make platform-wide governance decisions
++* Access and modify backend systems
++* Deploy updates and fixes
++* Grant and revoke roles
++
++**Governance**:
++
++* Maintainers operate under organizational governance rules
++* Major policy changes require Governing Team approval
++* Technical decisions made collaboratively
++
  ----
--== Reviewer ==
++== Content Publication States ==
--Responsibilities:
++=== Mode 1: Draft ===
--* Review contributions from Contributors and AKEL drafts
--* Check internal consistency and clarity of scenarios
--* Validate that evidence is correctly linked and described
--* Ensure verdicts match the evidence and stated assumptions
--* Reject, request change, or accept content
++* Not visible to public
++* Visible to contributor and reviewers
++* Can be edited by contributor or reviewers
++* Default state for failed quality gates
--Permissions:
++=== Mode 2: AI-Generated (Published) ===
--* Everything a Contributor can do
--* Change content status from `draft` → `in review` → `published` / `rejected`
--* Send content back to Contributors with comments
--* Flag content for expert review
++* **Public** and visible to all users
++* Clearly labeled as "AI-Generated, Awaiting Human Review"
++* Passed all automated quality gates
++* Risk tier displayed (A/B/C)
++* Users can:
++** Read and use content
++** Request human review
++** Flag for expert attention
++* Subject to sampling audits
++* Can be promoted to Mode 3 by reviewer/expert validation
--Limitations:
++=== Mode 3: Human-Reviewed (Published) ===
--* Cannot modify system-wide configuration or federation topology
--* Cannot unilaterally change expert conclusions without process
++* **Public** and visible to all users
++* Labeled as "Human-Reviewed" with reviewer/expert attribution
++* Passed quality gates + human validation
++* Highest trust level
++* For Tier A, requires Expert approval
++* For Tier B/C, Reviewer approval sufficient
++=== Rejected ===
++
++* Not visible to public
++* Visible to contributor with rejection reason
++* Can be resubmitted after addressing issues
++* Rejection logged for transparency
++
  ----
--== Expert ==
++== Contribution Rules ==
--Responsibilities:
++=== All Contributors Must: ===
--* Provide domain-specific judgment on scenarios, evidence, and verdicts
--* Refine assumptions and definitions in complex or ambiguous topics
--* Identify subtle biases, missing evidence, or misinterpretations
--* Propose improved verdicts and uncertainty assessments
++* Provide sources for claims
++* Use clear, neutral language
++* Avoid personal attacks or insults
++* Respect intellectual property (cite sources)
++* Accept community feedback gracefully
--Permissions:
++=== AKEL (AI) Must: ===
--* Everything a Reviewer can do
--* Attach expert annotations and signed opinions to scenarios and verdicts
--* Propose re-evaluation of already published content based on new evidence
++* Mark all outputs with `AuthorType = AI`
++* Pass quality gates before Mode 2 publication
++* Perform mandatory contradiction search
++* Disclose confidence levels and uncertainty
++* Provide traceable reasoning chains
++* Flag potential bubbles or echo chambers
++* Submit to audit sampling
--Limitations:
++=== Reviewers Must: ===
--* Expert status is scoped to specific domains
--* Cannot bypass moderation, abuse policies, or legal constraints
++* Be impartial and evidence-based
++* Document reasoning for decisions
++* Escalate to experts when appropriate
++* Participate in audits when assigned
++* Provide constructive feedback
++=== Experts Must: ===
++
++* Stay within domain expertise
++* Disclose conflicts of interest
++* Document specialized terminology
++* Provide reasoning for domain-specific decisions
++* Participate in Tier A audits
++
  ----
--== Moderator ==
++== Quality Standards ==
--Responsibilities:
++=== Source Requirements ===
--* Handle abuse reports, spam, harassment, and coordinated manipulation
--* Enforce community guidelines and legal constraints
--* Manage user bans, content takedowns, and visibility restrictions
++* Primary sources preferred over secondary
++* Publication date and author must be identifiable
++* Sources must be accessible (not paywalled when possible)
++* Contradictory sources must be acknowledged
++* Echo chamber sources must be flagged
--Permissions:
++=== Claim Requirements ===
--* Hide or temporarily disable access to abusive content
--* Ban or restrict users in line with policy
--* Edit or redact sensitive content (e.g., doxxing, illegal material)
++* Falsifiable or evaluable
++* Clear definitions of key terms
++* Boundaries and scope stated
++* Assumptions made explicit
++* Uncertainty acknowledged
--Limitations:
++=== Evidence Requirements ===
--* Does not change factual verdicts except where required for legal / safety reasons
--* Substantive fact changes must go through the review / expert process
++* Relevant to the claim and scenario
++* Reliability assessment provided
++* Methodology described (for studies)
++* Limitations noted
++* Conflicting evidence acknowledged
  ----
--== Maintainer / Administrator ==
++== Risk Tier Assignment ==
--Responsibilities:
++**Automated (AKEL)**: Initial tier suggested based on domain, keywords, impact
++**Human Validation**: Moderators or Experts can override AKEL suggestions
++**Review**: Risk tiers periodically reviewed based on audit outcomes
--* Maintain node configuration, security settings, and backups
--* Configure AKEL, storage, federation endpoints, and performance tuning
--* Manage role assignments (who is Reviewer, Expert, Moderator, etc.)
--* Approve software updates and schema migrations
++**Tier A Indicators**:
--Permissions:
++* Medical diagnosis or treatment advice
++* Legal interpretation or advice
++* Election or voting information
++* Safety or security sensitive
++* Major financial decisions
++* Potential for significant harm
--* All read/write access to configuration, but not necessarily content editorial authority
--* Define organization-level policies (e.g., which sources are allowed by default)
++**Tier B Indicators**:
--Limitations:
++* Complex scientific causality
++* Contested policy domains
++* Historical interpretation with political implications
++* Significant economic impact claims
--* Editorial decisions on controversial topics follow governance rules, not arbitrary admin choice
++**Tier C Indicators**:
++* Established historical facts
++* Simple definitions
++* Well-documented scientific consensus
++* Basic reference information
++
  ----
--== AKEL (AI Knowledge Extraction Layer) ==
--Responsibilities:
++----
--* Propose drafts — never final decisions
--* Normalize claims and extract candidate clusters
--* Draft scenarios, evidence candidates, and preliminary verdict suggestions
--* Propose re-evaluation when new evidence appears
++== User Role Hierarchy Diagram ==
--Permissions:
++The following diagram visualizes the complete role hierarchy:
--* Create and update **machine-generated drafts** and suggestions
--* Never directly publish content without human approval
++{{include reference="FactHarbor.Archive.FactHarbor V0\.9\.23 Lost Data.Specification.Diagrams.User Class Diagram.WebHome"/}}
--Limitations:
++----
--* AKEL output is always labeled as AI-generated draft
--* Must be reviewable, auditable, and overridable by humans
++----
++== Role Hierarchy Diagrams ==
++
++=== User Class Diagram ===
++
++The following class diagram visualizes the complete user role hierarchy:
++
++{{include reference="FactHarbor.Archive.FactHarbor V0\.9\.23 Lost Data.Specification.Diagrams.User Class Diagram.WebHome"/}}
++
++=== Human User Roles ===
++
++This diagram shows the two-track progression for human users:
++
++{{include reference="FactHarbor.Archive.FactHarbor V0\.9\.23 Lost Data.Specification.Diagrams.Human User Roles.WebHome"/}}
++
++=== Technical and System Users ===
++
++This diagram shows system processes and their management:
++
++{{include reference="FactHarbor.Archive.FactHarbor V0\.9\.23 Lost Data.Specification.Diagrams.Technical and System Users.WebHome"/}}
++
++**Key Design Principles**:
++
++* **Two tracks from Contributor**: Content Track (Reviewer) and Technical Track (Maintainer)
++* **Technical Users**: System processes (AKEL, bots) managed by Maintainers
++* **Separation of concerns**: Editorial authority independent from technical authority
++
  ----
++
++
++----
++
  = Functional Requirements =
--This section defines what the system must **do**.
++
++This page defines what the FactHarbor system must **do** to fulfill its mission.
++
++Requirements are structured as FR (Functional Requirement) items and organized by capability area.
++
++----
++
  == Claim Intake & Normalization ==
  === FR1 – Claim Intake ===
@@ -178,36 +178,32 @@
  The system must support Claim creation from:
--* Free-text input
--* URLs (web pages, articles, posts)
--* Uploaded documents and transcripts
--* Structured feeds (optional, e.g. from partner platforms)
++* Free-text input (from any Reader)
++* URLs (web pages, articles, posts)
++* Uploaded documents and transcripts
++* Structured feeds (optional, e.g. from partner platforms)
++* Automated ingestion (federation input)
++* AKEL extraction from multi-claim texts
--Accepted sources:
++**Automatic submission**: Any Reader can submit text, and new claims are added automatically unless identical claims already exist.
--* Text entered by users
--* URLs
--* Uploaded documents
--* Transcripts
--* Automated ingestion (optional federation input)
--* AKEL extraction from multi-claim texts
--
  === FR2 – Claim Normalization ===
--* Convert diverse inputs into short, structured, declarative claims
--* Preserve original phrasing for reference
--* Avoid hidden reinterpretation; differences between original and normalized phrasing must be visible
++* Convert diverse inputs into short, structured, declarative claims
++* Preserve original phrasing for reference
++* Avoid hidden reinterpretation; differences between original and normalized phrasing must be visible
  === FR3 – Claim Classification ===
--* Classify claims by topic, domain, and type (e.g., quantitative, causal, normative)
--* Suggest which node / experts are relevant
++* Classify claims by topic, domain, and type (e.g., quantitative, causal, normative)
++* Assign risk tier (A/B/C) based on domain and potential impact
++* Suggest which node / experts are relevant
  === FR4 – Claim Clustering ===
--* Group similar claims into Claim Clusters
--* Allow manual correction of cluster membership
--* Provide explanation why two claims are considered “same cluster”
++* Group similar claims into Claim Clusters
++* Allow manual correction of cluster membership
++* Provide explanation why two claims are considered "same cluster"
  ----
@@ -215,29 +215,30 @@
  === FR5 – Scenario Creation ===
--* Contributors, Reviewers, and Experts can create scenarios
--* AKEL can propose draft scenarios
--* Each scenario is tied to exactly one Claim Cluster
++* Contributors, Reviewers, and Experts can create scenarios
++* AKEL can propose draft scenarios
++* Each scenario is tied to exactly one Claim Cluster
  === FR6 – Required Scenario Fields ===
  Each scenario includes:
--* Definitions (key terms)
--* Assumptions (explicit, testable where possible)
--* Boundaries (time, geography, population, conditions)
--* Scope of evidence considered
--* Intended decision / context (optional)
++* Definitions (key terms)
++* Assumptions (explicit, testable where possible)
++* Boundaries (time, geography, population, conditions)
++* Scope of evidence considered
++* Intended decision / context (optional)
  === FR7 – Scenario Versioning ===
--* Every change to a scenario creates a new version
--* Previous versions remain accessible with timestamps and rationale
++* Every change to a scenario creates a new version
++* Previous versions remain accessible with timestamps and rationale
++* ParentVersionID links versions
  === FR8 – Scenario Comparison ===
--* Users can compare scenarios side by side
--* Show differences in assumptions, definitions, and evidence sets
++* Users can compare scenarios side by side
++* Show differences in assumptions, definitions, and evidence sets
  ----
@@ -245,21 +245,24 @@
  === FR9 – Evidence Ingestion ===
--* Attach external sources (articles, studies, datasets, reports, transcripts) to Scenarios
--* Allow multiple pieces of evidence per Scenario
++* Attach external sources (articles, studies, datasets, reports, transcripts) to Scenarios
++* Allow multiple pieces of evidence per Scenario
++* Support large file uploads (with size limits)
  === FR10 – Evidence Assessment ===
  For each piece of evidence:
--* Assign reliability / quality ratings
--* Capture who rated it and why
--* Indicate known limitations, biases, or conflicts of interest
++* Assign reliability / quality ratings
++* Capture who rated it and why
++* Indicate known limitations, biases, or conflicts of interest
++* Track evidence version history
  === FR11 – Evidence Linking ===
--* Link one piece of evidence to multiple scenarios if relevant
--* Make dependencies explicit (e.g., “Scenario A uses subset of evidence used in Scenario B”)
++* Link one piece of evidence to multiple scenarios if relevant
++* Make dependencies explicit (e.g., "Scenario A uses subset of evidence used in Scenario B")
++* Use ScenarioEvidenceLink table with RelevanceScore
  ----
@@ -269,19 +269,22 @@
  For each Scenario:
--* Provide a **probability- or likelihood-based verdict**
--* Capture uncertainty and reasoning
--* Distinguish between AKEL draft and human-approved verdict
++* Provide a **probability- or likelihood-based verdict**
++* Capture uncertainty and reasoning
++* Distinguish between AKEL draft and human-approved verdict
++* Support Mode 1 (draft), Mode 2 (AI-generated), Mode 3 (human-reviewed)
  === FR13 – Truth Landscape ===
--* Aggregate all scenario-specific verdicts into a “truth landscape” for a claim
--* Make disagreements visible rather than collapsing them into a single binary result
++* Aggregate all scenario-specific verdicts into a "truth landscape" for a claim
++* Make disagreements visible rather than collapsing them into a single binary result
++* Show parallel scenarios and their respective verdicts
  === FR14 – Time Evolution ===
--* Show how verdicts and evidence evolve over time
--* Allow users to see “as of date X, what did we know?”
++* Show how verdicts and evidence evolve over time
++* Allow users to see "as of date X, what did we know?"
++* Maintain complete version history for auditing
  ----
@@ -289,154 +289,196 @@
  === FR15 – Workflow States ===
--* Draft → In Review → Published / Rejected
--* Separate states for Claims, Scenarios, Evidence, and Verdicts
++* Draft → In Review → Published / Rejected
++* Separate states for Claims, Scenarios, Evidence, and Verdicts
++* Support Mode 1/2/3 publication model
  === FR16 – Moderation & Abuse Handling ===
--* Allow Moderators to hide content or lock edits for abuse or legal reasons
--* Keep internal audit trail even if public view is restricted
++* Allow Moderators to hide content or lock edits for abuse or legal reasons
++* Keep internal audit trail even if public view is restricted
++* Support user reporting and flagging
  === FR17 – Audit Trail ===
--* Every significant action (create, edit, publish, delete/hide) is logged with:
--  * Who did it
--  * When
--  * What changed
--  * Why (short comment, optional but recommended)
++* Every significant action (create, edit, publish, delete/hide) is logged with:
++** Who did it
++** When (timestamp)
++** What changed (diffs)
++** Why (justification text)
  ----
--= Federation Requirements =
++== Quality Gates & AI Review ==
--FactHarbor is designed to operate as a **federated network of nodes**.
++=== FR18 – Quality Gate Validation ===
--=== FR18 – Node Autonomy ===
++Before AI-generated content (Mode 2) publication, enforce:
--* Each node can run independently (local policies, local users, local moderation)
--* Nodes decide which other nodes to federate with
++* Gate 1: Source Quality
++* Gate 2: Contradiction Search (MANDATORY)
++* Gate 3: Uncertainty Quantification
++* Gate 4: Structural Integrity
--=== FR19 – Data Sharing Modes ===
++=== FR19 – Audit Sampling ===
--Nodes must be able to:
++* Implement stratified sampling by risk tier
++* Recommendation: 30-50% Tier A, 10-20% Tier B, 5-10% Tier C
++* Support audit workflow and feedback loop
--* Share claims and summaries only
--* Share selected claims, scenarios, and verdicts
--* Share full underlying evidence metadata where allowed
--* Opt-out of sharing sensitive or restricted content
++=== FR20 – Risk Tier Assignment ===
--=== FR20 – Synchronization & Conflict Handling ===
++* AKEL suggests tier based on domain, keywords, impact
++* Moderators and Experts can override
++* Risk tier affects publication workflow
--* Changes from remote nodes must be mergeable or explicitly conflict-marked
--* Conflicting verdicts are allowed and visible; not forced into consensus
++----
--=== FR21 – Federation Discovery ===
++== Federation Requirements ==
--* Discover other nodes and their capabilities (public endpoints, policies)
--* Allow whitelisting / blacklisting of nodes
++=== FR21 – Node Autonomy ===
--**Basic federation** (minimum):
++* Each node can run independently (local policies, local users, local moderation)
++* Nodes decide which other nodes to federate with
++* Trust levels: Trusted / Neutral / Untrusted
--* Subscribe to and import selected claims and scenarios from other nodes
--* Keep provenance (which node originated what)
--* Respect remote deletion / redaction notices where required by policy or law
++=== FR22 – Data Sharing Modes ===
--Advanced federation (later versions):
++Nodes must be able to:
--* Cross-node search
--* Federation-wide discovery and reputation signals
++* Share claims and summaries only
++* Share selected claims, scenarios, and verdicts
++* Share full underlying evidence metadata where allowed
++* Opt-out of sharing sensitive or restricted content
++=== FR23 – Synchronization & Conflict Handling ===
++
++* Changes from remote nodes must be mergeable or explicitly conflict-marked
++* Conflicting verdicts are allowed and visible; not forced into consensus
++* Support push/pull/subscription synchronization
++
++=== FR24 – Federation Discovery ===
++
++* Discover other nodes and their capabilities (public endpoints, policies)
++* Allow whitelisting / blacklisting of nodes
++* Global identifier format: `factharbor://node_url/type/local_id`
++
++=== FR25 – Cross-Node AI Knowledge Exchange ===
++
++* Share vector embeddings for clustering
++* Share canonical claim forms
++* Share scenario templates
++* Share contradiction alerts
++* NEVER share model weights
++* NEVER override local governance
++
  ----
--= Non-Functional Requirements (NFR) =
++== Non-Functional Requirements ==
--== NFR1 – Transparency ==
++=== NFR1 – Transparency ===
--* All assumptions, evidence, and reasoning behind verdicts must be visible
--* AKEL involvement must be clearly labeled
--* Users must be able to inspect the chain of reasoning and versions
++* All assumptions, evidence, and reasoning behind verdicts must be visible
++* AKEL involvement must be clearly labeled
++* Users must be able to inspect the chain of reasoning and versions
--== NFR2 – Security ==
++=== NFR2 – Security ===
--* Role-based access control
--* Transport-level security (HTTPS)
--* Secure storage of secrets (API keys, credentials)
--* Audit trails for sensitive actions
++* Role-based access control
++* Transport-level security (HTTPS)
++* Secure storage of secrets (API keys, credentials)
++* Audit trails for sensitive actions
--== NFR3 – Privacy & Compliance ==
++=== NFR3 – Privacy & Compliance ===
--* Configurable data retention policies
--* Ability to redact or pseudonymize personal data when required
--* Compliance hooks for jurisdiction-specific rules (e.g. GDPR-like deletion requests)
++* Configurable data retention policies
++* Ability to redact or pseudonymize personal data when required
++* Compliance hooks for jurisdiction-specific rules (e.g. GDPR-like deletion requests)
--== NFR4 – Performance ==
++=== NFR4 – Performance ===
--* POC: typical interactions < 2 s
--* Release 1.0: < 300 ms for common read operations after caching
--* Degradation strategies under load (e.g. partial federation results, limited history)
++* POC: typical interactions < 2 s
++* Release 1.0: < 300 ms for common read operations after caching
++* Degradation strategies under load
--== NFR5 – Scalability ==
++=== NFR5 – Scalability ===
--* POC: ~50 internal testers on one node
--* Beta 0: ~100 external testers on one node
--* Release 1.0: **2000+ concurrent users** on a reasonably provisioned node
++* POC: 50 internal testers on one node
++* Beta 0: 100 external testers on one node
++* Release 1.0: **2000+ concurrent users** on a reasonably provisioned node
--Suggested technical targets for Release 1.0:
++Technical targets for Release 1.0:
--* Scalable monolith or early microservice architecture
--* Sharded vector database (for semantic search)
--* Optional IPFS or other decentralized storage for large artefacts
--* Horizontal scalability for read capacity
++* Scalable monolith or early microservice architecture
++* Sharded vector database (for semantic search)
++* Optional IPFS or other decentralized storage for large artifacts
++* Horizontal scalability for read capacity
--== NFR6 – Interoperability ==
++=== NFR6 – Interoperability ===
--* Open, documented API
--* Modular AKEL that can be swapped or extended
--* Federation protocols that follow open standards where possible
--* Standard model for external integrations (e.g. news platforms, research tools)
++* Open, documented API
++* Modular AKEL that can be swapped or extended
++* Federation protocols that follow open standards where possible
++* Standard model for external integrations
--== NFR7 – Observability & Operations ==
++=== NFR7 – Observability & Operations ===
--* Metrics for performance, errors, and queue backlogs
--* Logs for key flows (claim intake, scenario changes, verdict updates, federation sync)
--* Health endpoints for monitoring
++* Metrics for performance, errors, and queue backlogs
++* Logs for key flows (claim intake, scenario changes, verdict updates, federation sync)
++* Health endpoints for monitoring
--== NFR8 – Maintainability ==
++=== NFR8 – Maintainability ===
--* Clear module boundaries (API, core services, AKEL, storage, federation)
--* Backward-compatible schema migration strategy where feasible
--* Configuration via files / environment variables, not hard-coded
++* Clear module boundaries (API, core services, AKEL, storage, federation)
++* Backward-compatible schema migration strategy where feasible
++* Configuration via files / environment variables, not hard-coded
--== NFR9 – Usability ==
++=== NFR9 – Usability ===
--* UI optimized for **exploring complexity**, not hiding it
--* Support for saved views, filters, and user-level preferences
--* Progressive disclosure: casual users see summaries, advanced users can dive deep
++* UI optimized for **exploring complexity**, not hiding it
++* Support for saved views, filters, and user-level preferences
++* Progressive disclosure: casual users see summaries, advanced users can dive deep
  ----
--= Release Levels =
++== Release Levels ==
  === Proof of Concept (POC) ===
--* Single node
--* Limited user set (~50 internal testers)
--* Basic claim → scenario → evidence → verdict flow
--* Minimal federation (optional)
++* Single node
++* Limited user set (50 internal testers)
++* Basic claim → scenario → evidence → verdict flow
++* Minimal federation (optional)
++* AI-generated publication (Mode 2) demonstration
++* Quality gates active
  === Beta 0 ===
--* One or few nodes
--* External testers (~100)
--* Expanded workflows and basic moderation
--* Initial federation experiments
++* One or few nodes
++* External testers (100)
++* Expanded workflows and basic moderation
++* Initial federation experiments
++* Audit sampling implemented
  === Release 1.0 ===
--* 2000+ concurrent users
--* Scalable monolith or early microservices
--* Sharded vector DB
--* IPFS optional
--* High automation (AKEL assistance)
--* Multi-node federation
++* 2000+ concurrent users
++* Scalable architecture
++* Sharded vector DB
++* IPFS optional
++* High automation (AKEL assistance)
++* Multi-node federation with full sync protocol
++* Mature audit system
++----
++
++
++
++== Related Pages ==
++
++
++
++* [[AKEL (AI Knowledge Extraction Layer)>>FactHarbor.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]]
++* [[Automation>>FactHarbor.Specification.Automation.WebHome]]
++* [[Workflows>>FactHarbor.Specification.Workflows.WebHome]]
++* [[Governance>>FactHarbor.Organisation.Governance]]

Changes for page Requirements

Summary

Details

Applications

Navigation

Need help?