Poesis
The Systemic Intelligence Engine — the governed AI context.
The Systemic Intelligence Engine: a GSM reference implementation for governed definitions and bounded execution.
Retained definitions, transition controls, execution source and contribution intake exist. A regulator additionally needs identified observations, accepted evaluation, authorized action and feedback.
Declarative infrastructure is an analogy, not evidence of universal reconciliation. Local API use does not require hosting.
Insights · context engineering’s missing layer — governed context, not retrieval →
Values
Attributable context, bounded operations and feedback loops.
- Value Partial
Make shared context attributable.
Build toward policy-filtered snapshots that people and AI can inspect. Direct API authoring is independent of sourcing, with MCP planned as an additional interface.
Supported by Affordances(1)
Supported by Capabilities(2)
Supported by Features(1)
- Value Partial
Constrain operations at declared boundaries.
Combine eligibility, caller authority and adapter contracts to bound effectful execution. Keep pure verdict evaluation separate from actions that change a system.
Supported by Capabilities(1)
Supported by Features(3)
- Value Partial
Build toward bounded feedback loops.
Connect definitions, observations, evaluation, authorized response and re-observation in future domain-specific loops, with explicit boundaries for each integration.
Supported by Capabilities(1)
Supported by Features(2)
- Value Partial
Use evidence to inform revisions.
Carry reviewed candidates into authorized revisions with promotion lineage. Collection, approval and confirmation against running systems remain distinct steps.
Supported by Affordances(1)
Supported by Capabilities(1)
Realized through Use cases(2)
Capabilities
Definition and execution foundations alongside planned evaluation and access routes.
- Capability Partial
Governance lifecycle controls
Control the progression from closed evidence collection to reviewed and activated definition revisions, keeping board sealing separate from approval. Existing transition controls need acceptance for identity-bound decisions, graded validation and concurrent intake integrity; committed-change notifications are a planned extension.
Addresses Pain points(2)
Supports Values(3)
Serves Use cases(1)
Used by Actor types(3)
- Capability Implemented
Collaborative contribution intake
Give collaborating sources a shared intake and retained evidence history so clients can compare contributions and revisit the basis for candidate selection. Panels and storage exist; end-to-end validation, complete auditing, client reconciliation and authorized draft promotion remain integration boundaries.
Addresses Pain points(2)
Supports Values(3)
Serves Use cases(1)
Used by Actor types(3)
Realized by Features(2)
- Capability Partial
Scoped Norm verdict evaluation
Combine access to versioned governed definitions with pure applicability and assertion evaluation over pinned rules and supplied instances. Planned verdicts preserve non-evaluable states and support comparison of proposed rules without dispatching effects; coherent input selection needs acceptance, and running-system claims additionally require observations.
Addresses Pain points(2)
Supports Values(3)
Serves Use cases(1)
Used by Actor types(3)
Realized by Features(2)
- Capability Partial
Bounded Mechanism execution
Translate eligible Mechanism definitions into effects through selected technology adapters under explicit execution and transport contracts. Existing execution and adapters need acceptance for atomic frames, caller authority, budgets, cancellation and partial or unknown outcome receipts; wider adapters are optional.
Addresses Pain points(1)
Supports Values(3)
Serves Use cases(1)
Used by Actor types(3)
Realized by Features(2)
- Capability Partial
Governed context for AI
Supply AI clients with a shared, versioned definition context through direct APIs and planned MCP access, combining policy-filtered selection with bounded operations. API foundations exist; authorized selection and evaluated tool/answer boundaries still need acceptance. Direct authoring does not require sourcing.
Addresses Pain points(2)
Supports Values(3)
Serves Use cases(1)
Used by Actor types(3)
Realized by Features(2)
Products
Three products, one engine.
- Product · recorded v1.0 Partial Definition Manager
Keep system definitions versioned, accessible and governed through change.
Product features- Feature · milestone v1.0 Implemented GSM Definitions management RESTful API
- Feature · milestone v1.0 Implemented GSM Definitions lifecycle controls
- Feature · milestone v1.0 Implemented GSM Definitions retention
- Feature · milestone v1.1 Planned GSM Definitions lifecycle events mediation
- Feature · milestone v1.2 Planned MCP
- Product · recorded v0.1 Partial Operator
Connect governed definitions to execution and planned Norm evaluation.
Product features- Feature · milestone v1.0 Planned GSM Norms evaluation API
- Feature · milestone v1.1 Partial GSM Mechanism execution foundations
- Feature · milestone v1.x Partial GSM Mechanism technology integrations
- Product · recorded v1.0 Implemented Definition Blackboard Manager
Bring evidence and competing proposals into a shared review space.
Product features- Feature · milestone v1.0 Implemented KS Contributions management RESTful API
- Feature · milestone v1.0 Implemented Blackboard seal lifecycle controls
- Feature · milestone v1.0 Implemented KS Contributions retention
Qualities
What the engine decides, and what it refuses to guess.
- Pure verdicts Partial The same inputs give the same verdict
Norm evaluation is scoped and side-effect free. Rule and input versions are part of the verdict; continuous operation additionally needs observations and scheduling.
- Bounded execution Partial Mechanisms run inside a declared sandbox
Mechanism execution is confined to a declared protocol surface. Effect safety and authorized action remain acceptance boundaries.
- Explicit unknowns Planned Missing evidence is a result, not a pass
Applicability, freshness and unknown states are first-class outcomes. An unevaluated obligation is never reported as satisfied.
Usage
Definition, appraisal and execution use cases
- Use case Implemented
Retrieve the basis of a historical decision
Retrieve the decided revision, recorded identity, supporting evidence and conditions relevant to a historical decision, retaining attribution gaps.
Supported by Features(1)
Addresses Pain points(2)
Realizes Values(5)
Performed by Actor types(2)
- Use case Implemented
Assess dependent definitions after foundation invalidation
Inspect dependent definition eligibility after a referenced foundation is invalidated and determine which continued uses require renewed review.
Supported by Features(1)
Addresses Pain points(1)
Realizes Values(1)
Performed by Actor types(2)
- Use case Implemented
Agree evidence-preservation requirements
Agree retention purpose, duration, access and disposal constraints for decision evidence, distinguishing agreed policy from demonstrated enforcement.
Supported by Features(1)
Addresses Pain points(1)
Realizes Values(4)
Performed by Actor types(3)
- Use case Planned
Qualify a rule revision against reference cases
Compare old and proposed rule verdicts on pinned reference inputs, investigate changed or unknown results and record acceptance before adoption.
Supported by Features(1)
Addresses Pain points(1)
Realizes Values(2)
Performed by Actor types(3)
- Use case Partial
Reconcile code evidence into reviewed definitions
Turn competing source-revision candidates into attributable definition drafts for review.
Supported by Affordances(1)
Addresses Pain points(2)
Realizes Values(9)
- Keep governance closer to its evidence.
- Give AI attributable context.
- Reduce manual candidate authoring.
- Relate definitions to inspected revisions.
- Inspect the basis of proposals.
- Use evidence to inform revisions.
- Compare contributed partial views.
- Separate exploration from acceptance.
- Trace retained proposal evidence.
Performed by Actor types(3)
- Use case Planned
React to a committed definition change
Refresh a downstream view from committed changes without repeated full polling.
Supported by Features(1)
Addresses Pain points(1)
Performed by Actor types(2)
- Use case Partial
Execute a bounded response and inspect the receipt
Perform a named authorized operation and retain enough evidence to decide whether recovery is needed.
Supported by Features(1)
Addresses Pain points(1)
Realizes Values(6)
Performed by Actor types(3)
- Use case Partial
Deliver a reviewed artifact through a local workflow
Produce a scoped artifact through an attributable local method, checks and human review.
Supported by Affordances(1)
Addresses Pain points(2)
Realizes Values(8)
Performed by Actor types(3)
- Use case Implemented
Read and revise definitions through the API
Create, query and revise typed definitions through the REST contract, inspecting validation, revision and access responses without treating a successful draft write as approval.
Supported by Features(1)
Addresses Pain points(2)
Realizes Values(1)
Performed by Actor types(2)
- Use case Partial
Qualify an execution adapter for an integration
Check a selected adapter's transport, authority and failure contract against a named integration, distinguishing supported operations from planned adapter coverage.
Supported by Features(1)
Addresses Pain points(2)
Realizes Values(1)
Performed by Actor types(2)
- Use case Implemented
Submit a contribution to a declared panel
Post a candidate to a declared panel and inspect schema, identity, confidence-envelope and rejection responses under the client/server contract. Acceptance into collection is not definition approval.
Supported by Features(1)
Addresses Pain points(1)
Realizes Values(1)
Performed by Actor types(1)
- Use case Implemented
Close a contribution collection for review
Request sealing or abandonment of a contribution collection and inspect concurrent-intake outcomes and snapshot readiness. Closing collection does not approve or activate a definition.
Supported by Features(1)
Addresses Pain points(1)
Realizes Values(1)
Performed by Actor types(2)
- Use case Implemented
Inspect retained contribution evidence
Retrieve stored candidates and their captured evidence to inspect provenance and conflicting assertions, making missing audit, integrity or promoted-draft links explicit.
Supported by Features(1)
Addresses Pain points(1)
Realizes Values(1)
Performed by Actor types(2)
- Use case Partial
Enforce definition lifecycle boundaries
Distinguish collection closure from definition approval, validate revision-bound lifecycle changes and inspect dependent eligibility after foundation invalidation. Where the notification route is available, inform authorized consumers without conflating event delivery with approval.
Supported by Capabilities(1)
Addresses Pain points(2)
Realizes Values(3)
Performed by Actor types(3)
- Use case Implemented
Collect competing contributions on a shared blackboard
Collect independent candidates under declared panel contracts and revisit their retained provenance to compare conflicting assertions. Contribution acceptance and evidence retention do not themselves seal a board or promote an approved definition.
Supported by Capabilities(1)
Addresses Pain points(2)
Realizes Values(3)
Performed by Actor types(3)
- Use case Partial
Obtain a reproducible verdict for supplied inputs
Select coherent definition revisions through the API, supply pinned inputs and Norms to evaluation, and compare verdicts across rule revisions with explicit applicability and unknown states. Repeatability applies to identical evaluation inputs, not changing live systems.
Supported by Capabilities(1)
Addresses Pain points(2)
Realizes Values(3)
Performed by Actor types(3)
- Use case Partial
Run a Mechanism inside declared bounds
Resolve an eligible operation and its supported adapter, apply declared authority and execution limits, then interpret the receipt against that adapter's failure contract before deciding on recovery. Wider adapters and complete execution controls require their own acceptance.
Supported by Capabilities(1)
Addresses Pain points(1)
Realizes Values(3)
Performed by Actor types(3)
- Use case Partial
Make review and activation boundaries explicit
Carry a proposed governance change through explicit grammar, revision-bound review and authorized lifecycle transitions, including human decision boundaries. A research-driven model revision follows its own acceptance process; collection sealing is not activation.
Supported by Affordances(1)
Addresses Pain points(2)
Realizes Values(3)
Performed by Actor types(4)
- Use case Partial
Review candidates from selected sources
Compare code-derived and delivery-derived candidates against their pinned source evidence, retain competing contributions and acquisition gaps, and select what may proceed to draft review. Confidence does not settle truth or establish deployed reality.
Supported by Affordances(1)
Addresses Pain points(3)
Realizes Values(3)
Performed by Actor types(3)
- Use case Partial
Evaluate identified inputs against supported Norms
Combine reproducible Norm verdicts with scoped IT measures and findings to identify accountable corrective work and judge a subsequent appraisal. Preserve rule/input identity, applicability and unknown states; operational conclusions require observation evidence.
Supported by Affordances(1)
Addresses Pain points(2)
Realizes Values(3)
Performed by Actor types(3)
- Use case Partial
Generate artifacts through declared workflows
Produce a grounded document or software artifact through assigned roles, bounded workflow execution and explicit deliverable contracts, then obtain the required revision-bound review before advancement. Technical checks, substantive acceptance and authorized deployment remain separate decisions.
Supported by Affordances(1)
Addresses Pain points(3)
Realizes Values(3)
Performed by Actor types(4)