https://github.com/camaraproject/CustomerInsights/issues/23

DT

ON-HOLD

06/MAR: New Topic: Two levels of scoring precision in API.

DT brings this topic. Based on Czech republic business, there is two different levels of precision for the score (rough and detailed) with different prices, they have customer for both models. That is the business idea. And look for a technical solution for it.

TEF will check about this concept internally from business view. Also VF will talk internally about this concept.

20/MAR: TEF comments that business is aligned with the concept/idea of having different precision models in order to be able to monetize them with different API pricing. They do not see this concept as linked directly to a score model but to indicate different level of precision available for any scoring model, like a new input parameter that reflects the precision required. DT will share this internally to also get some feedback, also check how this is done in other WGs like device location, having different precision for the location of the device.

03/APR: Rafal will get information from Business side. As a comment a parameter could be accomodated in request to indicate the precision and if not indicated default precision is provided. Anyway, it is an observation and it is needed more details from Business before thinking in a technical solution. Also to check info from Operate APIs and TMF regarding the provision of a product and relationship to request a higher precision.

24/APR: DT is still pending to further check about this topic. DT comments another idea, if we consider scoring model as country specific, maybe indicate this scoring granularity based in some model in the response, but not sure if this would be needed.

15/MAY: No new information yet. Rafal is contacting Poland Operators to have feedback. Once he has compiled and consolidate this feedback WG can move forward with this discussion.

https://github.com/camaraproject/CustomerInsights/issues/30

TEF

ONGOING

24/APR: New issue opened by TEF on 24/APR. Within this issue the pending topics (sources and examples for algorithm model will be provided). Some initial input provided by TEF regarding sources provided, still some concepts to be checked. It is asked within the WG whether level of granularity/deep is fine (Telco Operator system that hosts this information) and WG (CT, VF) sees that approach OK. It will be needed more time to get some examples to show and document them. It is expected to generate inital PR in the next weeks, once the source is consolidated for them and communicated to the WG.

15/MAY: PR https://github.com/camaraproject/CustomerInsights/pull/40 generated for the WG review. The PR adds two contents to customer-insights-algorithm-model-definition.md document in API_Documentation folder:
- Telco Operator source(s) for algorhitm model concepts documented
- Examplification of implementation for the algorithm (informative example, as exact implementation MUST be agreed within a gievn market, so as it is an illustrative information for the community to figure out how this could work internally). Pending to be reviewed.

https://github.com/camaraproject/CustomerInsights/issues/31

DT

ON-HOLD

24/APR: New issue opened by DT on 24/APR. It tries to manage the case in countries where there is personal identification number that changes when renewed but national identification number is kept from the first time it is generated (for instance this happens in Poland and it is a case in finantial procedures). It has also to discuss with Business Team. Some clarifications are commented by TEF, just to understand the topic. The “idDocument” concept refers to the national identification number that never changes (it is permanent) and in some countries the ID number of the document changes every time that document is renewed.
So probably some clarifications will have to be done regarding “idDocument” and also being checked by DT whether ID number of the document is also needed as optional for Use Cases within the context of this API. DT also will add some reference to wikipedia for this concept.
VF comments about the use of idDocument/phoneNumber. In Spring25, in 3-legged scenario no identification needs to be provided as API susbject is identified by the token. Thery are needed for 2-legged scenario and depending on Telco Operator rules (some Operators may only need phoneNumber, others both to perform a double-check to ensure is the same API Subject).

15/May: DT comments it is also pending to have information from Poland market, just to know whether both concepts would be required or only one (national identification number, i.e. idDocument). Rafal also comments about KnowYourCustomer/issues/197, where it is being discussed the support and indication of different idDocument types, just to have in mind for potential alignments. Pedro comments that even ID number of the document would not be required in the context of Customer Insights API, if idDocument description is modified in KYC we can align also in this WG to use the same description.

https://github.com/camaraproject/CustomerInsights/issues/33

WG

NEW

15/MAY: Parent issue for Metarelease Fall 25 activities generated.

AoB

WG