Discovery and selection programs often accumulate information across forms, email, attachments, spreadsheets, meeting notes, and individual expertise. The result is duplicated records, weak traceability, slow committee preparation, limited reuse of institutional knowledge, and uncontrolled use of AI on sensitive or unverified material.
BE Discovery Platform is an evidence-led operations workspace designed to replace that fragmentation with canonical records and an auditable decision workflow. It is an independent Hadox concept and is not an official product of, or statement on behalf of, any organization referenced by the project.
The working private prototype covers the operational path from intake to reviewed communication:
AI is an assistant for provisional artifacts. It is not the authority over canonical records, selection, funding, or other consequential decisions.
The reference architecture uses a server-rendered operational workspace, cohesive domain services, a relational system of record, asynchronous workers, document extraction, and replaceable adapters for models, email, identity, and storage. Review state, provenance, audit events, retention, and access policy apply across the workflow rather than being confined to the interface.
Every AI artifact should identify its purpose, source-record set, generation time, processing strategy, review state, and approving user. Sensitive source text should be minimized or redacted before external processing, and accepted output should remain linked to the evidence available at approval time.
A production edition requires strong authentication and MFA, server-side role or attribute authorization, program and tenant isolation, protected document parsing, append-only privileged and decision events, controlled model egress, safe non-production email defaults, tested recovery, and an explicit incident-response owner.
AI-generated scores or inferred characteristics must never be the sole basis for consequential decisions. Fairness, quality, retention, consent, and jurisdiction-specific handling rules must be defined with the institution operating each program.
The public GitHub repository documents the problem, users, value proposition, conceptual architecture, data method, maturity, limitations, security baseline, roadmap, and governance model.
It does not include the private application source, deployment configuration, commercial Velonic template or derived assets, client documents, demo credentials, personal data, operational records, or infrastructure details. A future public implementation must be rebuilt from a clean first-party codebase and pass legal provenance, secret, personal-data, dependency, test, and security release gates.
The private reference implementation is a functional prototype: the core domain model and end-to-end workflow are represented, major operational workspaces exist, and asynchronous assistance is demonstrated. It is not yet production-certified. Priority work includes a first-party interface, centralized authorization, synthetic demonstration data, negative-access tests, observable background jobs, governed integrations, backup restoration exercises, and named operational ownership.
The public concept material is proprietary and source-visible, not open source. Public visibility does not grant a right to reuse the material beyond the terms in the repository's license. Third-party names and materials retain their respective rights, and references do not imply sponsorship, endorsement, or an official relationship.