ISDP Process Integration Subgroup (Team 2): DRAFT Consolidated “To Be” State

ISDP Process Integration Subgroup (Team 2): DRAFT Consolidated “To Be” State 2 September 2009

Outline • GSMP Principles [Team 1] • Participation • General Policies • Group Leadership • Anti-trust Caution, Code of Conduct • IP Policy • Teleconferences and Physical Meetings • Consensus / Decision Making • Voting Procedures • Appeals • Loss of Participation Rights and Reinstatement • Access to Work in Progress and Confidentiality • Organization • Working Groups • Standards Maintenance Groups (SMG) • Mission-specific Working Groups • Governance Groups • Central Operations (COPS) • Process Oversight Committee (POC) • GS1 Architecture Group (GAG) • Board Committee for Standards (BCS) • Process Flow • Community Interaction • Infrastructure

Outline • GSMP Principles [Team 1] • Participation • General Policies • Group Leadership • Anti-trust Caution, Code of Conduct • IP Policy • Teleconferences and Physical Meetings • Consensus / Decision Making • Voting Procedures • Appeals • Loss of Participation Rights and Reinstatement • Access to Work in Progress and Confidentiality • Organization • Working Groups • Standards Maintenance Groups (SMG) • Mission-specific Working Groups • Governance Groups • Central Operations (POC) • POC • GAG • BCS • Process Flow • Community Interaction • Infrastructure

Participation • Participating Organizations and Individuals • Participants in GSMP are organizations (companies, etc) • Any number of individuals from an organization may participate; however • Each organization gets one vote, and is counted once for purposes of establishing group participation minimums, etc

Participation • All work in GSMP is carried out in GSMP Groups • Working Group • Group responsible for carrying out the system development work of GSMP, including development of GS1 Standards, Guidelines etc. • Any organization may join (subject to IP and other pre-requisites) • Includes: • Standards Maintenance Groups (SMG) – standing • Mission-Specific Working Group (MSWG) – exists ‘til work done, further classified: • Combined Development Group (CDG) – requirements and standards (for narrower and/or less technical efforts) • Requirements Development Group (RDG) – requirements only • Standards Development Group (SDG) – standards only • Governance Group • Group responsible for ensuring that GSMP process is correctly executed and providing advice • Does not define standards, guidelines, etc. • Limited membership, by appointment or election • Includes: • Central Operations (COPS) • Process Oversight Committee (POC) • GS1 Architecture Group (GAG) • Board Committee for Standards (BCS)

Participation

Categorization of Participating Organizations • By relationship to GS1: • GO (staff), MO (staff), MO member in good standing (the most common case), GO Affiliate, MO Affiliate • By elective status w.r.t. a specific Working Group: • WG Member • Opted-in to WG but not a WG member • GSMP Member but not opted-in to WG • MO Expert Group Member • MO LCN Member • Other (subscriber to MO, but not in above categories) • By supply chain role: • End user (further subdivided: retailer, mfr, etc) • Solution provider (further subdivided: hw, sw, etc) • Auto-ID Labs • Other SDO

Categorization and Participation • By relationship to GS1: • MO and MO Member fully participate in GSMP • GO, GO Affiliate, MO Affiliate may participate in meetings but do not vote • By elective status: • See chart on next slide • By supply chain role: • Roles are considered when establishing group minimums; e.g., WG typically requires 2 end users (from each side of trading relationship), 2 MOs, 2 solution providers. • Roles do not limit ability to participate and vote: all MO Members may participate and vote regardless of supply chain role (including solution providers)

Elective Status and Participation

Outline • GSMP Principles [Team 1] • Participation • General Policies • Group Leadership • Anti-trust Caution, Code of Conduct • IP Policy • Teleconferences and Physical Meetings • Consensus / Decision Making • Voting Procedures • Appeals • Loss of Participation Rights and Reinstatement • Access to Work in Progress and Confidentiality • Organization • Working Groups • Standards Maintenance Groups (SMG) • Mission-specific Working Groups • Governance Groups • Central Operations (COPS) • POC • GAG • BCS • Process Flow • Community Interaction • Infrastructure

Group Leadership • All GSMP groups have the following designated roles: • Group co-chairs • Two or more • At least one present at each meeting • Group may continue while a vacancy is being filled • Group facilitator • A GO staff person • Must be present at each meeting (but may designate a substitute) • All group decisions are by consensus; co-chairs participate with other members equally in this regard

