POC definition: 

1. SPONSOR– Lei_Huang (CMCC), huangzh (China Telecom), wangyaoguang (Huawei).
2. NON BLOCKING- POC  related defects shall not block the current release and not create any backward incompatibility
3. COMPLIANCE- POC should be fully compliant with ONAP development guidelines, including development procedures.
   1. License/Vulnerabilities- POC development that includes entry points in the release version must comply with license scans and vulnerability fixes.
   2. Proprietary Components– The PoC is not contributing its software otherwise it is subject to CLAs.
   3. Security- PoC development shall be compliant to security guidelines and incorporate the latest security fixes so as not to create a security vulnerability.
   4. Performance- PoC should not impact the performance of the main code; this should be implied as it is kept in a separate Repo. The PoC development team should have an eye on ONAP performance if in the future it might be evolved to be incorporated into the ONAP platform.
   5. Back Doors- A POC should not introduce a back-door to the stable features so it must comply with security, code coverage, and license scans requirements.
   6. Resources- The PoC should perform an assessment to see that adequate resources are available such as PoC toolchains (Jenkins, Sonar, NexusID, LF resources, Test coverage resources etc).
   7. Approval for inclusion- The TSC or Use Case S/C shall approve the PoC to proceed as part of the current release.
4. INDEPENDENT OF MAIN RELEASE- PoC are not part of the (current) ONAP release product.
   1. Documentation- The PoC will have documentation in a wiki, linked by https://wiki.onap.org/display/DW/Support+for+Intent+Framework+and+Intent+Modeling .
   2. Independence- The PoC shall be kept independent of the official (current) release. The PoC shall not introduce any new requirements in the current release.
   3. Integration/Testing responsibility- The testing, integration and use of the PoC shall be in the purview of the PoC development team.
   4. PoC Release Notes- PoC release notes may be developed by the PoC team, they may include details of functionality available, known issues, and known limitations/incomplete features, and these info will be tracked by POC wiki (same as above), https://wiki.onap.org/display/DW/Support+for+Intent+Framework+and+Intent+Modeling .
5. CODE INDEPENDENCE- The PoC software shall be kept separate and independent of the main ONAP branch/repository.
   1. Common Code Usage- PoC software using common code, does not change the treatment of the common code with regards to completeness, S3P, documentation and other common code expectations.
   2. Separate Branch- PoC should be kept in separate repository branch.
   3. Evolutionary Platform Software– The main code for this POC will be separate from other ONAP components, while enhancements on current ONAP components will be documented in POC wiki.
6. PROCESS- The PoC may follow a process during development.
   1. Milestones- The PoC team may follow some sort of development process. It is suggested that they use the Mx milestones/gates as the release progresses or some similar process.
   2. Final Approval - The final approval of a PoC shall ultimately be determined by the sponsor/leader of the PoC. We expect a "report" of how the PoC went to socialize at the end of Honolulu release and inform the TSC or Req S/C.
   3. PoC Overlap- It is recommended that the PoC team socialize their PoC so that other teams working on Use cases and PoCs are aware of potential cross-interactions that might occur and overlap in scope and functionality. Will use POC wiki (same as above) https://wiki.onap.org/display/DW/Support+for+Intent+Framework+and+Intent+Modeling .
7. SCOPE++- A PoC can be used to demonstrate functionality related to a project concept, a Use Case, functional or non-functional requirements, project specific extensions.
   1. ** Definition**– The POC is proposed to enhance ONAP with an general-purpose intent framework, which may contains intent translation, intent execution and intent decision and execution etc. It is expected to be one of ONAP component or sub-component in the future. In R8, the requirement will provide the internal reference architecture and interacting with other ONAP components, and also introduce intent modeling for specific use cases, such as intelligent radio optimization and intelligent slicing management.
   2. Project Review- the PoC team shall review the PoC with Req S/C and impacted projects PTLs (such as UUI, A&AI and potential External API Framework).
8. POC INCORPORATION- The PoC is to demonstrate a general-purpose intent framework. In addition to the Intent framework code, PoC team wishes to incorporate the PoC code into the main repository should follow the standard procedures for introducing new functionality in subsequent ONAP releases.
   1. Feature Proposals- There exists a standard procedure new functionality introduction leading up to M0 shall be followed by a PoC in subsequent releases by the PoC team if they wish to incorporate PoC Software into the main repository.
   2. Partial PoC Introduction- The original PoC scope may be altered from what is introduced in a future release. Lessons learned will be introduced in the “report” (see point #6 above) for the future release.
   3. Merge Responsibility- It will be the responsibility of the PoC Team to properly merge the PoC code into the main-line branch (S/W repo) if it becomes part of the future release. Merging should follow compliance principles (described in point #3 above).
   4. ** Proprietary Components**- If the PoC used proprietary components or software, for formal including into ONAP it would need to be excluded in the final merge because ONAP is an open source initiative.

========

Besides, More details are as follows:

Owners (one of these should be the Assignee - use @ notation):

CMCC: zm330, Lei_Huang

China Telecom:  huangzh, @Xin Zhang

Huawei: wangyaoguang,  @ Xianming Li 

Link to HLD/LLD (if any):  https://wiki.onap.org/display/DW/Support+for+Intent+Framework+and+Intent+Modeling 

Dependency Relationships with Other Projects:

• Reference architecture for ONAP with Intent Framework

         - Functional blocks and interfaces between them

         - Initial Implementation as a separate component with multiple micro services.

• External interface to other existing ONAP Components

         - UUI, SO, CDS, AAI/CPS, etc

• General Intent information modeling, and concrete intent data model for specific use cases

Project Impact (Test Only (TO), Code (C)):

Intent Framework(C), SO(TO), CDS(TO), CPS(C)

Company Engagement:

China Mobile, Huawei, China Telecom