@panaversity/ksor 0.0.43 → 0.0.44
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +27 -0
- package/docs/ingesting.md +15 -0
- package/package.json +1 -1
- package/templates/scaffold/knowledge/what-is-a-ksor.flashcards.yaml +0 -25
- package/templates/scaffold/knowledge/what-is-a-ksor.quiz.yaml +0 -90
- package/templates/scaffold/knowledge/what-is-a-ksor.slides.yaml +0 -65
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,32 @@
|
|
|
1
1
|
# @panaversity/ksor
|
|
2
2
|
|
|
3
|
+
## 0.0.44
|
|
4
|
+
|
|
5
|
+
### Patch Changes
|
|
6
|
+
|
|
7
|
+
- 2ece135: **A lighter starter, and `refresh` finally says what it does** (issues #173, #171).
|
|
8
|
+
|
|
9
|
+
`ksor init` put five of `knowledge/`'s eleven files onto a single concept — 199
|
|
10
|
+
lines of companions against a 40-line document — so the first thing an adopter
|
|
11
|
+
opened was one document wearing four attachments. The flashcards, quiz and
|
|
12
|
+
slides companions are gone; `what-is-a-ksor.summary.md` stays, because it is the
|
|
13
|
+
only companion carrying a governance rule (exactly `type: Summary`, one key), so
|
|
14
|
+
the profile marker is still demonstrated. `knowledge/` goes from 11 files to 8.
|
|
15
|
+
|
|
16
|
+
What that costs, stated rather than glossed: the recall, quiz and slides tabs are
|
|
17
|
+
no longer shown by the starter, and an adopter meets those features in the docs
|
|
18
|
+
instead. Nothing about the companion mechanism changed — decision 24 is
|
|
19
|
+
untouched, and the migrate fixture that proves a deck migrates byte-identically
|
|
20
|
+
is frozen from an older tree, so it still covers the case.
|
|
21
|
+
|
|
22
|
+
And `pnpm refresh` was a name the constitution never defined, sitting beside
|
|
23
|
+
`pnpm ingest` and `ksor ingest` with nothing saying how the three relate. It has
|
|
24
|
+
a vocabulary entry now, and `docs/ingesting.md` opens with the model: `ksor
|
|
25
|
+
build` makes the SITE correct with no database, `ksor ingest` makes the AGENT
|
|
26
|
+
DOOR correct, and `pnpm refresh` runs both. The split between the scaffold's
|
|
27
|
+
script and the underlying verb is deliberate, and now it is written down instead
|
|
28
|
+
of inferred.
|
|
29
|
+
|
|
3
30
|
## 0.0.43
|
|
4
31
|
|
|
5
32
|
### Patch Changes
|
package/docs/ingesting.md
CHANGED
|
@@ -14,6 +14,21 @@ embedding cost on every cold start and would need write credentials at runtime.
|
|
|
14
14
|
So **a first deploy with no ingest serves an empty record.** It is not broken;
|
|
15
15
|
nothing was ever published to it.
|
|
16
16
|
|
|
17
|
+
## `ksor ingest` or `pnpm refresh`?
|
|
18
|
+
|
|
19
|
+
Both, and they are not alternatives — one contains the other.
|
|
20
|
+
|
|
21
|
+
| | makes correct | needs a database |
|
|
22
|
+
| -------------- | ----------------------------------------------------------------------------------- | ---------------- |
|
|
23
|
+
| `ksor build` | the **site** — checks the record, regenerates the indexes, writes `build.lock.json` | no |
|
|
24
|
+
| `ksor ingest` | the **agent door** — embeds, loads Postgres, flips a generation | yes |
|
|
25
|
+
| `pnpm refresh` | both, in order: `ksor build` → `ksor ingest --flip` → `ksor gc` | yes |
|
|
26
|
+
|
|
27
|
+
`pnpm refresh` is the scaffold's script and the one to reach for by hand — it
|
|
28
|
+
is a single command that leaves every surface current. `ksor ingest` is the
|
|
29
|
+
verb underneath it, and it is what CI, a deploy step, or an agent calls when
|
|
30
|
+
the individual step is the subject. The rest of this page is about that verb.
|
|
31
|
+
|
|
17
32
|
## Before the first command
|
|
18
33
|
|
|
19
34
|
Ingest reads your markdown, sends each new chunk to an embedding provider, and
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@panaversity/ksor",
|
|
3
|
-
"version": "0.0.
|
|
3
|
+
"version": "0.0.44",
|
|
4
4
|
"description": "Knowledge System of Record — compile governed markdown into a static site for people and an MCP server for AI agents, with citations and measured abstention.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"abstention",
|
|
@@ -1,25 +0,0 @@
|
|
|
1
|
-
# A recall deck for what-is-a-ksor.md.
|
|
2
|
-
#
|
|
3
|
-
# Every card states only what its parent document states — a deck is a way of
|
|
4
|
-
# rehearsing the record, never a second source. Ask your coding agent to write
|
|
5
|
-
# one of these from a document, and to check each answer against it.
|
|
6
|
-
deck:
|
|
7
|
-
title: What a KSoR is
|
|
8
|
-
description: Recall checks for the record's own definition of itself.
|
|
9
|
-
cards:
|
|
10
|
-
- front: When a spreadsheet disagrees with the ledger, which one wins?
|
|
11
|
-
back: The ledger. A system of record is the copy that governs.
|
|
12
|
-
why: Which copy would your organization's agents trust today?
|
|
13
|
-
|
|
14
|
-
- front: A traditional system of record settles the state of a business. What does a KSoR settle?
|
|
15
|
-
back: What the organization knows and how it should operate — which policies apply, which thresholds are approved, what a term means here.
|
|
16
|
-
|
|
17
|
-
- front: What problem does a KSoR solve?
|
|
18
|
-
back: Scatter. Knowledge spread across wikis, decks, PDFs, prompts and someone's memory, with no authoritative answer to which knowledge an agent should trust.
|
|
19
|
-
|
|
20
|
-
- front: Why can an assistant not tell you which of its sentences were checked?
|
|
21
|
-
back: Because it answers from everything it has ever read. Nothing in that process distinguishes a checked claim from an unchecked one.
|
|
22
|
-
why: This is the gap the record exists to close.
|
|
23
|
-
|
|
24
|
-
- front: Does provenance prove that a document is correct?
|
|
25
|
-
back: No. Provenance proves who said what, and when. Whether the source is any good is a separate matter, and the record never claims otherwise.
|
|
@@ -1,90 +0,0 @@
|
|
|
1
|
-
# A quiz for what-is-a-ksor.md.
|
|
2
|
-
#
|
|
3
|
-
# Every question and every answer states only what its parent document states —
|
|
4
|
-
# a quiz is a way of checking the record, never a second source. Ask your coding
|
|
5
|
-
# agent to write one from a document, and to check each answer back against it.
|
|
6
|
-
#
|
|
7
|
-
# Two habits worth copying. The options are kept close in LENGTH, because if the
|
|
8
|
-
# correct answer is reliably the longest one a reader passes by looking rather
|
|
9
|
-
# than by reading. And the correct answer moves POSITION between questions: a
|
|
10
|
-
# quiz whose answer is usually B is a quiz you can pass without the document.
|
|
11
|
-
# `pnpm check` and `pnpm build` both refuse a quiz where either is true — the
|
|
12
|
-
# first draft of this one was refused for putting four of five answers at B.
|
|
13
|
-
quiz:
|
|
14
|
-
title: Check yourself
|
|
15
|
-
description: Five questions on what this record is, and what it is not.
|
|
16
|
-
questions:
|
|
17
|
-
- question: A spreadsheet and the ledger disagree about a number. Which one is authoritative?
|
|
18
|
-
options:
|
|
19
|
-
- Whichever of the two was most recently edited
|
|
20
|
-
- The spreadsheet, being closer to the daily work
|
|
21
|
-
- The ledger, because it is the governing copy
|
|
22
|
-
- Neither, until a person reconciles the two
|
|
23
|
-
answer: 2
|
|
24
|
-
explanation: >
|
|
25
|
-
A system of record is the copy that governs, so the ledger wins by
|
|
26
|
-
definition rather than by being newer or closer to the work. Recency is
|
|
27
|
-
not authority: an edit made this morning in a spreadsheet nobody governs
|
|
28
|
-
is still ungoverned. Reconciliation is something a record makes possible,
|
|
29
|
-
not a precondition for having an answer at all.
|
|
30
|
-
source: The opening definition
|
|
31
|
-
|
|
32
|
-
- question: What does a KSoR settle that a traditional system of record does not?
|
|
33
|
-
options:
|
|
34
|
-
- The state of a business, such as its balances
|
|
35
|
-
- Which vendor an organization has chosen to use
|
|
36
|
-
- How much storage the organization is paying for
|
|
37
|
-
- What the organization knows and how it operates
|
|
38
|
-
answer: 3
|
|
39
|
-
explanation: >
|
|
40
|
-
A traditional system of record settles the state of a business — what is
|
|
41
|
-
owed, what is owned, what was transacted. A KSoR settles the layer above
|
|
42
|
-
it: which policies apply, which thresholds are approved, and what a term
|
|
43
|
-
means inside this organization. Vendor choice and storage cost are
|
|
44
|
-
consequences of running one, never what it is authoritative for.
|
|
45
|
-
source: What this record settles
|
|
46
|
-
|
|
47
|
-
- question: Why can an ordinary assistant not tell you which of its sentences were checked?
|
|
48
|
-
options:
|
|
49
|
-
- It answers from everything it has ever read
|
|
50
|
-
- It was not given enough context to work with
|
|
51
|
-
- Its answers are checked, but only in summary
|
|
52
|
-
- It lacks permission to reveal its own sources
|
|
53
|
-
answer: 0
|
|
54
|
-
explanation: >
|
|
55
|
-
It answers from everything it has ever read, and nothing in that process
|
|
56
|
-
separates a checked claim from an unchecked one. This is not a context
|
|
57
|
-
problem and not a permissions problem: more context cannot create a
|
|
58
|
-
distinction that was never recorded in the first place. The record closes
|
|
59
|
-
the gap by governing what gets read.
|
|
60
|
-
source: Why an assistant cannot answer that question
|
|
61
|
-
|
|
62
|
-
- question: What problem does a KSoR exist to solve?
|
|
63
|
-
options:
|
|
64
|
-
- Storage costs across a growing organization
|
|
65
|
-
- Scatter, with no authoritative copy to trust
|
|
66
|
-
- The speed at which an assistant can reply
|
|
67
|
-
- The difficulty of writing documentation well
|
|
68
|
-
answer: 1
|
|
69
|
-
explanation: >
|
|
70
|
-
The problem is scatter: knowledge spread across wikis, decks, PDFs,
|
|
71
|
-
prompts and somebody's memory, with no authoritative answer to which of
|
|
72
|
-
them an agent should trust. Speed and cost are not what the record
|
|
73
|
-
addresses, and writing well is valuable but does not by itself tell an
|
|
74
|
-
agent which of two documents governs.
|
|
75
|
-
source: The problem it solves
|
|
76
|
-
|
|
77
|
-
- question: Abstention — answering "not in this corpus" — is best described as what?
|
|
78
|
-
options:
|
|
79
|
-
- An error state the record should minimise
|
|
80
|
-
- A temporary gap, pending the next ingest
|
|
81
|
-
- A setting an operator turns on when ready
|
|
82
|
-
- A correct answer the record is meant to give
|
|
83
|
-
answer: 3
|
|
84
|
-
explanation: >
|
|
85
|
-
Abstention is a correct answer, never an error and never a licence to
|
|
86
|
-
fall back on general model knowledge. A record that answers everything
|
|
87
|
-
has stopped being a record of anything in particular. It is not a gap
|
|
88
|
-
waiting to be filled, and while the gate that enforces it is configured
|
|
89
|
-
deliberately, the honesty it expresses is the product itself.
|
|
90
|
-
source: What this record settles, and what it does not
|
|
@@ -1,65 +0,0 @@
|
|
|
1
|
-
# The presentation that teaches what-is-a-ksor.md.
|
|
2
|
-
#
|
|
3
|
-
# These slides live IN the record: reviewed in a pull request, versioned with
|
|
4
|
-
# the document, withdrawn when it is withdrawn, and rendered by the site — so
|
|
5
|
-
# there is no third party, no dead link, and nothing to keep in step by hand.
|
|
6
|
-
# Your coding agent writes them from the document; `.agents/skills/make-slides/`
|
|
7
|
-
# is the procedure.
|
|
8
|
-
#
|
|
9
|
-
# A slide may only say what the document says. A deck is a way of presenting
|
|
10
|
-
# the record, never a second source.
|
|
11
|
-
slides:
|
|
12
|
-
title: Introducing the record
|
|
13
|
-
description: The 15-minute version, for a room.
|
|
14
|
-
deck:
|
|
15
|
-
# The opening slide does NOT repeat the page title. It sits directly under
|
|
16
|
-
# it, so restating it wastes the one slide everyone actually looks at.
|
|
17
|
-
- heading: Which copy should an agent trust?
|
|
18
|
-
lead: That question is what this record exists to answer, and nothing in an ordinary assistant can.
|
|
19
|
-
note: Open with the question, not the definition. The definition lands after they feel the problem.
|
|
20
|
-
|
|
21
|
-
- heading: The problem it solves
|
|
22
|
-
bullets:
|
|
23
|
-
- Knowledge is scattered across wikis, decks, PDFs, prompts and memory
|
|
24
|
-
- No authoritative answer to the question an agent has to ask
|
|
25
|
-
- Which of these copies should I trust?
|
|
26
|
-
note: Ask the room where their real answer lives today. Wait for the disagreement — it always comes.
|
|
27
|
-
|
|
28
|
-
- heading: When two copies disagree, one wins
|
|
29
|
-
bullets:
|
|
30
|
-
- A traditional system of record settles the state of a business
|
|
31
|
-
- The ledger is authoritative; the spreadsheet is not
|
|
32
|
-
- Recency is not authority — a fresh edit to an ungoverned copy is still ungoverned
|
|
33
|
-
note: This is the whole idea. If they take one slide away, it is this one.
|
|
34
|
-
|
|
35
|
-
- heading: AI never had one
|
|
36
|
-
bullets:
|
|
37
|
-
- An assistant answers from everything it has ever read
|
|
38
|
-
- Nothing in that separates a checked claim from an unchecked one
|
|
39
|
-
- Which is exactly why it cannot tell you which of its sentences were verified
|
|
40
|
-
note: Not a criticism of the models. It is a missing layer, and that layer is what we are building.
|
|
41
|
-
|
|
42
|
-
- heading: What this record settles
|
|
43
|
-
bullets:
|
|
44
|
-
- Which policies apply, and which thresholds are approved
|
|
45
|
-
- What a term means inside this organization
|
|
46
|
-
- What to do when the answer is not known
|
|
47
|
-
note: Point at the third one. It is the one people do not expect.
|
|
48
|
-
|
|
49
|
-
- heading: Abstention is a feature
|
|
50
|
-
lead: '"Not in this corpus" is a correct answer — never an error, and never a licence to fall back on model knowledge.'
|
|
51
|
-
note: A record that answers everything has stopped being a record of anything in particular.
|
|
52
|
-
|
|
53
|
-
- heading: One source, two surfaces
|
|
54
|
-
bullets:
|
|
55
|
-
- The website is for people
|
|
56
|
-
- The MCP server is for agents
|
|
57
|
-
- Both render the same build — they can never disagree
|
|
58
|
-
note: Open llms.txt beside the page here. Seeing one source render twice lands better than describing it.
|
|
59
|
-
|
|
60
|
-
- heading: Where the edges are
|
|
61
|
-
bullets:
|
|
62
|
-
- Provenance proves who said what, and when
|
|
63
|
-
- It does not prove the source was right — that is a separate judgment
|
|
64
|
-
- Governance is a ladder, not a gate; level 0 works on day one
|
|
65
|
-
note: Say the second bullet out loud. Overselling provenance is how these systems lose trust.
|