Anti-Trust Caution and Code of Conduct • All participation subject to GS1 Anti-Trust Caution and Code of Conduct • TBD for Team 4: name of “Anti-Trust Caution” – concern that the term “anti-trust” is US-specific • Both are read at start of every meeting

IP Policy Subject to Team 4 Review • IP Policy Agreement • Organization must sign in order to join GSMP • Provisions only operative upon “opt in” to a specific WG • Opt-In • Obligates organization to IP Policy w.r.t. output of a WG, in exchange for the right to participate and access WIP • See next slide for opt-in methods • Comment submission form • Used in community review for comments from organizations not opted-in • IP Declaration • Used during IP declaration period to declare intention not to license necessary claims on a royalty free basis

IP Policy: Opt in and opt out Subject to Team 4 Review • Explicit opt-in: • Organization signs an explicit agreement for each WG to which it opts in • Automatic opt-in: • Organization signs automatic opt-in agreement, which opts it in to all WGs existing at that time, and automatically opts in to any new WG formed with no further action required • Explicit opt-out: • Organization explicitly opts out of previously opted in WG • Can do this to exclude certain WGs after automatic opt-in • Cancellation of automatic opt-in: • Cancels all existing opt-ins • Must explicitly opt-in thereafter

Meeting Rules (Teleconference and Physical Meeting) • Written agenda distributed via community room in advance • Calendar invites sent as soon as date is known • Written agenda distributed at least 3 days in advance of weekly meeting or 1 week in advance of less frequent meeting • Minutes taken • Includes: name & org of all attendees, record of business transacted sufficient for non-attendees to keep up • Distributed to WG via community room afterward (facilitator decides whether to also issue an e-mail notification) • Preferably posted before next meeting, but within two weeks in any case • All attending organizations must be WG members and opted in • Participation minimums met. • Meeting may continue below minimums, • …but no voice votes may be taken • Continued failure to meet minimums escalated to POC by facilitator; POC may also notify IE • Group encouraged to use community room e-mail to carry on discussion between meetings

Decision Methods • Group consensus is overriding principle. • Four methods used:

Voting Details • Process-mandated voice motions: • Are subject to participation minimums • If not met, use group virtual vote instead • Group virtual vote: • Before vote closes, do not reveal voting tallies; only reveal comments that accompany votes, without disclosing who submitted them. • After vote closes, disclose the name of each company that voted and what its vote was (along with any comments submitted) • Community virtual vote: • Same notes as for group virtual vote

Appeals • Appeals of due process • Aggrieved organization first appeals to group co-chairs and facilitator • If not satisfied, then to POC (BCS also notified that POC appeal is in progress) • If not satisfied, then to BCS • BCS decision is final • Appeals of Voting Result • If a voting organization believes that the outcome of any particular vote has been unduly influenced by one stakeholder group, and has thereby resulted in a non-optimal outcome, they can escalate this concern by appealing the vote to the group co-chairs and facilitator • If not satisfied, then to POC (BCS and industry director also notified that POC appeal is in progress) • If not satisfied, then to the BCS • BCS decision is final • Automatic appeal of community vote to POC under specified conditions (next slide) • Continuation of process suspended until appeals resolved • Appeals of Architecture Questions • A group may seek architectural clarification from the GAG • If not satisfied, may appeal to BCS • BCS decision is final

Automatic Appeal of Community Vote • If an identifiable stakeholder group (e.g. supply side, demand side, 3PLS, MO, SP) participates in a community vote with the following conditions: • A predominance of the stakeholder group did not participate in the group via opt-in; and • The stakeholder group’s voting was uniform and divergent from the predominance of the other stakeholder groups; and • The result of the overall vote would be different in absence of the stakeholder group in question • …then the vote is automatically appealed to the POC to determine if undue influence was present and remedial action is necessary.

Loss of Participation Rights and Reinstatement Subject to Team 4 Review • An organization may lose right to participate in group meetings and vote if: • Continued anti-trust violation after being advised of violation • Continued code of conduct violation after being advised of violation • Unauthorized disclosure of WG materials • Process: • Co-chairs and POC discuss with organization (the individual, as well as the organization’s primary contact if different) • If decision is to suspend rights, all WG facilitators are notified, and organization told what it must do to regain rights • Organization may appeal to BCS, whose decision is final • Reinstatement: • Organization demonstrates to POC that reinstatement criteria are met • If POC decides to reinstate, all WG facilitators are notified and organization regains rights • If POC decides against, organization may appeal to BCS, whose decision is final

