Instance

http://3.225.169.87:8502/

https://www.aifaq.pro/linux-foundation-dt.html

Proposal

Proposal to Advance AIFAQ Lab to Incubation

Submitted to: Linux Foundation Decentralized Trust (LFDT) – Technical Advisory Committee (TAC)
Submitted by: AIFAQ Lab
Date: December 2025

1. Executive Summary

AIFAQ Lab respectfully requests consideration by the LFDT Technical Advisory Committee to move the AIFAQ project from its current lab status into Incubation. Over the past year, AIFAQ has evolved into a robust, AI knowledge system designed to help enterprises securely operationalize their documentation, data governance, and AI-powered decision support.

The project aligns directly with the LFDT mission by providing open, decentralized, secure AI infrastructure that organizations can deploy within their own environments. AIFAQ enables trusted knowledge orchestration across documentation, structured and unstructured data, enterprise storage, and domain-specific knowledge bases.

This proposal outlines the project, its scope, development resources, governance, and maintainers, and confirms vendor neutrality per LFDT guidelines.

2. Project Description

AIFAQ is an open-source, enterprise-focused multi-agent Retrieval-Augmented Generation (RAG) framework designed to allow organizations to:

• Build private AI knowledge bases using their own documentation and data

• Deploy AI assistants that understand and reason over domain-specific information

• Operate fully within secure enterprise environments (Snowflake, AWS, on-prem)

• Maintain strict data isolation between tenants through private data “bins,” stages, and warehouses

• Automate ingestion, indexing, and retrieval of structured + unstructured data

• Integrate directly into existing workflows including Web Sites, Discord, Snowflake Cortex, and enterprise knowledge systems

Key Innovation:
AIFAQ provides a turnkey, vendor-neutral framework for multi-agent enterprise knowledge orchestration, meeting the rising need for organizations to adopt AI safely, with deterministic control over where data lives, how it’s stored, and how it’s queried.

AIFAQ is currently deployed in demonstration environments through:

• LFDT Chat Bot for researching difference between Fabric 1.2 and Fabric 1.3

• Snowflake Native App (Version 1) – unstructured document ingestion (PDF/DOCX/CSV/TXT) from Snowflake Stages

• AIFAQ Web Platform – admin dashboards, private document bins, role-based permissions

• Multi-Agent Orchestration Engine – research agent, summarization agent, verification agent, and persona-based assistants

• Founders Institute Case Study – currently active on the FI Keystone chapters Website, used throughout demos to illustrate enterprise onboarding, document segmentation, and permissioned knowledge delivery

The project is intended to become a standard for enterprise-grade, privacy-preserving RAG solutions within the LFDT ecosystem.

3. Project Scope

Technical Scope:

• Multi-agent orchestration engine for RAG and enterprise knowledge tasks

• Private tenant provisioning and isolated data silos for each organization

• Document ingestion pipelines for structured + unstructured data

• Snowflake Native App integrations (Version 1: unstructured ingestion; Version 2: Iceberg connectivity)

• Standard interfaces for embeddings, indexing, and retrieval

• Role-based access control and permission-aware knowledge delivery

• API and UI components for enterprise AI assistants

• Governance templates for safe enterprise AI adoption

Documentation Scope:

• User docs, admin guides, developer guides

• Implementation guidelines for Snowflake, AWS, Azure, Google Cloud

• Enterprise onboarding toolkit

• Persona agent library

Community Scope:

• Open governance under LFDT

• Developer collaboration, onboarding, and roadmap planning

• Standards alignment across LFDT platforms

• Meetups, Workshops and Webinars

4. Committed Development Resources

AIFAQ has active, ongoing development with both volunteer and institutional contributors. The following teams and individuals are committed for the 2024–2026 development cycle:

Core Development Contributors

Sponsors and Supporters

• LFDT mentors and community

• Ledger Academy (education case study + infrastructure)

• Innovators Alliance (enterprise advisory)

• Snowflake

• Founders Institute

This resource base provides a stable pipeline of ongoing development, documentation, and issue triage for incubation and beyond.

5. Initial Maintainers

The following maintainers have agreed to serve as the initial governing maintainers under LFDT incubation:

AIFAQ Initial Maintainers

1. Gianluca Capuzzi – Lead Maintainer

2. Madugula Jayaram – Maintainer, Snowflake & Data Engineering

3. Bobbi Muscara – Maintainer, Product & Documentation

4. Peter Chmiel – Maintainer, Data Governance & Architecture

Maintainer Responsibilities

