Open APIs

The swagger definition of TMF651 does not enforce values, nor is there a state model. It says: "Status: Typical values are: in process, approved and rejected".
Would it be fair to state that the status would rather be more close to the ones of our Product in TMF637? 
"In process" seems a bit weird. Having both "Approved" and "Active" is not really possible, approved doesn't mean active if the start date is not really reached, right?
Would the following states & lifecycle diagram make sense?

Explicit approvals by a party would then go under the section agreementAuthorization where there is another status where we could use values per party approved, rejected.

Any comments on the above proposal? Tx in advance.

We have a discussion on this topic in the E2eODA team which is preparing a series of B2B(2X) use cases including Agreement Management. in TMFS019

The discussion is around how to extend the SID Model which is being updated for Agreement (here) to include concrete attributes such as legal matters.  That team has been discussing with @Kamal Maghsoudlou  how to realize this updated SID model and put in the necessary attributes/ characteristics, into TMF651.

Conversation is currently around using Sematic Web RDF ( ttl and JSOLN-LD ) to achieved this as we see examples in legal space of commonly accepted processes and states and different practices in telco ( for internal agreements),

My opinion is we need open world model thinking here so I would sugget having with state, a reference (href?) to a controlled vocabulary where the string values of State are constrained by the appropriate vocabulary for the specific context. I would imagine that the state model following the product TMF837 would be one reasonable vocabulary  context, but I see other alternatives for external contracts and legal contracts which need to align with other industry conventions.

The updated SID Agreement model is in  

[ISA-757] Review SID Agreement ABE - TM Forum JIRA

and in e2eODA we are working on some attribute updates  in

Agreement Extension Class, attribute vocabularies Definitions (Modifications and Additions) JIRA additions to ISA-757 - End to end ODA - TM Forum Confluence 

but these are far from complete or stable

I will raise this post on the next e2eODA call which with the seasonal holiday  break is not until 14th January 2026.

The swagger definition of TMF651 does not enforce values, nor is there a state model. It says: "Status: Typical values are: in process, approved and rejected".
Would it be fair to state that the status would rather be more close to the ones of our Product in TMF637? 
"In process" seems a bit weird. Having both "Approved" and "Active" is not really possible, approved doesn't mean active if the start date is not really reached, right?
Would the following states & lifecycle diagram make sense?

Explicit approvals by a party would then go under the section agreementAuthorization where there is another status where we could use values per party approved, rejected.

Any comments on the above proposal? Tx in advance.

And the states will also depend on the Party roles. An agreement between Party role = Marketplace and Party role = Business Partner will have certain states. An Agreement between party role = Marketplace owner and party role = Customer will have different states.

------------------------------
Sri-Jagadish (Jag) Baddukonda
ServiceNow, Inc.

Original Message:
Sent: Dec 22, 2025 04:13
From: David Milham
Subject: TMF651 - Agreement Management - What states to use?

We have a discussion on this topic in the E2eODA team which is preparing a series of B2B(2X) use cases including Agreement Management. in TMFS019

The discussion is around how to extend the SID Model which is being updated for Agreement (here) to include concrete attributes such as legal matters.  That team has been discussing with @Kamal Maghsoudlou  how to realize this updated SID model and put in the necessary attributes/ characteristics, into TMF651.

Conversation is currently around using Sematic Web RDF ( ttl and JSOLN-LD ) to achieved this as we see examples in legal space of commonly accepted processes and states and different practices in telco ( for internal agreements),

My opinion is we need open world model thinking here so I would sugget having with state, a reference (href?) to a controlled vocabulary where the string values of State are constrained by the appropriate vocabulary for the specific context. I would imagine that the state model following the product TMF837 would be one reasonable vocabulary  context, but I see other alternatives for external contracts and legal contracts which need to align with other industry conventions.

The updated SID Agreement model is in  

[ISA-757] Review SID Agreement ABE - TM Forum JIRA

and in e2eODA we are working on some attribute updates  in

Agreement Extension Class, attribute vocabularies Definitions (Modifications and Additions) JIRA additions to ISA-757 - End to end ODA - TM Forum Confluence 

but these are far from complete or stable

I will raise this post on the next e2eODA call which with the seasonal holiday  break is not until 14th January 2026.

------------------------------
Dave Milham
TM Forum, Chief Architect

Original Message:
Sent: Dec 19, 2025 04:54
From: Peter Broucke
Subject: TMF651 - Agreement Management - What states to use?

The swagger definition of TMF651 does not enforce values, nor is there a state model. It says: "Status: Typical values are: in process, approved and rejected".
Would it be fair to state that the status would rather be more close to the ones of our Product in TMF637? 
"In process" seems a bit weird. Having both "Approved" and "Active" is not really possible, approved doesn't mean active if the start date is not really reached, right?
Would the following states & lifecycle diagram make sense?

Explicit approvals by a party would then go under the section agreementAuthorization where there is another status where we could use values per party approved, rejected.

Any comments on the above proposal? Tx in advance.

------------------------------
Peter Broucke
Proximus SA
------------------------------

We have a discussion on this topic in the E2eODA team which is preparing a series of B2B(2X) use cases including Agreement Management. in TMFS019

The discussion is around how to extend the SID Model which is being updated for Agreement (here) to include concrete attributes such as legal matters.  That team has been discussing with @Kamal Maghsoudlou  how to realize this updated SID model and put in the necessary attributes/ characteristics, into TMF651.

Conversation is currently around using Sematic Web RDF ( ttl and JSOLN-LD ) to achieved this as we see examples in legal space of commonly accepted processes and states and different practices in telco ( for internal agreements),

My opinion is we need open world model thinking here so I would sugget having with state, a reference (href?) to a controlled vocabulary where the string values of State are constrained by the appropriate vocabulary for the specific context. I would imagine that the state model following the product TMF837 would be one reasonable vocabulary  context, but I see other alternatives for external contracts and legal contracts which need to align with other industry conventions.

The updated SID Agreement model is in  

[ISA-757] Review SID Agreement ABE - TM Forum JIRA

and in e2eODA we are working on some attribute updates  in

Agreement Extension Class, attribute vocabularies Definitions (Modifications and Additions) JIRA additions to ISA-757 - End to end ODA - TM Forum Confluence 

but these are far from complete or stable

I will raise this post on the next e2eODA call which with the seasonal holiday  break is not until 14th January 2026.

------------------------------
Dave Milham
TM Forum, Chief Architect

Original Message:
Sent: Dec 19, 2025 04:54
From: Peter Broucke
Subject: TMF651 - Agreement Management - What states to use?

The swagger definition of TMF651 does not enforce values, nor is there a state model. It says: "Status: Typical values are: in process, approved and rejected".
Would it be fair to state that the status would rather be more close to the ones of our Product in TMF637? 
"In process" seems a bit weird. Having both "Approved" and "Active" is not really possible, approved doesn't mean active if the start date is not really reached, right?
Would the following states & lifecycle diagram make sense?

Explicit approvals by a party would then go under the section agreementAuthorization where there is another status where we could use values per party approved, rejected.

Any comments on the above proposal? Tx in advance.

------------------------------
Peter Broucke
Proximus SA
------------------------------