pub struct AgenticSystem { /* private fields */ }Expand description
One revision of one agentic system design.
Implementations§
Source§impl AgenticSystem
impl AgenticSystem
Sourcepub fn draft(
id: AgenticSystemId,
purpose: SystemPurpose,
integrator: SystemRoleId,
roles: impl IntoIterator<Item = SystemRole>,
participants: impl IntoIterator<Item = LogicalParticipant>,
topology: impl IntoIterator<Item = CollaborationLink>,
profiles: impl IntoIterator<Item = (SystemRoleId, RequestedExecutionProfile)>,
ceremonies: impl IntoIterator<Item = CeremonyComposition>,
supervision: SupervisionPolicy,
attention: AttentionPolicy,
now: OffsetDateTime,
) -> Result<Self, DomainError>
pub fn draft( id: AgenticSystemId, purpose: SystemPurpose, integrator: SystemRoleId, roles: impl IntoIterator<Item = SystemRole>, participants: impl IntoIterator<Item = LogicalParticipant>, topology: impl IntoIterator<Item = CollaborationLink>, profiles: impl IntoIterator<Item = (SystemRoleId, RequestedExecutionProfile)>, ceremonies: impl IntoIterator<Item = CeremonyComposition>, supervision: SupervisionPolicy, attention: AttentionPolicy, now: OffsetDateTime, ) -> Result<Self, DomainError>
Start a design at its first revision.
Deliberately permissive about the content: a draft is something an author is still working on, and refusing to write down a half-finished system would mean the only way to get advice about one is to have finished it. What is refused here is what no revision of the design could ever repair — an empty system, or one whose own indexes disagree with themselves.
pub const fn id(&self) -> &AgenticSystemId
pub const fn revision(&self) -> AgenticSystemRevision
pub const fn lifecycle(&self) -> AgenticSystemLifecycle
pub const fn purpose(&self) -> &SystemPurpose
Sourcepub const fn integrator(&self) -> &SystemRoleId
pub const fn integrator(&self) -> &SystemRoleId
The business role that drives the system from outside it.
pub const fn roles(&self) -> &BTreeMap<SystemRoleId, SystemRole>
pub const fn participants(&self) -> &BTreeMap<ParticipantId, LogicalParticipant>
pub fn topology(&self) -> &[CollaborationLink]
pub const fn profiles( &self, ) -> &BTreeMap<SystemRoleId, RequestedExecutionProfile>
pub const fn ceremonies( &self, ) -> &BTreeMap<SystemCeremonyId, CeremonyComposition>
pub const fn supervision(&self) -> &SupervisionPolicy
Sourcepub const fn attention(&self) -> &AttentionPolicy
pub const fn attention(&self) -> &AttentionPolicy
What the integrator asked to be told about while it runs.
pub const fn created_at(&self) -> OffsetDateTime
pub const fn updated_at(&self) -> OffsetDateTime
Sourcepub fn digest(&self) -> Result<AgenticSystemDigest, DomainError>
pub fn digest(&self) -> Result<AgenticSystemDigest, DomainError>
The content identity of this design.
Sourcepub fn pin(&self) -> Result<SystemPin, DomainError>
pub fn pin(&self) -> Result<SystemPin, DomainError>
This design, named the way a run refers to it.
Sourcepub fn edited(&self, now: OffsetDateTime) -> Self
pub fn edited(&self, now: OffsetDateTime) -> Self
The same design saved as the next revision.
Editing produces a new revision rather than mutating this one, because the store’s compare-and-swap is what protects one author’s edit from another’s, and it can only compare revisions it was told about.
Sourcepub fn at_revision(&self, revision: AgenticSystemRevision) -> Self
pub fn at_revision(&self, revision: AgenticSystemRevision) -> Self
The same design, recorded at a revision the store assigned.
Sourcepub fn published(&self, now: OffsetDateTime) -> Result<Self, DomainError>
pub fn published(&self, now: OffsetDateTime) -> Result<Self, DomainError>
Seal this revision.
Refused from anything but a draft: publishing a published revision again would either be a no-op dressed as an event or a silent overwrite of something a run may already be pinned to.
Sourcepub fn deprecated(&self, now: OffsetDateTime) -> Result<Self, DomainError>
pub fn deprecated(&self, now: OffsetDateTime) -> Result<Self, DomainError>
Retire this revision from new runs without invalidating the ones already sealed against it.
Sourcepub fn blocking_dependencies(
&self,
) -> BTreeMap<SystemCeremonyId, Vec<SystemCeremonyId>>
pub fn blocking_dependencies( &self, ) -> BTreeMap<SystemCeremonyId, Vec<SystemCeremonyId>>
What each composition must wait for before it can run.
Not simply depends_on: a bounded loop declares which edge is
the way back round, and that edge is cut here so a system that
sends work back for revision can start at all.
Sourcepub fn root_ceremonies(&self) -> Vec<&CeremonyComposition>
pub fn root_ceremonies(&self) -> Vec<&CeremonyComposition>
The compositions nothing else has to finish first.
These are where a run begins. A design where every composition waits for another has a cycle nothing bounded, and the analysis says so before a run has to discover it by starting nothing.
Source§impl AgenticSystem
impl AgenticSystem
Sourcepub fn analyze(
&self,
resolved: &BTreeMap<SystemCeremonyId, PublishedCeremonyDefinition>,
) -> AgenticSystemValidationReport
pub fn analyze( &self, resolved: &BTreeMap<SystemCeremonyId, PublishedCeremonyDefinition>, ) -> AgenticSystemValidationReport
Analyse this design against the definitions its pins resolved to.