• Reviewing and approving PRs

• Roadmap ownership

• Security and compliance review

• Ensuring vendor-neutral governance

• Community onboarding and contributor mentorship

These maintainers represent diverse professional backgrounds to avoid any single-vendor influence.

6. Vendor Neutrality Statement

AIFAQ is committed to strict vendor neutrality, consistent with the Open Source Guidelines of the Linux Foundation.

• The project supports multi-cloud and hybrid deployments (Snowflake, AWS, Azure, GCP, on-prem).

• No vendor-specific code paths are required to use AIFAQ.

• Snowflake Native App support is one optional deployment pathway among many.

• The maintainers represent multiple institutional affiliations, not a single corporate sponsor.

• All APIs, code, interfaces, and documentation are open-source and licensed permissively.

• No commercial licensing fees are required to run or modify AIFAQ.

Vendor neutrality is enforced through:

• Open technical steering

• Public issue tracking

• Multi-stakeholder governance

• Multiple implementation options

7. Alignment with LFDT Mission

AIFAQ strengthens the LFDT portfolio by:

• Advancing trustworthy AI through transparent data governance

• Enabling decentralized knowledge reasoning without centralizing data

• Enhancing public infrastructure for safe enterprise AI deployments

• Supporting education, mentorship, and community contribution

• Demonstrating real-world impact through projects such as Ledger Academy, The Giving Chain, and Snowflake Native AI solutions

AIFAQ is well-positioned to become a flagship LFDT incubation project.

8. Request for Incubation Status

AIFAQ Lab formally requests that the LFDT Technical Advisory Committee:

1. Review this proposal

2. Evaluate AIFAQ Lab’s readiness for Incubation

3. Approve AIFAQ’s transition to an incubated LFDT project

We welcome a TAC presentation and are prepared to provide:

• Technical demos

• Architecture and roadmap documentation

• Community engagement plan

• Governance and maintainer documentation

WORKSHEET

We welcome a TAC presentation and are prepared to provide:

• Technical demos

• Architecture and roadmap documentation

• Community engagement plan

• Governance and maintainer documentation

Roadmap

Our main goals for the next 12 months are:

1. Achieve LFDT Incubation status

2. Stabilize and document the core AIFAQ open-source architecture

3. Release a secure, multi-tenant private-data ingestion model

4. Build a thriving community of contributors, mentors, and adopters

5. Showcase enterprise use cases such as Ledger Academy, Giving Chain, and developer onboarding

From this, here is the roadmap table the TAC expects:

LFDT TAC Roadmap Proposal for AIFAQ Incubation (12-Month Plan)

Sequencing Logic

1. Governance & TAC Proposal First
   LF projects must demonstrate governance before code review.

2. Core Platform Release Early
   So TAC can evaluate technical direction and architecture.

3. Security & Isolation Next
   Critical for being a “Decentralized Trust” project.

4. Community Programs Parallel
   Required for incubation; shows project sustainability.

5. Enterprise pilots before Graduation
   Demonstrates real-world adoption.

Success Metrics (12-Month Targets)

• TAC Approval for Incubation

• Two tagged open-source releases (v1 + v2)

• 10+ external contributors

• Three successful enterprise pilots

• Security review passed with no major findings

• Active community engagement: >25 monthly participant

Codebase

• Code should exist as open source software in some form. Previous accepted projects have come up through labs

• DCO sign off should be enforced in the code repository as it transitions to LFDT. Historical commits that existed in the repository before a decision to transition the project to LFDT was made do not need to be squashed, in order to preserve metadata.

https://github.com/hyperledger-labs/aifaq/tree/agents

• Codebase should be Apache 2 licensable, without encumbrances

• Copyright and License PolicyPreview

Maintainers

• The project should have multiple maintainers. These maintainers need not be from different companies; however, having maintainers from different companies is seen as a positive sign. Proposals with only one maintainer have been rejected by prior TACs.

• The project should have demonstrable examples of POC/production uses publicly available.

• The project should have the backing of more than one organization/individuals (i.e., the project proposers should be able to demonstrate significant, long term contribution in codebase)

Community

1. Holding technical discussions in a public forum (e.g., design and implementation discussions)

2. Building the community

   1. Hosting public, community calls

   2. Working to diversify contributors and maintainers from the initial set of contributing organizations

   3. Mentoring new contributors to become maintainers

3. Supporting public, community forums (e.g. GitHub, Discord)

4. Submitting annual and quarterly reports to the TAC in a timely fashion

Sponsors

