Adding knowledge

Two ways in. One guarded path to publication.

An agent can discover a candidate, and you can propose your own practice, source, correction, or missing topic. Neither route publishes directly. Every proposal keeps its uncertainty visible while it moves through review.

Where proposals start

Agent route

Discovery creates a candidate

The Research Scout follows maintained research questions, collects scholarly metadata, removes duplicates, and records a candidate with Topic and risk context.

Boundary: a title, abstract, DOI, or search result is still unreviewed. The scout cannot turn it into a published claim.

Community route

Your proposal enters the same queue

You can suggest an original practice, an executable protocol, a missing problem, a source, a correction, or a taxonomy change through a structured public form.

Boundary: a submission is a proposal, not approval. Its origin, evidence, uncertainty, and possible conflicts remain visible.

The review path

Capture. The agent or contributor records the problem, proposed action or source, known limitations, and enough context to reproduce the idea.
Triage. A maintainer checks for duplicates, maps the proposal to the closest canonical Topic, adds safety flags, and decides whether it needs source review, editorial work, or a correction.
Review the actual source. If the proposal makes an evidence claim, the Evidence Reviewer reads the source and records what it supports, challenges, or does not establish. Metadata alone cannot pass this step.
Build the knowledge record. The Protocol Builder turns an accepted action into bounded steps with eligibility, a smallest first action, an observable signal, a stop/change rule, limitations, and provenance.
Fit and verify. The Taxonomy Curator preserves canonical identity and stable URLs. Automated checks compare page, API, data, retrieval, citation, and safety behavior.
Publish through review. A maintainer-reviewed change is merged only when its source and generated outputs agree. Rejected, restricted, or still-pending proposals do not silently appear as trusted recommendations.

agent discovery or your proposal → candidate → triage → source review when needed → protocol and taxonomy → checks → maintainer review → publish

What the labels mean

State	What you can conclude
Candidate / proposed	Worth looking at; not reviewed evidence and not a trusted recommendation.
`pending-review`	The record exists, but its evidence or wording still needs a decision.
`restricted`	Kept out of normal retrieval because the risk or evidence boundary is unresolved.
`practical`	A bounded, transparent practice that can be used without pretending it has stronger evidence than it does.
`reviewed`	The exact published claim is tied to an actual-source review with scope and limitations.

Choose what you want to propose

Your own idea

Practice, protocol, or missing problem

Share a technique you use, a short sequence someone can try, or a problem the library does not answer yet. Include attribution if the idea is adapted from someone else.

Open a knowledge proposal →

Research lead

Source worth screening

Suggest a paper, review, guideline, replication, or negative/null result and explain which Brali claim it may support, challenge, or correct.

Suggest a source →

Existing record

Correction or missing provenance

Point to the affected URL or canonical ID, explain what is wrong, and describe the expected correction.

Report a correction →

Knowledge map

Topic, method, alias, or mapping

Propose a taxonomy change when it improves retrieval or semantic clarity without silently changing a stable identity.

Propose a taxonomy change →

What makes a useful proposal

Name the concrete problem and who the idea is for.
Describe the smallest first action and any later steps.
Say what a person could observe to decide whether it helped.
Include a stop, change, or fallback condition when the action may not fit.
Link the original source or credit the origin when the idea is not yours.
State uncertainty, contraindications, conflicts, and known limitations plainly.

Do not include private, identifying, medical, client-restricted, or confidential information in a public GitHub issue.

What happens after you submit

Your issue becomes the traceable intake record. A maintainer may ask for a narrower claim, better attribution, a source, or a clearer first action. A proposal can be merged, revised, kept for later review, restricted, or declined. Silence is not approval, and publication timing is not guaranteed.

For the underlying contracts and agent responsibilities, read Agents & skills. For research, integration, localization, or commercial work, use Build with Brali.