# Concepts > Working ideas about context, judgment and AI. Open an idea, examine its parts and follow how it changes. - Canonical URL: https://www.svenspoede.com/concepts/ - Language: English - JSON: https://www.svenspoede.com/concepts/index.json - Complete public context: https://www.svenspoede.com/context.json These are ideas I work with and continue to develop. Each entry connects an explanation with something you can explore. Start with knowledge objects or follow a working method. ### Knowledge objects - ID: `knowledge-object` - Type: concept - Canonical page: https://www.svenspoede.com/concepts/knowledge-objects/ - Updated: 2026-09-19 A piece of knowledge becomes more useful when its meaning, evidence, boundaries and interfaces travel together. A useful statement rarely travels alone. Someone needs to know what it means, what supports it, where it applies and how it may be used. A knowledge object keeps those relationships attached. The object on this page is an example of that structure. Its subject is the idea itself. The same four layers organize the profile on the homepage, where their subject is a person and his work. The shape stays the same; the context changes. ## What the object carries Meaning gives a statement its intended interpretation. Evidence makes its support inspectable. Boundaries preserve limits, uncertainty and responsibility. Interfaces let people and software use that same context in different forms. These are connected concerns. A new source may narrow a claim. A changed boundary may alter what an interface should expose. Treating the parts as a single paragraph makes those changes harder to see. ## A worked example: a pilot invitation Imagine a shared campaign workspace that is available to invited teams. A general release date has not been confirmed. A launch draft says: “Available to everyone next month.” - **Meaning:** help eligible teams decide whether to request a pilot invitation. - **Evidence:** the pilot note confirms invitation-only access, but gives no general release date. - **Boundaries:** the draft may not broaden access or invent a date; a responsible person approves publication. - **Interfaces:** a person can read the explanation, while an assistant can inspect explicit access, date and approval fields. The object does not write the final message by itself. It gives a writer or reviewer enough context to see why the draft must change. The example is authored for this explanation; it is not a client result. ## A structure to inspect, not a guarantee A structured claim can still be wrong. Sources can be weak, interpretation can drift and boundaries can become outdated. The useful property is that these questions have a place to live—and a place to be corrected. My [AG CommTech interview](https://agcommtech.de/2026/03/31/weniger-dokumente-mehr-knowledge-objects-wie-zeiss-ki-assistenten-systematisch-aufbaut/) provides public context for how I approach knowledge objects in communication work. The four-part model here is my explanatory framing, not a universal standard. What must travel with a piece of knowledge? **Boundary:** An explanatory model with an authored example; no claim of a universal standard or client outcome. #### Keep the meaning with the statement. - Part ID: `meaning` - Label: Meaning Make the intended interpretation and use explicit. A knowledge object is a piece of knowledge with enough context to be understood and used responsibly. This object describes that idea; the homepage uses the same structure to describe a person. **Purpose:** Make the intended interpretation and use explicit. **Source:** The definition authored on this page. **Boundary:** This is a practical framing, not a universal knowledge standard. **Example:** “Knowledge object” here means a statement kept with its support, limits and ways to use it. Related parts: evidence, interfaces #### Show what supports the idea. - Part ID: `evidence` - Label: Evidence Keep claims attached to sources that someone can inspect. A source can be a public interview, an observation or a recorded decision. What matters is the relationship: which statement does it support, and what does it leave open? A citation is a route to scrutiny, not a substitute for it. **Purpose:** Keep claims attached to sources that someone can inspect. **Source:** The linked AG CommTech interview provides public context; the four-part model and pilot example are authored here. **Boundary:** A source about an approach does not prove every proposed use or outcome. **Example:** The pilot note supports “invitation only”; it does not support “available to everyone next month”. Related parts: meaning, boundaries #### Keep limits and responsibility attached. - Part ID: `boundaries` - Label: Boundaries State where a claim applies, what is unknown and who may decide. Boundaries prevent a useful statement from becoming a promise it cannot support. They include scope, uncertainty, confidentiality and the difference between knowing something and having permission to act. **Purpose:** State where a claim applies, what is unknown and who may decide. **Source:** The scope and limits stated in this concept and its illustrative pilot example. **Boundary:** A knowledge object can describe authority; it cannot grant authority by itself. **Example:** An unconfirmed release date stays unknown. Publication still requires a responsible person. Related parts: evidence, interfaces #### Offer different views of the same context. - Part ID: `interfaces` - Label: Interfaces Let people and software use the same authored meaning. An article, an interactive object and structured fields can expose different views of the same context. The interface should suit its reader while preserving the sources and limits underneath. **Purpose:** Let people and software use the same authored meaning. **Source:** This article and its JSON and Markdown representations. **Boundary:** A machine-readable view is context for an agent, not unrestricted permission to operate. **Example:** A person reads the explanation; an agent inspects the same meaning, evidence and boundaries as explicit fields. Related parts: meaning, boundaries #### Relationships - `meaning` → `evidence`: is supported by - `evidence` → `boundaries`: sets the limits of - `boundaries` → `interfaces`: constrains - `interfaces` → `meaning`: carries into use #### Sources - [AG CommTech — Less documents, more knowledge objects – How ZEISS builds AI assistants systematically](https://agcommtech.de/2026/03/31/weniger-dokumente-mehr-knowledge-objects-wie-zeiss-ki-assistenten-systematisch-aufbaut/) (public-record) ### A working method - ID: `working-method` - Type: concept - Canonical page: https://www.svenspoede.com/concepts/working-method/ - Updated: 2026-09-19 Frame the decision, connect the relevant knowledge, challenge the draft and release with clear ownership. Feedback can change the frame at any stage. A method is useful when it helps people notice what needs to change. A rigid sequence can do the opposite: it carries an early misunderstanding through increasingly polished work. I think of the work as a loop: frame a decision, connect the relevant knowledge, challenge the result and release with clear ownership. These are places to exercise judgment. They are not four steps that make judgment unnecessary. ## One announcement, four different questions Consider the same illustrative pilot invitation used in the knowledge-object concept. Invited teams can try a campaign workspace; a general release date is unknown. An early draft announces that it will be “available to everyone next month.” Framing asks who needs to decide what. Connecting brings the pilot note and review rules into the draft’s context. Challenging exposes the unsupported audience and date. Release hands over a corrected message to the person who can approve publication. The value is not a longer checklist. It is the ability to locate the problem. Here, better phrasing would not repair the draft. Its framing conflicts with the actual scope. ## Why the arrows point back Challenge can send work back to the frame. Perhaps the intended audience was never agreed, or the brief asks for a claim that available evidence cannot support. Release also creates feedback. If readers mistake an invitation for general access, their response is evidence that the original framing needs work. A released message is a commitment with an owner, not an end to learning. ## What stays with people Tools can help gather context, compare a draft with its sources and surface contradictions. Someone still has to decide whether the sources are appropriate, whether the trade-off is acceptable and whether the result should enter use. This example is authored to explain the method. It is not a workflow running against a client system, and selecting a stage does not approve or publish anything. How does context become a decision someone can own? **Boundary:** The same illustrative pilot announcement, explored as a working method. #### Name the decision before choosing the tool. - Part ID: `frame` - Label: Frame Agree what should change for the audience and what a useful outcome would be. Agree what should change for the audience and what a useful outcome would be. A pilot invitation and a general launch announcement are different tasks. **Purpose:** Agree what should change for the audience and what a useful outcome would be. **Source:** Example brief: eligible teams need to decide whether to join a campaign-workspace pilot. **Boundary:** A pilot invitation and a general launch announcement are different tasks. **Example:** Invite the right teams to try the workspace. Do not promise a wider rollout. Related parts: connect, challenge, release #### Bring the necessary context into the work. - Part ID: `connect` - Label: Connect Connect the brief, supported facts and review rules so they remain available when the draft changes. Connect the brief, supported facts and review rules so they remain available when the draft changes. More material is not automatically more context. Include what the decision depends on. **Purpose:** Connect the brief, supported facts and review rules so they remain available when the draft changes. **Source:** The example brief, invitation-only pilot note and human review rule. **Boundary:** More material is not automatically more context. Include what the decision depends on. **Example:** Keep “invitation only” attached to the draft, alongside the unconfirmed general release date. Related parts: frame, challenge #### Test the draft against what is known. - Part ID: `challenge` - Label: Challenge Expose contradictions and missing support before fluency is mistaken for correctness. Expose contradictions and missing support before fluency is mistaken for correctness. Unsupported wording can be rejected. Missing facts must be checked, not guessed. **Purpose:** Expose contradictions and missing support before fluency is mistaken for correctness. **Source:** Example draft: “Launching for everyone next month.” Compare it with the example pilot note. **Boundary:** Unsupported wording can be rejected. Missing facts must be checked, not guessed. **Example:** “For everyone” exceeds the pilot scope. “Next month” adds an unconfirmed date. Return both claims to the brief. Related parts: connect, frame, release #### Put the result into use with an owner. - Part ID: `release` - Label: Release Make a bounded handover: what is approved, who decides and what would trigger a revision. Make a bounded handover: what is approved, who decides and what would trigger a revision. A tool can prepare the result. Publication remains a human decision, and later evidence can require a correction. **Purpose:** Make a bounded handover: what is approved, who decides and what would trigger a revision. **Source:** Example review decision: use invitation-only wording; the responsible person approves publication. **Boundary:** A tool can prepare the result. Publication remains a human decision, and later evidence can require a correction. **Example:** “Invited teams can now try the campaign workspace.” If readers mistake this for general access, revise the framing. Related parts: challenge, frame #### Relationships - `frame` → `connect`: defines what is needed - `connect` → `challenge`: makes assumptions testable - `challenge` → `release`: supports a bounded decision - `challenge` → `frame`: reframes when a claim fails - `release` → `frame`: returns feedback from use