48. Voting
48.1 Board Vote
48.1.1 A Board Vote is the formal decision procedure by which the Board of Trustees, Board of Directors, or equivalent fiduciary apex body acts on matters reserved to it by law, charter, bylaw, delegation instrument, fiduciary duty, mission lock, public-benefit obligation, risk profile, financial significance, institutional consequence, or governance doctrine. A Board Vote is not merely an expression of preference. It is the recorded exercise of fiduciary authority.
48.1.2 A Board Vote is required or appropriate where the matter concerns constitutional stewardship, mission protection, approval of bylaws or major policies, annual plans and budgets, appointment or removal of senior officers, major financial commitments, institutional risk, legal compliance, conflict-sensitive transactions, public-good rail integrity, anti-capture controls, major publication or reputation risk, major data or AI governance risk, formation or dissolution of major bodies, reserved delegations, or other matters assigned to the Board.
48.1.3 A Board Vote must be evidence-ready. Directors or trustees should receive the relevant Decision Pack, authority analysis, conflict disclosures, AEPs where applicable, safeguards record, public authority capacity record where relevant, technical findings where required, financial or resource implications, legal review where required, public claims implications, correction path, and proposed resolution. A Board Vote without adequate record is procedurally formal but substantively weak.
48.1.4 A Board Vote must remain within the Board’s authority. The Board may authorize institutional action within its mandate, but it cannot create public authority approval, community consent, technical certification, finance advice, procurement award, regulatory clearance, or downstream execution where those functions belong elsewhere. Board authority is fiduciary and institutional, not universal.
48.1.5 A Board Vote should follow consensus-first deliberation where possible. The Board may seek convergence, re-scope the question, impose conditions, defer, refer to TMDs, request safeguards review, or require public authority clarification before voting. Where a vote is required, the vote should occur after dissent and conditions have been heard and recorded.
48.1.6 Board Vote records must identify the motion, authority basis, notice, quorum, participating directors or trustees, recusals, conflicts, materials reviewed, votes in favour, votes against, abstentions, recorded dissent, conditions, effective date, delegated implementation authority, public claims limits, and correction path.
48.1.7 A Board Vote may approve, reject, defer, condition, ratify, rescind, re-scope, refer, suspend, or require correction. The record must state which action occurred. “Board discussed” must never be treated as “Board approved.”
48.1.8 The doctrine is direct:
A Board Vote is the recorded fiduciary act of the institutional apex; it can authorize institutional governance within mandate, but it cannot manufacture authority that belongs to public bodies, communities, technical functions, finance actors, or downstream lawful actors.
48.2 Member Vote
48.2.1 A Member Vote is the formal decision procedure through which the members, General Assembly, or equivalent membership body exercise constitutional or reserved member authority. It is used where the governing instruments, applicable law, or institutional doctrine require member approval, member confirmation, member election, member ratification, or member consent.
48.2.2 A Member Vote is appropriate for matters such as election or removal of directors where applicable, approval of fundamental changes, bylaw amendments where reserved to members, dissolution or continuance matters, merger or structural transformation where applicable, changes to membership rights, approval of constitutional instruments where reserved, or other matters assigned to the General Assembly or membership body.
48.2.3 A Member Vote is not day-to-day management. Members provide constitutional legitimacy and reserved authority, not operational control over evidence packs, TMD findings, routeability determinations, public-safe releases, technical baselines, platform administration, or ordinary management unless the governing instruments expressly assign such matters to members.
48.2.4 A Member Vote must be preceded by clear notice, matter classification, authority explanation, decision text, supporting materials, proposed effect, voting threshold, eligibility criteria, conflict treatment where applicable, dissent route, and record consequences. Members must know whether they are voting on a constitutional matter, election, ratification, amendment, strategic direction, or other reserved matter.
48.2.5 A Member Vote must preserve the distinction between member authority and helix legitimacy. Members may approve reserved institutional matters, but Helix Councils may provide social, technical, public authority, industry, research, civil society, media, community, and Indigenous or local legitimacy inputs where applicable. A Member Vote should not erase unresolved helix concerns where those concerns are material.
48.2.6 A Member Vote must not be used to override protected rights, statutory public authority processes, community consent requirements, fiduciary obligations, legal duties, privacy rules, protected knowledge controls, or safeguards holds. Member authority is constitutional but bounded.
48.2.7 Member Vote records must identify eligible members, notice, quorum, voting method, threshold, votes cast, abstentions, invalid ballots where applicable, conflicts or limitations where applicable, resolution text, effective date, conditions, dissent or minority statements where allowed, and correction path.
48.2.8 The doctrine is direct:
A Member Vote expresses reserved constitutional membership authority, not operational control over the Rail; it is valid only when properly noticed, scoped, recorded, and bounded by law, safeguards, and role separation.
48.3 Helix Concurrence
48.3.1 Helix Concurrence is the recorded convergence or non-objection of the relevant Helix Councils or helix constituencies after evidence-bound deliberation on a matter affecting whole-of-society legitimacy. It is not a substitute for Board approval, member approval, public authority approval, technical verification, community consent, or finance-readiness. It is a legitimacy input.
48.3.2 Helix Concurrence may be required or appropriate where a matter affects multiple social orders: public authorities, industry and operators, academic and research actors, civil society and media, communities, Indigenous or local knowledge holders where applicable, environmental interests, or other defined helix surfaces. It helps ensure that governance does not become captured by one actor class.
48.3.3 Helix Concurrence should be used for major public-good baselines, public-safe reporting frameworks, national priority registers, regional comparability frameworks, community observatory models, public-facing maturity frameworks, platform governance principles, high-risk technology pathways, public authority interface protocols, and other matters where broad legitimacy matters.
48.3.4 Helix Concurrence must be evidence-bound. Councils should receive the relevant AEP, Baseline, Decision Pack, safeguards record, public authority capacity record, technical summary, publication class, claims limits, and dissent record. A helix process without evidence becomes consultation theatre.
48.3.5 Helix Concurrence must preserve difference among helix voices. Concurrence should not flatten public authorities, industry, researchers, civil society, media, communities, and Indigenous or local knowledge holders into one generic stakeholder outcome. Each helix voice may have different authority, risk, and concern. Records should show convergence and unresolved objections by class where material.
48.3.6 Helix Concurrence may be full, conditional, partial, withheld, deferred, or not applicable. Conditional concurrence may require safeguards, re-scoping, public authority clarification, technical review, public-safe summary revision, or monitoring. Partial concurrence must state which helix classes concur and which do not.
48.3.7 Helix Concurrence must not be used to imply consent or approval beyond its record. A Helix Council concurrence is not community consent, regulatory approval, finance approval, certification, procurement approval, or Board approval. Public claims must be precise.
48.3.8 The doctrine is direct:
Helix Concurrence records cross-societal legitimacy input; it strengthens governance by surfacing convergence and dissent across helix constituencies without substituting for the authorities that belong elsewhere.
48.4 Affected-Community Non-Objection Where Applicable
48.4.1 Affected-Community Non-Objection is a recorded governance condition used only where appropriate and lawful to determine whether affected communities have raised material objection to a defined governance step after adequate notice, accessible information, protected participation, grievance routes, and sufficient time to respond. It is not universal consent and must not be used as a shortcut around consent requirements.
48.4.2 Non-objection may be useful for certain public-safe releases, observatory participation models, local evidence use, low-risk pilot stages, monitoring arrangements, public-safe summaries, or bounded procedural steps where formal community consent is not legally or ethically required but community objection would be material to legitimacy and safeguards.
48.4.3 Non-objection must never be used where law, Indigenous rights, community protocol, land rights, protected knowledge rules, ethics requirements, or governing doctrine requires consent, approval, permission, free prior and informed consent, or another stronger standard. Non-objection is a lower and narrower condition than consent.
48.4.4 Affected-Community Non-Objection requires adequate process. The affected community or communities must receive understandable information about the proposed step, what it does and does not do, what data or knowledge is involved, what public claims may be made, what risks exist, how to object, how objection will be treated, what language and accessibility support exists, and what correction route applies.
48.4.5 Non-objection must be time-bound and scope-bound. Non-objection to a public-safe summary does not mean non-objection to project execution. Non-objection to monitoring does not mean consent to data sharing. Non-objection to evidence use does not mean support for finance-readiness. Each record must state scope.
48.4.6 Silence must be treated carefully. Silence may reflect agreement, lack of awareness, fear, exclusion, language barrier, consultation fatigue, power imbalance, or lack of access. Non-objection should not be inferred from silence unless the process is designed to make objection safe, accessible, and realistic.
48.4.7 Non-objection records must preserve objections, conditions, and dissent. If an affected community or subgroup objects, the record must identify the objection safely and state whether the matter is held, re-scoped, deferred, escalated, or proceeds with conditions. Vulnerable or protected participants may require confidential handling.
48.4.8 The doctrine is direct:
Affected-Community Non-Objection may support bounded governance steps only where applicable; it is never a substitute for consent, never inferred from unsafe silence, and always limited by scope, safeguards, and correction.
48.5 Safeguards Clearance
48.5.1 Safeguards Clearance is the recorded determination by the competent safeguards function that a matter has satisfied the safeguards requirements applicable to a defined stage, scope, publication class, community process, data use, technical review, public-safe release, routeability step, or handoff. It is a protective governance condition, not a general approval.
48.5.2 Safeguards Clearance may be required before public-safe publication, community-sensitive record use, protected knowledge handling, AI processing of sensitive records, public authority-sensitive release, routeability involving affected communities, controlled-room access, public-safe mapping, downstream handoff, or any matter involving vulnerable participants or potential harm.
48.5.3 Safeguards Clearance must be stage-specific. Clearance for internal review does not mean clearance for public publication. Clearance for public-safe summary does not mean clearance for raw data release. Clearance for a meeting does not mean clearance for routeability. Clearance for observability does not mean clearance for execution.
48.5.4 A Safeguards Clearance Record should identify the Case ID, matter, stage, applicable safeguards profile, affected groups, protected knowledge issues, privacy issues, accessibility measures, participation status, dissent, grievance route, non-retaliation measures, publication class, conditions, prohibited claims, review date, and correction triggers.
48.5.5 Safeguards Clearance may be conditional, withheld, deferred, or revoked. A conditional clearance may require redaction, public-safe summary, access restriction, community review, language support, no-AI-processing, no-mapping, non-retaliation measures, or grievance route activation. Withholding clearance may require a hold.
48.5.6 Safeguards Clearance must not be overridden by ordinary convenience, finance pressure, technical urgency, sponsor preference, platform design, or majority vote unless the governing instrument creates a lawful review mechanism and the safeguards record supports such review. Safeguards are not optional finishing touches.
48.5.7 Safeguards Clearance must remain correctable. If harm emerges, protected knowledge is exposed, community objections arise, participation was misrepresented, or data use exceeds permission, clearance may be suspended, narrowed, withdrawn, or re-reviewed.
48.5.8 The doctrine is direct:
Safeguards Clearance confirms only that defined safeguards conditions have been met for a defined step; it protects people, communities, knowledge, dignity, and trust without becoming a universal authorization.
48.6 Public Authority Capacity Clearance
48.6.1 Public Authority Capacity Clearance is the recorded determination that the role, mandate, status, and public-reference permission of a public authority or public actor have been properly classified for a specific matter. It prevents public authority participation from being misrepresented as approval, endorsement, funding, procurement, regulation, emergency action, or legal authorization.
48.6.2 Public Authority Capacity Clearance may be required before any record, meeting output, public-safe summary, proof pack, maturity record, routeability note, dashboard, publication, or handoff refers to a public authority, public official, regulator, municipality, public finance body, procurement authority, emergency authority, public agency, or Indigenous government where applicable.
48.6.3 Capacity categories may include observer, learner, data provider, technical contributor, policy participant, regulator, procurer, public finance actor, emergency authority, host, implementation body, lawful decision-maker, public communicator, or no public authority role. The category must be specific and supported by record.
48.6.4 A Public Authority Capacity Clearance Record should identify the public actor, office or body, jurisdiction, capacity, lawful mandate if relevant, source of capacity information, public-reference permission, quotation permission where applicable, decision or non-decision status, limitations, expiration or review date, and correction route.
48.6.5 Capacity Clearance must distinguish institutional participation from individual participation. A public official speaking in a personal, technical, informal, or exploratory capacity does not necessarily bind the public authority. The record must state whether the person had authority to speak for the body.
48.6.6 Capacity Clearance must be updated when circumstances change. Officials change, mandates shift, processes advance, decisions are issued, approvals expire, public statements are withdrawn, or public authority procedures become active. Stale capacity records are high-risk.
48.6.7 Public Authority Capacity Clearance must be reflected in claims language. Public-facing outputs should say “observed,” “participated in a technical session,” “provided data,” “reviewed under its mandate,” or “approved under X authority,” only where the record supports that language.
48.6.8 The doctrine is direct:
Public Authority Capacity Clearance protects lawful authority by ensuring that public-sector participation is described exactly as recorded and never inflated into public approval or government backing.
48.7 Technical Release Gate
48.7.1 A Technical Release Gate is the formal review point through which a technical artifact, dashboard, software release, model integration, sensor output, digital twin scenario, data pipeline, technical baseline, API, proof-pack annex, public-safe technical statement, or technical finding is cleared, conditioned, held, rejected, or withdrawn for a defined use. It is a technical authority procedure, not a public authority approval.
48.7.2 Technical Release Gates are appropriate where technical outputs may affect evidence quality, public-safe reporting, maturity, routeability, dashboards, public authority learning, community protection, cyber security, platform operation, or downstream reliance. They prevent technically incomplete artifacts from acquiring governance meaning.
48.7.3 A Technical Release Gate should identify the artifact, version, configuration, intended use, technical baseline, standards applied, test results, security review, data review, model review where applicable, SBOM or dependency review where applicable, safeguards implications, publication class, rollback plan, monitoring requirement, and correction path.
48.7.4 Gate outcomes may include pass, conditional pass, hold, fail, defer, suspend, withdraw, re-scope, or re-enter after correction. Each outcome must state effect and non-effect. A technical pass does not mean public-safe release unless the publication gate is also satisfied. A technical pass does not mean certification, procurement approval, public authority approval, or endorsement.
48.7.5 Technical Release Gates should be governed by the relevant TMD, technical function, data/AI/cyber function, safeguards function, platform function, and records function according to the artifact. High-consequence artifacts require stronger review than low-risk internal tools.
48.7.6 Technical Release Gates must include AI controls where machine outputs are involved. Model register status, inference record requirements, data eligibility, human review gate, prohibited uses, monitoring, and correction obligations must be established before release.
48.7.7 Technical Release Gates must be auditable. The release record should show who reviewed, what evidence was reviewed, what tests passed, what risks remain, what conditions apply, what version was released, and how rollback or correction will occur.
48.7.8 The doctrine is direct:
A Technical Release Gate authorizes a technical artifact for a defined governance use within technical scope; it never becomes certification, public authority approval, procurement preference, or universal safety claim.
48.8 Supermajority
48.8.1 A Supermajority is a heightened voting threshold required for matters of exceptional institutional, constitutional, public-good, financial, structural, reputational, technological, safeguards, or authority significance. It protects the Rail from major changes being made by narrow transient majorities where broader institutional agreement is required.
48.8.2 Supermajority may be appropriate for bylaw amendments, constitutional instruments, mission-lock changes, dissolution or structural transformation, major reserved delegations, significant changes to role separation, adoption of major standards, approval of high-risk public-facing doctrine, entry into major long-term obligations, removal of key governance officers where applicable, or matters designated by governing instruments.
48.8.3 Supermajority requirements must be defined in advance. The record should identify the applicable threshold, eligible voting body, quorum, notice requirement, whether abstentions count, whether class approval is also required, whether member approval is required, and whether any statutory requirement applies.
48.8.4 Supermajority is not a substitute for other clearances. A supermajority Board or member vote cannot override safeguards clearance, public authority approval, community consent requirements, legal obligations, protected knowledge controls, data sovereignty rules, or technical release gates where those are separately required.
48.8.5 Supermajority should not be used to freeze ordinary governance. Requiring supermajority for too many matters can create paralysis, empower blockers, and prevent correction. The threshold should be reserved for matters whose consequence justifies heightened agreement.
48.8.6 Supermajority records must preserve dissent. A supermajority outcome may still have significant minority objection. The record should capture dissent, conditions, and minority concerns because they may become relevant to correction, implementation, or legitimacy.
48.8.7 Supermajority approvals should include review and correction conditions where the matter is dynamic. A major standard, platform rule, or governance structure approved by supermajority may still require review after implementation. Supermajority does not eliminate drift.
48.8.8 The doctrine is direct:
Supermajority protects the Rail from narrow control over high-consequence matters, while remaining bounded by law, safeguards, public authority, community rights, technical gates, and correction.
48.9 Class Approval
48.9.1 Class Approval is the requirement that a defined class of members, participants, council category, stakeholder group, community group, regional body, national body, institutional category, or rights-bearing group approve or concur in a matter before it can proceed. It is used where a decision affects that class distinctly or where governance legitimacy requires class-specific protection.
48.9.2 Class Approval may be appropriate where membership classes have legal rights, where regions are affected differently, where national bodies must approve adoption within their jurisdiction, where a community or Indigenous authority has distinct rights, where a council family has defined authority, where funder or sponsor class limitations must be protected, or where constitutional instruments require class consent.
48.9.3 Class Approval must be expressly defined. The class, eligibility, scope, threshold, notice, procedure, authority effect, dissent treatment, and correction route must be recorded. A vague claim that “the class agreed” is insufficient.
48.9.4 Class Approval must not be confused with consultation. A class may be consulted without having approval rights. A class may have concurrence rights but not veto rights. A class may have non-objection rights for a limited step. A class may have consent rights under law or protocol. The governing record must identify the exact right.
48.9.5 Class Approval must protect against class capture. A small leadership group may not legitimately approve for a class unless it has authority. A dominant institution may not speak for all members of a class where the class is diverse. Representation, conflicts, dissent, and authority must be recorded.
48.9.6 Class Approval may coexist with Board Vote, Member Vote, Helix Concurrence, safeguards clearance, public authority capacity clearance, or technical release gate. Complex matters may require multiple approval surfaces. The record must show which conditions are cumulative and which are advisory.
48.9.7 Class Approval records must state non-effect. Approval by one class does not imply approval by another class, public authority approval, community consent, finance-readiness, technical verification, or execution authorization unless separately recorded.
48.9.8 The doctrine is direct:
Class Approval protects distinct governance interests by requiring the affected or rights-bearing class to approve where its own authority is engaged, while preventing class voice from being generalized beyond its record.
48.10 Recorded Dissent With Bounded Approval
48.10.1 Recorded Dissent With Bounded Approval is a decision outcome in which a competent body approves, recommends, releases, recognizes, routes, or otherwise authorizes a defined step while preserving unresolved dissent, limitations, objections, uncertainty, or safeguards concerns in the record and bounding the approval accordingly.
48.10.2 This outcome is necessary because not every dissent blocks action. A body may responsibly proceed where dissent is understood, non-fatal, limited, conditioned, or addressed through monitoring and correction. But proceeding without recording dissent creates false consensus. Bounded approval allows movement without erasure.
48.10.3 Bounded approval must state what is approved, what is not approved, what dissent remains, why the body proceeded, what conditions apply, what monitoring is required, what public claims are permitted, what public claims are prohibited, and what correction trigger will reopen the matter.
48.10.4 Recorded dissent with bounded approval may be appropriate where a technical minority view remains but the risk is managed; where community concerns require monitoring but do not block a public-safe summary; where public authority capacity is limited but sufficient for a narrow interface; where routeability may proceed only for controlled review; or where safeguards permit a narrow release subject to conditions.
48.10.5 Bounded approval must not be used to override fatal dissent. If dissent identifies unresolved protected knowledge exposure, lack of required consent, unlawful public authority substitution, serious technical defect, major safety risk, or finance overclaim, the matter may need hold, deferral, withdrawal, or rejection. Bounded approval is not a loophole.
48.10.6 Bounded approval must shape public claims. Public-facing language must not say “approved” without the bounds where the bounds are material. It may need to say “approved for internal review only,” “released as public-safe summary only,” “routeable for controlled diligence only,” or “approved subject to unresolved dissent and monitoring,” depending on the matter.
48.10.7 Bounded approval must be monitored. If the conditions fail, dissent becomes validated, evidence changes, or harm emerges, the approval must be reviewed, corrected, limited, suspended, or withdrawn.
48.10.8 The doctrine is direct:
Recorded Dissent With Bounded Approval allows the Rail to proceed honestly where action is justified despite unresolved dissent, provided the approval is narrowed, conditions are recorded, and correction remains active.
48.11 Voting Procedure Selection by Matter Class
48.11.1 Voting Procedure Selection by Matter Class is the rule that the decision method must be chosen according to the nature of the matter, the authority implicated, the governing instrument, the affected rights, the required expertise, the safeguards profile, the public authority relationship, and the consequence of the decision. The Rail does not use one voting procedure for all matters.
48.11.2 A matter-class analysis should identify whether the matter is constitutional, fiduciary, operational, technical, safeguards-related, public authority-related, community-related, routeability-related, publication-related, data/AI/cyber-related, finance-sensitive, emergency, incident, correction, or downstream handoff. The analysis then identifies the competent decision body and procedure.
48.11.3 Constitutional and reserved matters may require Member Vote, Board Vote, supermajority, class approval, or statutory procedure. Fiduciary matters normally require Board procedure. Operational matters may be delegated. Technical matters may require TMD release gate. Safeguards matters may require safeguards clearance. Routeability matters may require GRA determination. Public authority matters require capacity clearance and, where applicable, public authority action. Community matters may require non-objection, consent, or protected process depending on context.
48.11.4 Procedure selection should occur before deliberation where possible. Participants should know the decision path before they discuss the matter. If the procedure changes because the matter is reclassified, the record must explain why.
48.11.5 Procedure selection must prevent authority shopping. Actors must not choose a voting body because it is more likely to approve, bypass safeguards, avoid public authority clarification, avoid community objection, or produce faster routeability. The matter determines procedure; preference does not.
48.11.6 Procedure selection must include escalation. If a delegated body encounters a reserved matter, it must escalate. If a council encounters technical authority, it must refer to TMD. If a routeability review reveals public authority ambiguity, it must seek capacity clearance. If a community process reveals consent requirements, non-objection is insufficient.
48.11.7 Procedure selection must be recorded in the Decision Pack and Decision Record. A later reviewer should be able to see why the chosen procedure was valid.
48.11.8 The doctrine is direct:
Voting procedure must follow matter class, not convenience; each decision must be routed to the body and threshold competent to decide it without bypassing safeguards, public authority, community rights, or technical gates.
48.12 Voting Records
48.12.1 Voting Records are the official records documenting the procedure, participants, authority, materials, votes, thresholds, recusals, dissent, conditions, and outcomes of any formal vote within the Nexus Rail. They are the evidence that a vote occurred validly and within scope.
48.12.2 A Voting Record should identify the Case ID, matter class, voting body, authority basis, notice, meeting or written procedure, quorum, eligible voters, ineligible participants, conflicts, recusals, motion text, amendments, materials reviewed, voting threshold, votes in favour, votes against, abstentions, non-votes, outcome, conditions, dissent, effective date, implementation authority, public claims limits, and correction path.
48.12.3 Voting Records must distinguish voting participants from non-voting participants. Observers, public authorities, community participants, experts, finance readers, staff, sponsors, providers, or guests may attend without voting authority. The record must prevent their attendance from being counted as approval.
48.12.4 Voting Records must identify conflicts and recusals. A vote may be invalid, challengeable, or require correction if conflicted actors participated improperly. Recused actors may receive limited information or be excluded from deliberation depending on the matter.
48.12.5 Voting Records must preserve dissent and minority views where material. A passed vote does not erase objections. Minority concerns may shape conditions, public claims, monitoring, correction triggers, or future review.
48.12.6 Voting Records must state the effect and non-effect of the vote. A Board vote approving a public-safe report does not approve execution. A Member Vote approving a bylaw does not grant public authority. A Helix vote or concurrence does not create community consent. A technical release vote does not create certification. The record must prevent overclaim.
48.12.7 Voting Records must be publication-classified. Some voting outcomes may be public. Some may be public-safe. Some may be controlled, public authority sensitive, finance-sensitive, community-sensitive, restricted, or security-sensitive. Transparency must match law, safeguards, and reliance.
48.12.8 Voting Records must be correctionable. If notice was defective, quorum miscalculated, conflict undisclosed, authority misstated, vote counted incorrectly, procedure invalid, or public claim overstated, the Voting Record must support correction, ratification where lawful, re-vote, withdrawal, or supersession.
48.12.9 The final doctrine of this chapter is direct:
Voting and authority procedures give formal decision power its proper place in Planetary Nexus Governance. Votes matter when the right body votes on the right matter under the right rule, but no vote can exceed law, evidence, safeguards, public authority, community rights, technical limits, or the record that gives the vote meaning.
Last updated
Was this helpful?