• Sponsors are advocates for the project. There should be more than one sponsor, and they should be from different organizations. They may or may not be committing resources to the project.

Legal

• Trademark concerns – project names should not be trademarked by a contributing company or if it is, then the trademark will need to be handed over to LFDT. Project names must be approved by the LFDT marketing committee

• Projects do not require a name prior to being submitted.

• Codebase should be Apache 2 licensable, without encumbrances

• Non-Apache 2 licensed code is possible, but requires Governing board approval (see allowed third-party licenses)

• Special examination should be given to copyleft and non-licensed code.

• Required patent licensing issues have prevented projects from entering Incubation.

• GPL licensing issues have prevented projects from entering Incubation.

• If code does not already have copyright, the code should be modified to include copyright as per Copyright and License Policy prior to being brought into LFDT.

Overlap with existing projects.

Project: Formally endorsed by the Technical Advisory Committee

Projects seeking to join LF Decentralized Trust must submit a formal proposal and secure endorsement from the Technical Advisory Committee (TAC) for incubation. Each project operates independently with its maintainers and Technical Steering Committee setting policies and governing operations. The TAC ensures projects maintain their scope and adhere to best open source practices without intervening in governance. The guidelines below help maintain the integrity and collaborative nature of the ecosystem, promoting a path to successful project incubation.

Requirements for Project Proposals:

• Have a Clear Description: Ensure the project description is precise and understandable

• Have a Well-Defined Scope: Define clear boundaries and objectives for the project

• Identify Committed Development Resources: Show evidence of strong, ongoing development support

• Identify Initial Maintainers: List the initial leaders responsible for project maintenance

• Be Vendor Neutral: Maintain neutrality, avoiding undue influence from any single vendor

1. Prepare your proposal 

Review the proposal requirements, then prepare your presentation for the TAC.

Review requirements

Project Proposal Process

A Project at LF Decentralized Trust is a collection of specific Maintainers, users and other developers, code, releases, issues, and other activity oriented around a common software-implemented mission.

This project proposal template ushers originators, designers, implementers, and testers of a project through community and TAC approval. The proposal should evolve organically as it moves through the stages of conception, design, approval, implementation and deployment. The project and hence the proposal may also need several iterations. In its terminal forms it can also serve as a short manual to the features of the project for users.

This proposal template is descriptive and not normative, a guide rather than the law. Prior templates like the internet RFC process, Bitcoin Improvement Proposal, Python Improvement Proposal etc. were used as guidelines to develop this template.

The seed of a new project has to be vetted in a public forum like the TAC mailing list before creating a project proposal. It is best if the project has technical champions who believe in the project and are the maintainers of the project. The technical champions can change in the middle of the project.

If this project proposal is for a feature that is unique to an existing LF Decentralized Trust project, please reach out to that project’s TSC to see about joining that project instead of creating a new project proposal. If discussion with the existing project community leads to not joining, then the proposal will be reviewed on its own merits as an independent project. Please note in the proposal the conversations with that project and the reason for not joining their efforts.

Please note that readability is very important. The language of the proposal should be English if possible as that is the lingua franca of the community. The Chicago Manual Of Style should be followed for explanation of abbreviations, references etc. This is extremely important as a clear statement of the problem and its technical details are helpful to coalesce the community around a solution and prompt volunteers. The outline of a project is given below with comments on the sections.

• Identifier a short description plus a serial number with a version (for example this document is Template for a Project 0.3)

• Sponsor(s) name and contact details including email address

• Abstract (less than 50 word) description of the project.

• Context if any, what is this project derived from? What if any is it related to?

• Dependent Projects if any, must be listed, and each dependent project's maintainers must sign off on the proposal before it is considered by the TAC. NOTE: If this project proposal is unique to an existing project, please discuss including this feature with that project’s TSC.

• Motivation for this project; a longer justification of the project. This may be a couple of hundred words. Why is this project better at solving a problem compared to parallel proposals or implemented projects?

• Status of the project: See lifecycle documentation.

• Solution to the problem addressed in the motivation section. Try to make this as detailed as possible. The topics given below are just suggestions, address only if they are relevant to your problem:

  • Transactions - including types, confidentiality, signing, traceability, identity of participants, contracts (scripts)

  • Effects on User facing Clients that help with transaction formation (similar to Wallets in BTC)

  • Effects on the network, throughput, visibility to other participants, change in protocol if any, criteria for network participation

  • Block formation and ledger formation: Consensus algorithm, size overhead, effects on the throughput and rate