Access to Work in Progress and Confidentiality Subject to Team 4 Review • WG Members and opted-in organizations have full access to community room, including: • Documents (final and work in progress, minutes, etc) • E-mail archive • WG calendar • WG roster • An organization may not share above material with any organization that is not a WG member or opted-in, except by permission of GS1 legal • Exceptions: • All GSMP members have access to documents that have been submitted for community review • MOs may share materials with expert group members, under agreement • All ratified standards, guidelines, etc, are available to the general public on the GS1 website in the Knowledge Center. • Notwithstanding the above, all GSMP members will have visibility into what work efforts are underway and what is their status with respect to the process flow.

Organization • All work in GSMP is carried out in GSMP Groups • Working Group • Group responsible for carrying out the system development work of GSMP, including development of GS1 Standards, Guidelines etc. • Any organization may join (subject to IP and other pre-requisites) • Includes: • Standards Maintenance Groups (SMG) – standing • Mission-Specific Working Group (MSWG) – exists ‘til work done, further classified: • Combined Development Group (CDG) – requirements and standards (for narrower and/or less technical efforts) • Requirements Development Group (RDG) – requirements only • Standards Development Group (SDG) – standards only • Governance Group • Group responsible for ensuring that GSMP process is correctly executed and providing advice • Does not define standards, guidelines, etc. • Limited membership, by appointment or election • Includes: • Central Operations (COPS) • Process Oversight Committee (POC) • GS1 Architecture Group (GAG) • Board Committee for Standards (BCS) •  TBD: Specific groups that exist are TBD pending “committee landscape” discussion

Relationship of Mission-Specific Working Groups to Standards Maintenance Groups • Mission-specific group is typically related to one or more identified SMGs • In some cases, for example a mission-specific group working on a brand new area of standards, there may be no related SMGs; this is expected to be rare. In many such cases, the mission-specific group may become an SMG once it completes an initial standard, if justified by ongoing community interest. • The participation/voting minimums for the mission-specific group include at least two members of each related SMG. (The same people may also be the ones who meet the other minimums.) • A member of each related SMG is identified as either a co-chair of the mission-specific WG, or, if that is not possible, as a designated liaison member of the mission-specific WG to the SMG • During finalization, the mission-specific Working Group gives a presentation of the work to the related SMG(s), and encourages the SMG members' participation in the upcoming community review • SMG(s) is part of community review, and the vote thereafter

System Development Process per OE 3a 1 Statement of Business Need Clear Definition Of Need 2 Requirements Development Requirements Document 3 GS1 System Development Ratified Standards, Guideline, Approved Solutions, Services Publications, Marketing, Support Tools and Training 4 Deployment

Graphics Do Something = An activity performed by a group Doc = A document or other deliverable. An output of one activity, the inputto another = An open issue identified in the Team 2 issues list (issue 5 in this example) 5

ISDP “To Be” – 50,000 foot view Primarily SD Primarily IE SBN ISDP 1a: stmt of need ISDP 1b: process initiation ISDP 2: require-ments ISDP 3: stan-dards ISDP 4: deploy-ment WorkRequest SBN BRAD UnratifiedStandard Standard Charter Statement of Business Need, similar to old GSMP Business Case Document • Includes: • Work request(s) • Resource needs • WG assignment (new or standing) • WG chairs (if new) • Settings for ISDP “knobs” • Expected timeline Like old GSMP “change request” or EPC “enhancement request”

Handling of Parallel Work Streams • Many-to-many mapping of Work Requests to Chartered work efforts: • Related work requests may be combined into a single work effort • One work request may best be split into multiple work efforts • Variety in the BRAD-to-Standard transition: • “Narrow” path possible when impact of BRAD on standards is clearly identifiable before BRAD work begins (corresponds to GSMP “simple” process) • “Accumulated” path used when finished BRADs are accumulated over time then consolidated into a single work effort (as in GDSN) • Normal path provides for many-to-many mapping of BRADs to standards developments: • Related BRADs may result in a consolidated change to a standard • One BRAD may result in parallel changes to several standards • Allows decision of which standard(s) are affected to be made in context of fully documented requirements

