Explore your document ↗
Add text, a file or a link and inspect possible connections to the parliamentary material.
See a real example ↗
Follow parliamentary documents and their source references.
Open the validator ↗
Check the example object structure in your browser.
Plan an implementation ↗
Identify sources, responsibility, conditions and integration needs.
Start with knowledge and its connections
Read about Knowledge Objects, relationships and the register, then intertweens. Continue to skills and learning before choosing which operational roles an implementation needs to support.
Read the protocol overview ↗From source to first check
First follow a document through its source, local registration, federated discovery and requested use. The real bill’s preserved XML, complete extracted text and relationships with evidence can be explored here. The fictional example embeds its entire text and scripted permission views.
- Choose a public or synthetic source record for your first test.
- Follow a relation to its exact passage and back to the source. Distinguish the complete document from the excerpt.
- Record identity, source, actor, time and conditions. Do not guess missing values.
- Open the example object and compare its fields with your record.
- Paste the object JSON into the validator and read each result.
What does a check establish?
Compare the object with the Wrapper guide. Check that its source can be located, its version is explicit and relationships distinguish source claims from your interpretations. Use the validator for the structural checks it describes.
A passing result does not prove source authenticity, factual truth or permission to use the material. The existing validator does not verify the complete learning cycle or full conformance with every profile.
Explore one question at a time
Who may see what? ↗
Switch perspectives and compare the visible objects. The example illustrates permitted views; it is not production access enforcement.
Has history changed? ↗
Try changes to synthetic records and read exactly what verification checks. Two nodes are simulated locally.
How does a challenge change a method? ↗
Add the reviewer’s challenge and follow the explanation, evidence and history. The example is scripted and runs no AI.
From examples to a local implementation
Use these questions to describe what an implementation needs. There is no ready-to-use node service or installation process here. Adapters, runtime, permission enforcement and federated exchange need to be implemented and verified for their context.
- Which knowledge and source systems are in scope? Identify a defined task and its source material.
- How will source identifiers and versions survive? Describe mapping to Knowledge Objects and detection of updates.
- Who may describe, review and change relationships? Specify responsibility, mandates and challenge handling.
- What may be discovered and used? Separate access from reuse and training; identify where rules are enforced.
- How will changes be recorded? Plan history, corrections, retention, export and recovery.
- Which profile will be supported and tested? Separate structure, history integrity, enforced permissions and practical value.
Plan how knowledge will be used and maintained
Adoption starts with an organisational question and responsibility for the knowledge. Technical choices need to follow that context.
- Use
- Choose a situation where sources or relationships are hard to follow. Describe what someone needs to understand or do.
- Responsibility
- Identify custodians, reviewers and those authorising use. Decide who receives corrections and challenges.
- Evaluation
- Describe the baseline and signs of improvement: can someone find the source, understand a difference and notice missing evidence? Record failures and limitations too.
- Maintenance
- Plan how versions, conditions and relationships stay current, how knowledge can be exported and when use should be reassessed.