Learn Knowledge

POST /knowledge-learn

Store one fact, after the write-time validation of annex 10 §6.3 and Q-M2.

201 for the merge outcome too, deliberately: the caller’s fact is now represented — by the incumbent whose confidence just rose — and the body says which of the two happened. A 200/201 split would make every client branch on a distinction the body already carries.

Role floor

Requires member or above. The floor is a minimum, not a grant: scope filtering still applies on top of it, and a resource in another tenant answers 404 rather than 403.

Request body — KnowledgeLearnRequest

Field	Type		Notes
knowledge_set	string	required	min length 1 max length 120
content	string	required	min length 1 max length 20000
title	string | null	optional	max length 300
kind	fact | rule | open_question | hub	optional	Default "fact".
importance	low | normal | high	optional	Default "normal".
tags	string[]	optional	Default [].
supersedes_hint	string | null	optional	max length 2000

Responses

Status	Description	Body
201	Successful Response	KnowledgeLearnView
422	Validation Error	HTTPValidationError

Only the success paths are declared

Any operation may also answer any status in the error catalogue, and every failure body is the platform envelope — including the 422 this document types as HTTPValidationError.

Example

The body shows the fields the schema always carries. Which combination is legal is a service rule the schema cannot express, so read the description above before copying this.

curl -X POST https://your-deployment.example.com/knowledge-learn \
  -H "Authorization: Bearer $COBRE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
       "knowledge_set": "string",
       "content": "string"
     }'

Response — KnowledgeLearnView

Field	Type		Notes
stored	boolean	required	—
item_id	string (uuid)	required	—
merged_into	string (uuid) | null	required, nullable	—
superseded_candidate	string (uuid) | null	required, nullable	—