PCD ISDP “To Be” – 40,000 foot view “Accumulated” BRAD path ISDP 1: stmt of need ISDP 3: stds ISDP 2: require-ments 5 If SBN needed PCD 34 DevCharter Std Work PCD PCD WR DraftCharter Charter, SBN BRAD Work Work DevCharter Std WR Work WR SBN DraftCharter Charter, SBN BRAD Work Work Work DevCharter Std Work WR SBN DraftCharter Charter, SBN BRAD Work Work Work Std Work WR “Narrow” BRAD path Primarily IE Primarily SD = Work done by a WG, including approvals, voting, ratification, etc (detailed in later slides) = Prioritize, Consolidate, Distribute Work

Charter Ingredients • Every ISDP work effort is governed by a charter, which specifies • Title of work effort • References the Work Request(s) to be addressed • Specifies GS1 resources needed • What WG is responsible (standing, or new mission-specific) • WG chairs (for a mission-specific WG) • Settings for ISDP “knobs” (see next slide) • Expected timeline, expressed in terms of ISDP milestones

ISDP “knobs” specified in Charter • Work Group: • Standing “Standards Maintenance Group” (SMG) (specify which one) – requires justification against established criteria • New mission-specific group (specify a name for it, and to which SMG, if any, it reports) • Stakeholder participation minimums • Identify specific types of end user, solution provider, if appropriate • Provide justification if default minimums are to be waived/altered • BRAD-to-Standards transition: • Normal path (hand off to standards WG via PCD process) • “Narrow” path (same WG continues from requirements development to standards development) – must specify which standard(s) will be affected • “Accumulated” path (stops at finished BRAD; at specified trigger such BRADs are consolidated and entered as a new Work Order) • “Narrow” and “Accumulated” path require justification against established criteria • Prototype testing: yes or no • Conformance requirements: yes or no • Collateral deliverables needed: implementation plan, impact analysis, other collateral 6 6 Development charter items

Setting of Process “knobs” • It is role of IE and POC (with assistance from COPS) to determine the appropriate process “knob” settings for each work effort. • IE/POC responsible for establishing and maintaining criteria by which these decisions are made • Starting point for these criteria are given on next few slides • Charter for work effort records these decisions

GSMP Work Order Spectrum Maintenance-related Development-related • Maintenance-Related Order: • A small change to an existing standard or guideline that can readily be handled by a standing committee • Examples include: Errata, New EDI code values, new symbol placement rules, GDSN validation Rules • Development-Related Order: • The creation of a new standard/guideline or significant change to existing standard/guideline. • A standards or guidelines change that spans topic areas of GS1 Standards • Examples include: GDSN Extension, HF standard, EPCIS enhancement for layers, New Bar Code symbology, new XML Message

Maintenance-Related Versus Development-Related Orders These terms are intended to give broad awareness of the nature of work in a given group. They do not represent explicit categorizations and it is foreseen that many work efforts may not readily fall into one category or another. Work efforts obviously at one extreme or the other will be dealt with through “preset” GSMP process settings Work efforts that are not obviously one or the other will be dealt with procedurally in the GSMP by an analysis to find the optimal way to address the specific work effort which will be captured in the group Charter and approved by the POC

Spectrum for Standards & Guidelines Content Application-Related Technology-Related • Application-Related Standards/Guidelines • GS1 Standards/guidelines that primarily deal with new combinations of business content with existing business-context neutral technologies • Examples include: new Business Message Standards (XML) based on existing design patterns, GDSN Extensions (Hardlines, Books, etc.), Traceability Process Standard • Technology-Related Standards/Guidelines • GS1 Standards defining data, messages, and interfaces that are business context-neutral (primarily reusable across many business processes), along with GS1 Guidelines for their use • Examples include: XML “SBDH” (Standard Business Document Header), Certificate Profile, Air Interface Protocols

Application-Related vs Technology-Related Standards / Guidelines • The terms Application-related and Technology-related are intended for general awareness of the TYPE of user expertise needed to bring about the optimal standard design. • These terms will help to clarify why some work efforts are handled in one group or two. • Application-related Standards, as they focus on development of business content utilizing existing technologies, are generally developed in a single group which creates the requirements AND approves the subsequent standards, or combined with other standards groups working on similar requirements • Technology-related Standards, as they focus on business context neutral technologies, are developed in two groups, the first made up of business users who create the business requirements, and technical groups who develop a technical standard

