Knowledge Base Update & Evidence Feed
Pricing
$0.25 / completed knowledge-update plan
Knowledge Base Update & Evidence Feed
Turn completed document exports into reviewable knowledge-base update plans. Get changed-text actions, metadata patches, coverage holds and a compact evidence package. $0.25 per completed plan, including no-change checks. No crawling or destination writes.
Pricing
$0.25 / completed knowledge-update plan
Rating
0.0
(0)
Developer
JJ Toolworks
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
a day ago
Last modified
Categories
Share
Knowledge Base Update and Evidence Feed
Turn completed document exports into a reviewable knowledge-base update plan. Identify new text, metadata changes, unchanged content and documents that need to be held for review. Useful for agencies and developers maintaining client documentation or AI retrieval systems.
Price: $0.25 per completed bounded plan, including a no-change check. The fee is requested only after the output artifacts and completion manifest are saved. Rejected inputs and failures before complete delivery request no JJ processing fee. No startup or dataset-item fee is configured. A completed plan can include held documents. This Actor prepares work; it does not apply it to a customer system.
Start with the example
- Keep Input mode set to
inlineand Output delivery set tocompact. - The Planning contract example contains two explicitly synthetic documents. Replace them with documents you are authorized to process. Use stable IDs, URLs, titles, text, extractionProfile and fetchedAt timestamps.
- Keep namespace, scope and extraction settings stable between cycles. Include an acknowledged applied baseline when comparing an update. A first run without a baseline proposes an initial import.
- Use 512 MB, restart on error Off, and a maximum run cost of at least $0.25. A $0.50 cap is suitable for the example. For owner development runs, Apify can display platform usage separately.
- Inspect the summary and evidence review. Download the records named by the complete manifest before consuming the plan.
The example inventory is partial. Do not mark a delta, a truncated export or a failed crawl as a complete inventory. Omitted or failed documents retain their previous evidence rather than silently becoming deletions. Proposed text removals still require review.
Input contracts
This release accepts supplied exports only. plannerInput.source.format supports documents, JJ Bulk Website Content Export rows (jj-content), and JJ Website Change Monitor rows (jj-changes). Arbitrary third-party crawler output needs explicit field mapping; it is not a verified native integration. Live producer-dataset ingestion is outside the verified release.
For documents, each healthy item needs a stable id, url, original text, complete: true, extractionProfile and a valid fetchedAt. Source completion and immutability are caller assertions. Preserve error rows and scope/coverage information so the plan can distinguish uncertainty from confirmed changes. Use the supplied two-document example to learn the envelope before loading a larger export.
What you receive
- One summary row with counts of new, changed, unchanged and held documents and proposed actions.
- A document-level HTML review and CSV work list.
- A lossless plan package with actions, citations, passages, holds and a candidate baseline.
- Source-verification notes, a completion manifest, and a separate billing receipt.
Compact delivery stores evidence once in bounded compressed parts. PLAN is the package index; ACTIONS and CANDIDATE_SNAPSHOT are references into that plan. They are not standalone action arrays or an already-applied baseline. Legacy mode returns full JSON artifacts and reaches size limits sooner.
Consumer handoff and recurring checks
The companion Node.js 22+ source package includes a free local compatibility checker, decoder and receipt helper; it uses no third-party libraries. The checker evaluates the actual input and output size before a cloud run:
To decode compact output, save all JSON records as KEY.json, the CSV as REVIEW.csv, the report as REVIEW_HTML.html, and each binary part as PLAN_PART_001.bin etc. Keep MANIFEST.json with them:
The decoder checks every record size/hash, part order, decompression bound and reconstructed plan identity. Checksums detect corruption; they do not authenticate a sender.
After reviewing the holds and completing the destination work, generate a receipt template:
The template starts with confirmedApplied: false. Confirm actual destination success for every listed action, enter the actual reviewer/time, and only then set it to true. Create the next baseline with:
The helper rejects partial or mismatched receipts and never overwrites existing evidence. It checks a caller's acknowledgement; it neither connects to a destination nor independently verifies that the work happened. Supply the resulting baseline in the next Planning contract to avoid re-proposing already applied work.
Limits and failure behavior
Cloud input is limited to 8 MiB including baseline. Safety ceilings are 1,000 documents, 25,000 chunks, 8 MiB source text and a 24 MiB serialized plan. These are maximum guards, not a promised usable batch size: text density and baseline size matter. Binary parts are at most 1 MiB and compressed plan data at most 8 MiB. The free checker reports actual compatibility and delivery sizes. Split oversized work into explicit stable scopes; do not silently truncate it.
No crawling, embeddings, automated deletion, alerts, subscriptions or destination synchronization is included. Failed or uncertain sources remain visible as holds. The run uses limited permissions and its own storage. Do not put passwords or API keys in input.
Fee requests are never automatically retried. A durable journal blocks rebilling on restart or resurrection. A billing response can be uncertain, and an acknowledged event can appear in run metadata after the immediate receipt readback. A failure writing a billing receipt after the fee was accepted does not undo the committed output or fee. Inspect the manifest and run event counts before restarting; there is no automatic refund or recharge workflow.
Validation
The local regression suite passes 141 tests. Completed-plan, no-change and rejected-input private cloud tests recorded exactly 1, 1 and 0 plan-fee events. Both completed plans passed all eight output checksums and exactly matched their local plans. Earlier compact delivery also passed a 100-document synthetic cloud test. These are technical and owner-operated tests, not proof of customer savings, collected payment, destination acceptance or repeat paid demand.
