Poesis
Actor types
Human and system participants
- Actor type Partial
IT service owner
Accept service commitments against dependencies and evidence.
Own service outcomes, agree operating boundaries, and coordinate affected owners during changes, incidents and recovery reviews.
Supported by Capabilities(1)
Supported by Features(5)
Experiences Pain points(14)
- Collection scope, incomplete runs and stale evidence are mistaken for current coverage.
- Governance drifts from what actually runs.
- Reviewers work from different selections and lose related decisions across meeting notes.
- Selected vocabulary and unbound templates are mistaken for complete, applicable obligations.
- Impact analysis is a guess made in a meeting.
- Service commitments have no agreed map of dependencies and accountable owners.
- The reason for a decision stays in an email thread instead of reaching the next reviewer.
- Temporary exceptions remain in force after their justification or controls expire.
- Security findings are ranked without reliable deployed-service context or mitigation evidence.
- Supplier assurances and exit promises are detached from the services that depend on them.
- Recovery targets assume dependency sequences and restoration results that exercises have not demonstrated.
- Data producers and consumers discover incompatible meanings or quality expectations only after a change.
- We know which software failed, but not which business processes are disrupted or whom to notify.
- Architecture, compliance, and quality tools don’t speak to each other.
Pursues Use cases(16)
- Set and review evidence-refresh expectations
- Prepare and conduct a multi-item governance session
- Define and reuse a scoped review lens
- Bind selected obligations to an organizational scope
- Assess application decommissioning prerequisites
- Accept a service responsibility baseline
- Transfer service ownership
- Review a time-bound risk exception
- Hand over operational decisions and evidence
- Prioritize vulnerabilities by service exposure
- Assess a supplier change against service commitments
- Review supplier exit readiness
- Review a service recovery exercise
- Resolve competing data-quality requirements
- Trace a software incident to affected business processes
- Maintain a governed IT definition inventory
- Actor type Planned
Application owner
Keep application responsibilities and service dependencies explicit.
Maintain application commitments and lifecycle decisions, identify consuming services, and transfer responsibility with accepted evidence.
Supported by Features(2)
Experiences Pain points(7)
- A blocking finding identifies a problem without a clear route to correction and renewed review.
- Impact analysis is a guess made in a meeting.
- Service commitments have no agreed map of dependencies and accountable owners.
- The reason for a decision stays in an email thread instead of reaching the next reviewer.
- A shared API changes before all affected consumers and migration conditions are known.
- Data producers and consumers discover incompatible meanings or quality expectations only after a change.
- We know which software failed, but not which business processes are disrupted or whom to notify.
Pursues Use cases(8)
- Resolve a blocked change request
- Assess application decommissioning prerequisites
- Accept a service responsibility baseline
- Transfer service ownership
- Review a breaking API contract change
- Coordinate an API deprecation
- Review a data contract change
- Trace a software incident to affected business processes
- Actor type Partial
IT risk owner
Own the consequences of a bounded risk decision.
Assess exposure, propose compensating controls, and provide evidence for exception renewal or closure without assuming approval authority.
Supported by Affordances(2)
Supported by Capabilities(2)
Supported by Features(2)
Experiences Pain points(7)
- Every framework lives in its own silo — and they collide on your desk.
- A blocking finding identifies a problem without a clear route to correction and renewed review.
- Evidence is discarded too early or retained indefinitely without a justified preservation policy.
- Temporary exceptions remain in force after their justification or controls expire.
- Security findings are ranked without reliable deployed-service context or mitigation evidence.
- Selected vocabulary and unbound templates are mistaken for complete, applicable obligations.
- Compliance is reconstructed in spreadsheets before every audit.
Pursues Use cases(10)
- Resolve competing obligations before adoption
- Turn uncovered obligations into corrective proposals
- Agree evidence-preservation requirements
- Review a time-bound risk exception
- Renew or close a risk exception
- Review vulnerability mitigation evidence
- Compose an IT governance fabric for an adopting scope
- Run a scoped IT compliance appraisal
- Review selected obligations together
- Evaluate identified inputs against supported Norms
- Actor type Partial
Exception approver
Decide whether a scoped, time-bound exception is acceptable.
Review justification, authority, expiry and compensating-control evidence before granting, renewing or revoking an exception.
Supported by Affordances(1)
Supported by Capabilities(1)
Supported by Features(3)
Experiences Pain points(7)
- Reviewers work from different selections and lose related decisions across meeting notes.
- Every framework lives in its own silo — and they collide on your desk.
- AI agents ship work nobody scoped, gated, or can replay.
- Temporary exceptions remain in force after their justification or controls expire.
- Incorrect bindings, unsupported narrative and partial files pass for completed deliverables.
- Anything can change anything — there is no approval trail.
- Dependent definitions remain trusted after a foundation is invalidated.
Pursues Use cases(7)
- Prepare and conduct a multi-item governance session
- Resolve competing obligations before adoption
- Approve an agent resource and action mandate
- Review a time-bound risk exception
- Renew or close a risk exception
- Gate an advancement on an authenticated human decision
- Make review and activation boundaries explicit
- Actor type Planned
API product owner
Evolve a shared interface with its consumers.
Review contract changes, identify affected consumers, and agree migration and deprecation conditions supported by compatibility evidence.
- Actor type Partial
Operational knowledge owner
Transfer decisions and unresolved obligations with the service.
Curate authoritative decisions, operating evidence and open questions so the receiving owner can explicitly accept a handover.
Supported by Affordances(1)
Supported by Capabilities(1)
Supported by Features(2)
Experiences Pain points(7)
- Compliance is reconstructed in spreadsheets before every audit.
- The reason for a decision stays in an email thread instead of reaching the next reviewer.
- Every deliverable is hand-crafted, again and again.
- Incorrect bindings, unsupported narrative and partial files pass for completed deliverables.
- Evidence is discarded too early or retained indefinitely without a justified preservation policy.
- Service commitments have no agreed map of dependencies and accountable owners.
- AI agents ship work nobody scoped, gated, or can replay.
Pursues Use cases(11)
- Retrieve the basis of a historical decision
- Author and maintain reusable output bindings
- Preview bindings before generating an artifact
- Set grounding constraints for generated narrative
- Operate recurring report production
- Investigate partial or failed generation
- Agree evidence-preservation requirements
- Transfer service ownership
- Hand over operational decisions and evidence
- Produce a named IT document family from pinned definitions
- Generate artifacts through declared workflows
- Actor type Planned
Vulnerability manager
Prioritize vulnerabilities in the context of affected services.
Reconcile findings with deployed components, assess exposure and business criticality, and route remediation to accountable owners.
- Actor type Planned
Product security engineer
Demonstrate whether a mitigation addresses the relevant exposure.
Investigate applicability, propose fixes or compensating controls, and inspect verification evidence before closing a finding.
- Actor type Planned
IT procurement manager
Compare supplier commitments against the services that depend on them.
Review contractual changes, renewal conditions and exit obligations with service and risk owners before committing a purchase.
- Actor type Planned
Third-party risk analyst
Connect supplier evidence to the scope of actual dependence.
Assess assurance scope, evidence age, subcontractor dependencies and concentration exposure while preserving unresolved questions.
- Actor type Planned
IT resilience manager
Assess whether recovery evidence supports service commitments.
Review disruption scenarios and exercise results with service and business owners, and record gaps between targets and demonstrated recovery.
- Actor type Planned
Disaster-recovery coordinator
Coordinate recovery in a dependency-aware order.
Prepare exercise sequences, identify shared-resource conflicts, and collect timed recovery and data-restoration evidence for review.
- Actor type Planned
Data owner
Accept data commitments with producers and consumers.
Decide acceptable uses and quality expectations, resolve conflicting consumer requirements, and approve contract changes within authority.
- Actor type Partial
Data steward
Make data-quality evidence and contract differences inspectable.
Maintain definitions and lineage evidence, assess quality findings, and prepare changes for accountable owner and consumer review.
Supported by Capabilities(1)
Supported by Features(2)
Experiences Pain points(3)
- Actor type Planned
Incident commander
Trace a software incident to affected business activities.
Coordinate response from observed disruption through deployed components and services to business processes and owners, distinguishing confirmed impact from possible exposure.
- Actor type Planned
Business-process owner
Make the business consequences of an IT disruption explicit.
Identify critical activities and service dependencies, confirm business disruption, agree workarounds, and set recovery priorities with incident and service owners.
Experiences Pain points(3)
- Service commitments have no agreed map of dependencies and accountable owners.
- Recovery targets assume dependency sequences and restoration results that exercises have not demonstrated.
- We know which software failed, but not which business processes are disrupted or whom to notify.
- Actor type Planned
CTO / CIO
Evaluate a shared definition model for a bounded IT decision.
A pilot can compare reconciliation work, decision quality and governance costs. Integrated inventory, appraisal and generation remain planned; whole-estate savings are not assumed.
Supported by Capabilities(1)
Supported by Features(2)
Experiences Pain points(3)
- Actor type Partial
Enterprise Architect
Trace definitions to accepted intent and inspected evidence.
Explore planned authoring, dependency analysis and artifact generation. Source revisions, deployed observations and simulation assumptions remain distinct evidence boundaries.
Supported by Affordances(4)
Supported by Capabilities(15)
- Governed IT definition inventory
- IT governance fabric composition
- Evidence-backed IT definition sourcing
- Scoped IT compliance evaluation
- IT dependency analysis and decision support
- IT artifact generation
- Authoritative definition store
- Governance lifecycle controls
- Collaborative contribution intake
- Systemic primitive vocabulary
- Open domain typing
- Governance grammar and lifecycle
- Selected framework and regulation sourcing
- Selected protocol and domain vocabulary
- Delivery evidence sourcing
Supported by Features(30)
- IT artifact factory
- IT compliance evaluation
- IT Copilot
- IT impact analysis and planned simulation
- GSM Definitions sourcing management
- GSM Definitions management
- GSM Ontology management
- Governance review sessions
- GSM Definitions candidate sourcing from code repos
- GSM Definitions lifecycle controls
- GSM Norms evaluation API
- KS Contributions retention
- Eight systemic primitives
- DNA grammar
- Archetyping
- Systemic Ascription lifecycle
- HTTP
- TOGAF
- IT
- ISO 25010
- ISO 25012
- PROV
- GDPR
- NIS2
- SCAP
- DORA
- SAFe
- ITIL
- Catalogue update stream
- Harness history sourcing
Experiences Pain points(18)
- Collection scope, incomplete runs and stale evidence are mistaken for current coverage.
- Reviewers work from different selections and lose related decisions across meeting notes.
- A blocking finding identifies a problem without a clear route to correction and renewed review.
- Architecture, compliance, and quality tools don’t speak to each other.
- Every framework lives in its own silo — and they collide on your desk.
- Selected vocabulary and unbound templates are mistaken for complete, applicable obligations.
- Every deliverable is hand-crafted, again and again.
- Incorrect bindings, unsupported narrative and partial files pass for completed deliverables.
- Dependent definitions remain trusted after a foundation is invalidated.
- A rule revision changes established verdicts without an inspected explanation.
- Impact analysis is a guess made in a meeting.
- A shared API changes before all affected consumers and migration conditions are known.
- Anything can change anything — there is no approval trail.
- The architecture repository is out of date the day it’s written.
- Governance drifts from what actually runs.
- Compliance is reconstructed in spreadsheets before every audit.
- AI agents act on stale wikis and tribal knowledge.
- The reason for a decision stays in an email thread instead of reaching the next reviewer.
Pursues Use cases(47)
- Configure repository collection boundaries
- Prepare and conduct a multi-item governance session
- Resolve a blocked change request
- Define and reuse a scoped review lens
- Inspect one subject across framework perspectives
- Compose and reuse a governance selection
- Identify gaps in selected vocabulary coverage
- Author and maintain reusable output bindings
- Preview bindings before generating an artifact
- Turn uncovered obligations into corrective proposals
- Assess dependent definitions after foundation invalidation
- Qualify a rule revision against reference cases
- Agree a reusable domain typing contract
- Assess application decommissioning prerequisites
- Review a breaking API contract change
- Read and model a governance decision
- Describe a service contract and its attribution
- Review sourced obligations before binding them
- Review a governance package upgrade
- Author and approve a shared definition
- Reconcile code evidence into reviewed definitions
- Review a scoped IT appraisal
- Inspect a change before committing to it
- Ask an IT question and inspect its sources
- Generate and review an architecture decision pack
- Reuse captured delivery evidence as definition proposals
- Extract definition candidates from a code revision
- Inspect retained contribution evidence
- Extract definition candidates from delivery history
- Maintain a governed IT definition inventory
- Compose an IT governance fabric for an adopting scope
- Source IT definitions from inspected evidence
- Answer an IT question from the governed model
- Produce a named IT document family from pinned definitions
- Hold definitions as the authoritative, revision-bound source
- Enforce definition lifecycle boundaries
- Collect competing contributions on a shared blackboard
- Type a governance concern with the systemic primitives
- Define a domain vocabulary as an Archetype
- Express an obligation in the governance grammar
- Adopt a sourced framework or regulation
- Describe an interaction with sourced protocol vocabulary
- Turn delivery history into definition candidates
- Work from shared, typed definitions
- Review selected obligations together
- Make review and activation boundaries explicit
- Review candidates from selected sources
- Actor type Partial
CISO / Security leadership
Make a stated appraisal scope and its missing evidence visible.
Selected GDPR/NIS2 templates and quality vocabularies exist; binding, observations and appraisal are planned integrations. Measure coverage and reconstruction effort, not automatic legal compliance.
Supported by Affordances(4)
Supported by Capabilities(6)
Supported by Features(17)
Experiences Pain points(15)
- Access assignments drift from responsibilities and identity-provider changes.
- Compliance is reconstructed in spreadsheets before every audit.
- The reason for a decision stays in an email thread instead of reaching the next reviewer.
- Reviewers work from different selections and lose related decisions across meeting notes.
- Architecture, compliance, and quality tools don’t speak to each other.
- Every framework lives in its own silo — and they collide on your desk.
- A blocking finding identifies a problem without a clear route to correction and renewed review.
- Selected vocabulary and unbound templates are mistaken for complete, applicable obligations.
- Evidence is discarded too early or retained indefinitely without a justified preservation policy.
- A rule revision changes established verdicts without an inspected explanation.
- Anything can change anything — there is no approval trail.
- The architecture repository is out of date the day it’s written.
- Governance drifts from what actually runs.
- Dependent definitions remain trusted after a foundation is invalidated.
- AI agents act on stale wikis and tribal knowledge.
Pursues Use cases(25)
- Review operation-specific privileges
- Restore identity-provider synchronization
- Retrieve the basis of a historical decision
- Inspect one subject across framework perspectives
- Compose and reuse a governance selection
- Resolve competing obligations before adoption
- Turn uncovered obligations into corrective proposals
- Bind selected obligations to an organizational scope
- Agree evidence-preservation requirements
- Qualify a rule revision against reference cases
- Review sourced obligations before binding them
- Review a governance package upgrade
- Author and approve a shared definition
- Review a scoped IT appraisal
- Review recurring patient-portal appraisal
- Maintain a governed IT definition inventory
- Compose an IT governance fabric for an adopting scope
- Run a scoped IT compliance appraisal
- Enforce definition lifecycle boundaries
- Serve authorized definition context to a model
- Adopt a sourced framework or regulation
- Work from shared, typed definitions
- Review selected obligations together
- Make review and activation boundaries explicit
- Evaluate identified inputs against supported Norms
- Actor type Partial
Platform / Ops / SRE lead
Inspect the boundary between definitions and operations.
API and execution source can support a bounded integration experiment. Observation identity, effect authority, failure receipts and recovery must be accepted for the selected environment.
Supported by Affordances(2)
Supported by Capabilities(14)
- Evidence-backed IT definition sourcing
- Scoped IT compliance evaluation
- IT artifact generation
- Authoritative definition store
- Governance lifecycle controls
- Collaborative contribution intake
- Scoped Norm verdict evaluation
- Bounded Mechanism execution
- Selected protocol and domain vocabulary
- Profile-scoped definition interchange
- Deterministic workflow controls
- Scoped artifact contract checks
- Agentic SAFe operating model
- Local-first delivery plane
Supported by Features(33)
- IT artifact factory
- IT impact analysis and planned simulation
- GSM Definitions sourcing management
- Authentication and planned RBAC/ABAC
- Identity-provider synchronization
- GSM Definitions management RESTful API
- GSM Definitions lifecycle controls
- GSM Definitions lifecycle events mediation
- GSM Mechanism execution foundations
- GSM Mechanism technology integrations
- Blackboard seal lifecycle controls
- gRPC
- GraphQL
- Kafka
- AMQP
- JDBC
- WebSocket
- DORA
- SAFe
- ITIL
- Catalogue update stream
- Workflow & step resolution
- Skill and instruction prompt injection
- LLM resolution
- Artifact validation
- Agent write authorization
- Logging
- Skills
- Instructions
- Artifacts
- Workspace data plane
- Installer
- CI/CD artifacts pipelines
Experiences Pain points(20)
- Collection scope, incomplete runs and stale evidence are mistaken for current coverage.
- Governance drifts from what actually runs.
- Access assignments drift from responsibilities and identity-provider changes.
- Every deliverable is hand-crafted, again and again.
- Incorrect bindings, unsupported narrative and partial files pass for completed deliverables.
- Dependent definitions remain trusted after a foundation is invalidated.
- Your governance model is trapped in a vendor’s proprietary format.
- Architecture, compliance, and quality tools don’t speak to each other.
- AI agents ship work nobody scoped, gated, or can replay.
- Host or model selection changes behavior without verifying workload quality, instruction delivery or disclosure limits.
- Individually valid parallel agent outputs overwrite or contradict accepted work.
- The reason for a decision stays in an email thread instead of reaching the next reviewer.
- Recovery targets assume dependency sequences and restoration results that exercises have not demonstrated.
- We know which software failed, but not which business processes are disrupted or whom to notify.
- Every framework lives in its own silo — and they collide on your desk.
- Anything can change anything — there is no approval trail.
- The architecture repository is out of date the day it’s written.
- Compliance is reconstructed in spreadsheets before every audit.
- Impact analysis is a guess made in a meeting.
- A rule revision changes established verdicts without an inspected explanation.
Pursues Use cases(51)
- Configure repository collection boundaries
- Diagnose and recover incomplete collection
- Set and review evidence-refresh expectations
- Review operation-specific privileges
- Restore identity-provider synchronization
- Operate recurring report production
- Investigate partial or failed generation
- Assess dependent definitions after foundation invalidation
- Qualify transfer between independent processors
- Approve an agent resource and action mandate
- Qualify model routing for a workload
- Qualify instruction delivery on another host
- Reconcile conflicting parallel agent outputs
- Hand over operational decisions and evidence
- Resolve recovery dependency conflicts
- Trace a software incident to affected business processes
- Describe payment request and notification boundaries
- Describe payment settlement and recovery boundaries
- Review a governance package upgrade
- Reconcile code evidence into reviewed definitions
- React to a committed definition change
- Review recurring patient-portal appraisal
- Inspect a change before committing to it
- Execute a bounded response and inspect the receipt
- Deliver a reviewed artifact through a local workflow
- Set up a workspace and publish checked artifacts
- Read and revise definitions through the API
- Qualify an execution adapter for an integration
- Close a contribution collection for review
- Resolve the next eligible workflow step
- Validate a mediated artifact write
- Inspect a captured harness invocation sequence
- Select a practice playbook for a delivery task
- Select versioned instructions for an engineering role
- Define a deliverable schema and template
- Install a pinned agentic workspace
- Publish artifacts through configured CI checks
- Source IT definitions from inspected evidence
- Produce a named IT document family from pinned definitions
- Hold definitions as the authoritative, revision-bound source
- Enforce definition lifecycle boundaries
- Collect competing contributions on a shared blackboard
- Obtain a reproducible verdict for supplied inputs
- Run a Mechanism inside declared bounds
- Describe an interaction with sourced protocol vocabulary
- Run an agentic workflow with deterministic controls
- Check a produced artifact against its contract
- Adopt the agentic SAFe operating model
- Deliver from a local-first, reproducible plane
- Review candidates from selected sources
- Generate artifacts through declared workflows
- Actor type Partial
Head of AI
Evaluate AI answers against authorized, attributable context.
Planned read-only context and copilot routes need citation, abstention and injection tests. Direct authoring is valid without sourcing; typed context alone does not make action safe.
Supported by Affordances(2)
Supported by Capabilities(5)
Supported by Features(8)
Experiences Pain points(9)
- Incorrect bindings, unsupported narrative and partial files pass for completed deliverables.
- AI agents ship work nobody scoped, gated, or can replay.
- Host or model selection changes behavior without verifying workload quality, instruction delivery or disclosure limits.
- AI agents act on stale wikis and tribal knowledge.
- Impact analysis is a guess made in a meeting.
- Anything can change anything — there is no approval trail.
- Reviewers work from different selections and lose related decisions across meeting notes.
- Architecture, compliance, and quality tools don’t speak to each other.
- Every deliverable is hand-crafted, again and again.
Pursues Use cases(16)
- Set grounding constraints for generated narrative
- Approve an agent resource and action mandate
- Qualify model routing for a workload
- Qualify instruction delivery on another host
- Consume authorized definition context
- Ask an IT question and inspect its sources
- Deliver a reviewed artifact through a local workflow
- Assign a delivery responsibility from the role catalog
- Define a delivery ceremony and its handoffs
- Answer an IT question from the governed model
- Serve authorized definition context to a model
- Run an agentic workflow with deterministic controls
- Adopt the agentic SAFe operating model
- Gate an advancement on an authenticated human decision
- Work from shared, typed definitions
- Generate artifacts through declared workflows
- Actor type Partial
Specification reader / modeler
Compare a system description with a declared modeling contract.
Read source specifications and sourced vocabularies, inspect examples and record interpretation limits before choosing an implementation.
Supported by Capabilities(7)
Supported by Features(27)
- GSM Ontology management
- Eight systemic primitives
- DNA grammar
- Archetyping
- Systemic Ascription lifecycle
- Enhanced Directives and Norms model
- HTTP
- TOGAF
- IT
- ISO 25010
- ISO 25012
- PROV
- gRPC
- GraphQL
- Kafka
- AMQP
- JDBC
- WebSocket
- GDPR
- NIS2
- SCAP
- Causal model research
- Governance chain research
- DNA production research
- Research cases
- Decision register
- Research protocol & promotion path
Experiences Pain points(5)
- Selected vocabulary and unbound templates are mistaken for complete, applicable obligations.
- Architecture, compliance, and quality tools don’t speak to each other.
- Your governance model is trapped in a vendor’s proprietary format.
- Every framework lives in its own silo — and they collide on your desk.
- A modeling decision cites an example as though it were an executed test.
Pursues Use cases(17)
- Identify gaps in selected vocabulary coverage
- Agree a reusable domain typing contract
- Qualify transfer between independent processors
- Read and model a governance decision
- Describe a service contract and its attribution
- Describe payment request and notification boundaries
- Describe payment settlement and recovery boundaries
- Review sourced obligations before binding them
- Review a model research question
- Test and propose a grammar extension
- Incorporate an accepted grammar extension
- Type a governance concern with the systemic primitives
- Define a domain vocabulary as an Archetype
- Express an obligation in the governance grammar
- Adopt a sourced framework or regulation
- Describe an interaction with sourced protocol vocabulary
- Take a modeling limit through research to a decision
- Actor type Partial
Research reviewer
Distinguish a research hypothesis from an accepted requirement.
Compare explanations, inspect case evidence and follow decision records before proposing a specification change.
Supported by Affordances(1)
Supported by Capabilities(1)
Supported by Features(7)
Experiences Pain points(4)
- Actor type Partial
Authorized integration client
Exchange identified definitions within an explicit access boundary.
A consuming service or tool requests pinned context, publishes reviewed drafts or consumes committed changes under its own authenticated identity.
Supported by Affordances(2)
Supported by Capabilities(8)
Supported by Features(10)
- GSM Definitions candidate sourcing from code repos
- GSM Definitions management RESTful API
- GSM Definitions lifecycle events mediation
- MCP
- GSM Mechanism execution foundations
- GSM Mechanism technology integrations
- KS Contributions management RESTful API
- Blackboard seal lifecycle controls
- KS Contributions retention
- Harness history sourcing
Experiences Pain points(12)
- Your governance model is trapped in a vendor’s proprietary format.
- Architecture, compliance, and quality tools don’t speak to each other.
- The architecture repository is out of date the day it’s written.
- Governance drifts from what actually runs.
- AI agents act on stale wikis and tribal knowledge.
- Anything can change anything — there is no approval trail.
- Every deliverable is hand-crafted, again and again.
- The reason for a decision stays in an email thread instead of reaching the next reviewer.
- Collection scope, incomplete runs and stale evidence are mistaken for current coverage.
- Compliance is reconstructed in spreadsheets before every audit.
- A rule revision changes established verdicts without an inspected explanation.
- Reviewers work from different selections and lose related decisions across meeting notes.
Pursues Use cases(22)
- Qualify transfer between independent processors
- Reconcile code evidence into reviewed definitions
- Consume authorized definition context
- React to a committed definition change
- Execute a bounded response and inspect the receipt
- Reuse captured delivery evidence as definition proposals
- Extract definition candidates from a code revision
- Read and revise definitions through the API
- Qualify an execution adapter for an integration
- Submit a contribution to a declared panel
- Close a contribution collection for review
- Inspect retained contribution evidence
- Extract definition candidates from delivery history
- Source IT definitions from inspected evidence
- Hold definitions as the authoritative, revision-bound source
- Collect competing contributions on a shared blackboard
- Obtain a reproducible verdict for supplied inputs
- Run a Mechanism inside declared bounds
- Serve authorized definition context to a model
- Turn delivery history into definition candidates
- Work from shared, typed definitions
- Review candidates from selected sources
- Actor type Partial
Assessment runner
Evaluate identified inputs and retain unknown results.
A scheduler or appraisal client supplies pinned rules and instances, requests pure verdicts and routes findings to an accountable reviewer.
Supported by Affordances(1)
Supported by Capabilities(3)
Supported by Features(3)
Experiences Pain points(5)
- A rule revision changes established verdicts without an inspected explanation.
- Compliance is reconstructed in spreadsheets before every audit.
- Governance drifts from what actually runs.
- Anything can change anything — there is no approval trail.
- A blocking finding identifies a problem without a clear route to correction and renewed review.
Pursues Use cases(8)
- Qualify a rule revision against reference cases
- Review a scoped IT appraisal
- Review recurring patient-portal appraisal
- Execute a bounded response and inspect the receipt
- Run a scoped IT compliance appraisal
- Obtain a reproducible verdict for supplied inputs
- Run a Mechanism inside declared bounds
- Evaluate identified inputs against supported Norms
- Actor type Partial
Delivery agent
Produce artifacts under declared grants and review boundaries.
A host-bound software agent receives a scoped task, resolves instructions and submits artifacts for checks and human review without assuming authority to deploy.
Supported by Affordances(1)
Supported by Capabilities(5)
Supported by Features(10)
Experiences Pain points(5)
- Individually valid parallel agent outputs overwrite or contradict accepted work.
- AI agents ship work nobody scoped, gated, or can replay.
- Incorrect bindings, unsupported narrative and partial files pass for completed deliverables.
- Host or model selection changes behavior without verifying workload quality, instruction delivery or disclosure limits.
- Every deliverable is hand-crafted, again and again.
Pursues Use cases(18)
- Reconcile conflicting parallel agent outputs
- Deliver a reviewed artifact through a local workflow
- Set up a workspace and publish checked artifacts
- Resolve the next eligible workflow step
- Validate a mediated artifact write
- Inspect a captured harness invocation sequence
- Assign a delivery responsibility from the role catalog
- Select a practice playbook for a delivery task
- Define a delivery ceremony and its handoffs
- Select versioned instructions for an engineering role
- Define a deliverable schema and template
- Publish artifacts through configured CI checks
- Run an agentic workflow with deterministic controls
- Check a produced artifact against its contract
- Adopt the agentic SAFe operating model
- Gate an advancement on an authenticated human decision
- Deliver from a local-first, reproducible plane
- Generate artifacts through declared workflows