Clarification of Application-related vs. Technology-related Standards As earlier stated, these terms are intended to give broad awareness of the nature of work in a given group. They do not represent explicit categorizations and it is foreseen that many work efforts may not readily fall into one category or another. Work efforts obviously at one extreme or the other will be dealt with through “preset” GSMP process settings Work efforts that are not obviously one or the other will be dealt with procedurally in the GSMP by an analysis to find the optimal way to address the specific work effort which will be captured in the group Charter and approved by the POC

GSMP Process Settings Decision Tool Technology-related Typically ad-dressed by a standing group (“narrow path” + SMG) Typically addressed by a new group that analyzes requirements, followed by a second new group that develops the standard/guideline (possibly in response to several related requirements streams) (“normal path” + “mission-specific group”) Maintenance-related Development-related Typically addressed by a new group that both analyzes requirements and develops the standard/guideline (“narrow path” + “mission-specific group”) Application-related

Group Naming Based on Process Settings These names are more specific ways of describing a mission-specific WG, based on the process steps it is responsible for

Step 1: 25,000 Feet ISDP 1a: stmt of need [IE] Industry Roadmap PCD Ongoing Engagement with a given Industry Work Request Form SBN Team Draft SBN SBN Finalize SBN PendingSBN If a WR was submitted without a SBN, and it is substantial enough to warrant one, it is sent back to IE to review and create the SBN Revise SBN if needed ISDP 1b: process initiation [Dev] Vote to advance to next step Omitted if standing SMG to be used Review of SBN by WG to ensure it’s understood (consult with IE as needed) PCD Work request with SBN Charter SBN DraftCharter Draft and issue call-to-action Form WG Work request, no SBN SBN Work request originating from other than IE Call to Action New C-Room IE IE POC 71 IE

Step 2: 25,000 Feet ISDP 2: requirements Community review (*) of BRAD Work on BRAD Finalize(*) BRAD Charter, SBN BRAD Community GAG If WG is mission-specific reporting to an SMG SMG (*) “Finalize” implies a certain sequence of review and voting steps detailed on slide 14 (*) “Community review” implies a certain sequence of review and voting steps detailed slide 15

Step 3: 25,000 Feet ISDP 3: system development POC Optional PCD 1st IP Review BRAD DevCharter Community review(*) Prototype testing Finalize(*) changes UnratifiedStandard Work on Standard Finalize(*) Standard BRAD “Narrow” path Community GAG SMG (*) “Finalize” implies a certain sequence of review and voting steps detailed on slide 14 (*) “Community review” implies a certain sequence of review and voting steps detailed on slide 15

Step 4: 25,000 Feet ISDP 4: system development 2nd IP Review Community review(*) POC Ratification Board Ratification Ongoing revisions to collateral RatifiedStandard UnratifiedStandard Confirm collateral list Work on collateral Finalize(*) all collateral Other Step 4 collateral Marketing, IE Community POC BCS POC GAG SMG (*) “Finalize” implies a certain sequence of review and voting steps detailed on slide 14 (*) “Community review” implies a certain sequence of review and voting steps detailed on slide 15

Step 4 open issues • Should impact assessment wait until Step 4, or be done in Step 3 prior to the first community review of draft standard? • Rationale: we really ought to have thought through issues of compatibility and transition before the technical details have been finalized • What is the complete list of collateral materials that might be created in Step 4? (see also next slide) • Impact assessment (but see above) • Value proposition – based on SBN • Scenarios / use cases • Migration Plan • Implementation plan • Implementation guide – based on BRAD together with standard • Marketing collateral • Outreach • How does WG engage non-WG resources in Step 4 (e.g., other SPs, IE, Marketing, other end users, MOs)? What if any IP policy issues arise from this? • In most cases, this does not need to be formalized. WG can solicit help from outside if needed. • If WG needs help from others, those others must either (a) opt in to WG; or (b) only be presented with work artifacts that have received prior community review • Scope of community review in Step 4 – what is reviewed? • Andrew: I would allow everything to be reviewed. This is in line with our principles • While the standard or guideline (previously reviewed in Step 3) is made available at this stage for reference, comments are not solicited on that and changes will not be made in Step 4. • Scope of ratifications in Step 4 – standard only or also the collateral materials? • Andrew: implementation guidance, value proposition, migration plans and scenarios are ratified. I think marketing materials should be excluded because opinions will be so subjective that consensus will be hard to achieve • Michele: but what does “ratification” mean for other deliverables? For a standard, it means the standard cannot be changed without due process, but this may not be appropriate for guidance, migration plans, etc, which may evolve as they are used • Conclusion: board does not “ratify” collateral. POC approves, and collateral may change post-ratification if needed • Criteria for omitting some or all Step 4 deliverables • Andrew: Obviously errata and new codes don't need much if anything. Items coming out of CDGs or SDGs should have at least a value proposition, operational guidance and scenarios • Should Step 4 begin with an assessment of interest – do we want to continue with collateral development and ratification or have the needs of end users shifted since the work was initiated?

Step 4 deliverables • Impact statement (move this to Step 3?) • Back compatibility, migration issues, etc • Qualitative assessment of the size of the impact – difficulty, number of hours, etc. • Value Proposition – based on SBN • tells members why they should bother to implement the standard in terms they can take to their budget holders for approval. • is also the item that product marketing and business development functions in larger MOs will find useful in their communications • Scenarios / use cases • To communicate the way that the standard is intended to be used (not in a restrictive way), helping to avoid divergent interpretations of what the standard is • Implementation / Migration plans. • If the output is a development of an existing standard (an update or a new version) migration planning guidance will be needed. How are existing users supposed to move from existing standards to the new and at what pace? Is there a need for concerted community action? Do two (or more versions) co-exist and what are the sunrise and sunset dates? • If the output is a new standard, implementation guidance will be needed. How are users expected to carry out their initial adoption of the standard and at what pace? Is there a need for concerted community action? Is there a defined sunrise date? Is there any relationship to existing standards, and if so, what is the impact on implementations of the existing standard due to adoption of the new standard? • Including revisions to GS1 Services, if applicable; i.e. coordinating end user activity with activity of GS1 in deploying/upgrading GS1 Services • Implementation guide – based on BRAD and the standard • For each business requirement, show how the relevant part of the standard can be used in an implementation to meet the requirement • FAQs • Marketing collateral • “Sales pitch” • Analysis of other business needs for which the new standards or guidelines may play a role • Materials related to overall GS1 strategy • Outreach plan • Webinars • Press releases • Newsletters • Bulletins • E-mail distribution lists

Document Maturity Levels • A document under development (BRAD in Step 2, Standard in Step 3, Collateral in Step 4) has a maturity level that indicates how far along the process it is • Maturity levels are “ratchets” that ensure a one-pass flow: • At a given maturity level, a document may undergo revision as development is performed or comments are processed • A document’s maturity level advances at the completion of a process milestone marked by a vote, approval, or ratification • A document never moves to an earlier maturity level • Rare exception: POC may force rework due to IP claim or other dire circumstance

WG development WG review (+ GAG if no community review) Community, GAG review Prototyping POC ratification BCS ratification Publication Document Maturity Levels Document Type BRAD, guideline, etc, without community review BRAD, guideline, etc, with community review Standard,not prototyped Standard,prototyped What takes place while at that maturity level Draft Draft Draft Draft Draft(penultimate) Draft(penultimate) Draft(penultimate) Draft(penultimate) Community Review Draft Community Review Draft Community ReviewDraft Prototype Standard Unratified Standard Unratified Standard Unratified Standard Unratified Standard Final Document Final Document Ratified Standard Ratified Standard

“Finalize” process • Used to progress a document through a significant process gate (completion of development/test work) WG collects comments using comment form WG resolves comments RevisedPenultimateDraft CRD or FinalWorkingDraft Group Motion to Begin WG Review Group Vote to Progress Draft (penultimate) Work on Document Draft “Finalize” steps “Motion” = takes place on concall or meeting; 2/3 of attendees “aye” + established minimums required to move forward. WG may decide to do this via Kavi ballot instead (and must do so if minimums not met during a voice vote) “Vote” = via Kavi; 2/3 “yes” votes + established minimums required to move forward. Exception: for finalization of requirements on “accumulated” path, this may be done via concall motion instead

“Community Review” process • Used to solicit and respond to community input Prototype Standard For a standard subject to prototype/pilot Announce and distribute to community Community provides comments via comment form WG resolves comments RevisedComm. Review Draft Commu-nity Vote to Progress Community ReviewDraft Unratified Standard For a standard not subject to prototype/pilot Final Document For a BRAD, guideline, or other deliverable “Community Review” steps Community Community GAG If WG is mission-specific reporting to an SMG SMG “Vote” = via Kavi; 2/3 “yes” votes + established minimums required to move forward Participants in this vote include WG plus all community members who have signed IP policy

ISDP Process Integration Subgroup (Team 2): DRAFT Consolidated “To Be” State