From 32921ded5771f10e0d9cd050fdee65c91f538047 Mon Sep 17 00:00:00 2001
From: Bob Walker <bob.walker@octopus.com>
Date: Thu, 27 Aug 2026 10:49:10 -0500
Subject: [PATCH 1/2] Simplifying the sync instances page and removing the
 instance per environment from enterprise patterns

---
 .../multiple-environments.png                 | Bin 34123 -> 0 bytes
 .../administration/sync-instances/index.md    | 520 +++---------------
 .../enterprise-patterns.md                    |  24 +-
 3 files changed, 77 insertions(+), 467 deletions(-)
 delete mode 100644 public/docs/img/platform-engineering/multiple-environments.png

diff --git a/public/docs/img/platform-engineering/multiple-environments.png b/public/docs/img/platform-engineering/multiple-environments.png
deleted file mode 100644
index 2dece8b0ba140992e79b52641b9009f73f816ca3..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 34123
zcmeFZcT`jD*EXn#prWFJqDWIzM4B{_4k{oWrFW%DjdTJeh=`~NNN*BQdhdjqpr~|0
zO{fV{0wF+v5K2PeJ3Q}t*L*YU{jHh#Z`PWJwK%}Z$;o~8z4x`Reck)!qk*2rxig$+
zjvYI8PV?!L=f{qnoIQ5z_}f!Vz?sj#YJ!0uj6RPvjZOhyA*UQZ96QE$O!JAVQJ~Gr
zG;=Du+C<w%%31AxS%I!=Pi|>G7w;H0JbP77-1%8=s*l3uxdLZ(cJ>QrpIp2ZKL6Ff
z%cbjY2|Oi@@G--wzQFmw52duY?Q3dEcO6@XHaBU#dv}cC6yKYF5C7WWUqARa4E}|J
z|5r$;qIYt0VN0bT*6m;=eoikXjLd)JL$}J?-ZFDG*T?$Wmkd-iSB>741cGaZ=Qx$p
z;vobaD0p|k(kj)b8|rLPS?=f5AQx4R9cR4oKOH)?k27q5i~1V>$5)Tu5wG_~C1gli
z_OkkazDL+wFu2+bMl30D{Vfr^`OlS4Ux#Tcn`g{O`<hagFw>(piC2Ize2@W#x$AoI
z=)kHK4m?hSF5fe%pZc%n)eH^re;laQZ52MOai7}D|9HjJ9pDNN5%quX@n19juRZ?H
z{{F8${<X)y`0?KuZgtyWz&J0jvYfqPyI9C^XU+O$4@}HfNzk(Vt5KnWs_RIhU@L7q
zK|Pu?avE30TWVdSzJ?$_kcI9yBnn#Uy@%{pS(ZF%{0ELNnZ1~%`gvnK;AV7V&!NjF
z%9F|cNIn_!hFLR|UyKc^WuKbyeAuez%YS8=*A_E*9IyoC0=<uBpBYYWYInuw<*E0j
z50yiLW$9Z7&kJ9F`_R#_&_3Pl-xcb~bvN=nPkefvYmZPxYh2Fv*lYBJv%w^5;+Uv)
zb5~}-bV5$Z!&5+VF#vK|2&<jw7Z^fdR(4B0lveM7Mh)H8o`>6ZXwTizoreXl!5Owb
z#t-eRl9{9>BsCM|3|ard%bn9JaEfW8ARXHpM?0LF=hp8CqWZSNp2=VOFY3C%2i#U>
z*p5pvNXLI|>Lpz`RaqZ;O;Vl7CN!tkbNJ4%{Tw7RJo3DSYM^egKdIl#YbU=TI93;z
z(dZJR|10bi-xqcU9o+=>z7>R)sCn(v_X_*j?&B@LArbm*mq6IBcXC1xx~S$gPJRsN
zFZXU7<@!LzPnU)6$Ti8sivl+;HTK=S(;+5-xe8PAAi?GX%`TjI9?oXp@wr~u36*}$
zm81TjH{D8W%h$cWP$a;UbWJi}z`T#GrpbzY%c=RfPyoyQo7m~q#ik+UjgjG@T5}(y
zH%T(5!`~ez%5tSwMt?>l_(W?_#)B?-5b{Q>!uC7ja@wntu<gaHO+p8+#i$&;_rN>z
z+HKWGN1pUlCoEmstxKjo^pv?Qw`{=Z<-_<B%;(LrSa~)-)Ot)R%_BCNynd~N9Pv2G
z(%B?IOLe(`wM!Lh(JqbXGD{&6k{0849^#19o%9!1<W2jB-#ip}O+bpKM2XQ&4UTWw
zgtWh>Z0>x%wmHYzzOeqS9j!z{kn6wtK4+8k(Cx~$9|M?AIe2Q=BvA^?c=ckIf(JK;
zw20Z=Kty9=B72cd&igHS`dRSyUdp_~<hhNOMjwZ++23Bz{Lh5_!^TvqS(dD-Po804
zmtYsZFjXPYe37E@Pnhsw86QnYx?Q8#w7hIr_a0w3tY7=BNNy)hRaqnG_>#a9rUg~t
zN-Hsdc~Epy%`OkbgbsMXwTqtTwO*#}6~uis)^t7MIRAV3r^0o5q};kgxElHm{v=dV
zQJ1UkyqfB<uqPM!E@a&mNmHTRHK{H9I*3HV)mb=%pJq=yyZnFUZnOH?jy-7XqrANQ
z?!WvRvlU+wkNp32)v>TZ4jG%99Iaq-GIp78W=$@DTQG>BBZj-j#7X14bMNIsW^UQu
z-)8meW7mLpsPN@8jIRy5t48og#{Q{w2d9C{xng#ydo99}i~mgV2eB}%B%!^_uWYH<
z-Fq+MQ|_2TAPm;zTYH!{%gt7Aep^^$-+Z*#|CDr(YV3h2w?^;#eH+@C>u}s&N!uif
z%{kED`&IjquLwS?erHr}_1hw_R3AB<_vGUx)yU<yJ{TJcNK;=Qj{g}<B`oH7(y6L6
z@B=P|Km*UlJ$1L2=DMU78J&A3TS$Y`!LP3<5Bw%E*(j=<=TYEu>`qL2$qTvZ;^HC^
zH1agfak;^x$3)OLzjma^&~&2SO{|r+l@zkK>6lLY79KgDQkAm+s(EN_VNvWp*<^g?
z%DuY_-AO5bqV?keAbD@)4w@Ph-&_mDZTE!kH&lIBPInzG7ZF2J)jP=`Go;NOy{~-K
z!=j>$(ySbf*r!@mv(L*cq-FOK4RcLNi030M$1jR1$~ja9Vm|~@DDb>T5t|a!#jJT$
zk>PC*pW=B`itX}98GkgVOdJ`7RQYs8=!&Qia#cQHHBnsoP?)@kN~#@^B4;~SI1XmN
zd`uY3Njbt5J0)3qzgll1D}c3Oj2vdIK}i&ukcIBc@lID9P#}DI#q+#kDff}5{VSpM
zM!<-)8A?pb6XTRWfAJ$?w3hRYYF@8EhfyhsK&)y-C6|>-J8LCv>v}DAZ6&4HCJH9p
zp=Qq2ncA?^2YuBKYaC|$WE_glj!z3-p_}W`wt<^;S;MDqPNaZ`@}sXWd?%x-pdx0K
z*)8O?`#`?1GLR0)Ad0U}nwFV~X4HaY4hVOi=FmY4TE@BHDE!djicfCH-Wk=7pa&uJ
zQI1VYime$EyPlPir;me5c>QGDo7>r__FR=KQFKF>dQf+oys;-a(us}TFUi%R**t6l
z2R950bR;0njc9R<TVCHzwt95>(85UhP?=?b&ng>OH~bYuqsHik|B=Ve8ocnCa6&%M
zW8Xo>+BCclQ=qQDaO0&<1}#qSd@3hyCp6kxSJ_2yjUiFg>)3j0dD+Dla^BOpo2qpq
zw8xoH|GmuxbSuG2@@c8}LNVT^1=h&(P}}#@*V0@O%LhIB$_IDJ9K9)hc$hgTO30}6
z?&@Sfq9jU5Uda53N0xzT)WM#{pU(%H$)e`M&HkinYS)Ax@o9w(q>u6mH1jg|(L=Ak
z9KSRrk97Bm+QFtsTno5{z0<Z$c*^qU)M3Wv&Kf_rd?wd}^A}4}-^-O*Hvb91sCQ|R
zt+ll$Zvl}kBmVZxP_>^M!J|7b3Z<dNIh?lJL6Y!Wb`UyWX}{=COwV&2b;Zkli}Y2Z
z7zw_zWD$IB6Y?IYCQtoZG>VzCyJv7SyB&uVQ=H$E%BHRi6gccv=Rvc0r~D1-JtprQ
z?$;O~Xxna$lzRC*!^M6mZRxF#NAJm>^B>vDM*oI#E9;d<UHFhCP8S1RK!lkO+?h}f
z6qy>#(J13<$@gXBf=QD>;Jx3AeY!4x9!w*C`@W;*EbI;Y^1-LU@I*oDKNX(aw#nBr
z7GYou-yht;L)XzpY^MgZPUlOyIxyTwu@+acs9m>aUy)`NyqUMv`h)-0mLOdo)OrJX
zxb4>YIDmUXuvw>B#9}Kpghs(g1a@AiQ8AeNLd!3pVc!Aqk*6TJ<wgAQPO&dbMt{q>
zx^WNDZgpze?s42u#T+zl2N#O@yt2bfU#uD+JuXPlk5h$XuWbI+_eA)_b^mrgDxSZe
z;Sz^T((vEPw`;;&_F#%8yh?u<mr&BIMimX4#ckI6(9p$I8MVV0=6uCqe@h7BVE?{d
z!{spyUpf5-v{0!BrcZ^<D2c2q$kG)j=;of(Z8~1$aqtDDN<EF<>nE6dqg`JNMc&PV
zY*uk8u<xf$lutEJDL9yWz7@)uUk<}`5el-drAAO_h*pGKl(l?7_kaLzifoPZ-fFY^
z_@%)t&3q7Y?fv1?SXe<sZ%>UEfODHG!;izu{d{M_4tg^sEuoxyIa6M!*5|{F_!EXw
z$eb`RS^h{XxC8ux4~!~deZ-O$S+ngx()LrC{6LEAan6FSz+)FdyPpZe3wtRx+tB=-
zkG!F~VVB>r>P&<##cpqKF17wu4)2{^|10o%Aoy>JO`u*as=A=g4gKL@NxCD{lZQPp
zJ(bS0WEZ-$B1>rUb5jf5f*MvBmLvSL=TW?f7%-%-#$(b%XuHy3W0tRg-+Sznp}RDs
z_|IKm6)c;+BAZj2{gyqa+z0Qm;KL*@<mc1(GCKTvQ91KJqr{T5MO%em@lIFz5-x%J
zt%P0)|AZ-cy&11@>Q1o@xf9L{H7dpwUX);caPz{su=T^`oH%(f-<QW>k0R(<UwI|M
zHrr~QcRa6c&YXa%269tI>OF#8rgA@msW9;&i|{eA*4?i<X%e#cS!7phm9QQOeW!}s
zW=iRAG@Tez1t<z-rUo{H*lfeLvGDbUo)j7W=KT|EWPE>8tkTsh+aq$`tG^esDA?31
zLdkZ~xg<}|R~Zl7)>3dodD;uklJP%adP<EoXB(&%E~67Nk6NH~CiDa1VtSbBqLQm<
z<$<{Vpdvu^W}m}t6kRZga4C-oAo*>!s%3{I$k+sr`Y!*Fp@dySI=_7g;|uX3zYkaB
zoi<etUii)Ng!leCZTmm_!a=I`phXGCo|6j{Ol=YV?{7m@T;!{e#h*#htN-QOEq0#E
zE2@F3s9M{>!51*7?umB(_n`v3XM@Fr+jsCj!50wqVEIyQj3>H%7|0st{EgBsNaa}?
z$zkr#IVd<Y7<<wLXWXcDnY1lxtw-5*q4%HSet6z8n+y77@<134X^y$lyqxY<Cc~^y
z^rS1^d%+lEb_HV-&?^1?{(TY4>R;F2iCN`V`Xx*>=~}vs7boFPNuB%jDq9WoSyG!n
zl<V)gpKdVYUdxLx{}KB-5geH4=f-H&kb69<g9kh&cB%ryBiGc&^9x|hbqWWa7X~jT
zh6!5W2HQgRxR01n!kdH4k%Qp`Io~Drs@<l;#lxMCb^6C4J-UbQC$S340aOCC14+RX
z0Vg>3$W)3Rjm3-~+7P9~vCNU$LcLFeT082P|5C6>3(7K<c;;OF^4`~{atv59J_Y@(
zLY@J~fQh{Ljp<5YH}RJ=3PGpox;v(&=#UbwOMALccM!7`TTRw)LB=+oy>okjf)0Lg
zd1X_P0q0m%4WuKMcK-124!&q@IwaK`vbg#~8nQ9RV0<l5Tff(NXkBNu^<If=@rWC&
zimzHn^&jz>Fns<Hn<Tu4*Wz0z1Qa$7Af)-HDSm>w69g<6(`wR&N$|DVt3d8%edeU(
zfE@{`A-e~`L;X6&_F0H0;m0QSK;zYF+v(51l6}L|dUtlYQn&Ikk`~$pRkFXQ8am`$
z3?6}0g3}1jqO_gM*k>fm-YuziY_Nt?x{H$(!EM|5>!7Wk1S>DYaAH?NY21r+sr7@l
znaFT;Fp=n~oW>GnWG}mfo}^b7y5@h8U7RA9ddQ{g7(O1p7F@r#8ZyhlE$ua@3-2^z
z+gfv0Zzr4!dNIU&3Z*PRQjGg^?s{npg;M`ibJCC)NRO5Q+nOr85WTV$ydHk-<2RcO
znS!oP-q8E{KgG^>Ysp)4cP(miGB)|oP_PBl!8)`<=~ex`_3)k27YE|Qal8+F@DpNp
zayBwq?p?hO)SF?9R|YP+QQ^i3+sJUwMq|CTso%lvIs9<~`v(~<Aaz;7<Do$(DL?qy
z^kak|W$pv1EMzNxdo6g4HE39umiUqFpwiPlID??aDfMbepaejAVX2Br;>hiEy|p1V
zxs1(u$8L|%<Vi$pYTBi>6`y{#a}J-mB`1o5%zbJg<!O)jo;Pi#yE&k+ifCyAQ}VG}
zuhThJQGUMPnVf1xLg@<}ZVn;2xmT!Kdn%I4t(n*EW_y(2J_59?E3zG1m(MzKofxb0
z;xMiQb}DT&lEf-$cw+^wG(4Db*tlmx5;~m760>RPJcB3J*@W%yy+w0>!Usq>93TGx
zR35*=R2q&u)B21guFJS50_9+aOgEwi%Z|xa9b*w|l(Osc>oz&}YME}nv!+-^0LXa#
zdDo%1;UHe3CO}AQsKNS2B_AHPdP&eN-+nar1WY|uW?~DWmw?}Z3mVeSbGLQ`9?TId
zkhR!bm|PITI&`jYXnboCCa6}+%elQ4S|(GO`E&wKXkQ4m_K%?WryjtuC8E--wYUeY
z%n#f<Pi-EM$f(leC%@&-_|2wk;I7i(V994Ra!tRIsq4rV?`2Qxg0v!krM;!cQGRb5
z@lD&*>uS8vNNpgfdebRzT((y0ds$oyWhw2w!5n{%dQ2rYWSIS7r+&}<UMs^uC!T?Z
zb_%|!UFl?&Qf?@jf+=<THSNTCqik;GM(n$iE0Y&Hla7V$T5Wi}7CyP<)XVlpSrh@*
zp?sZq7VODWXMcUOlMVl|@Nh|FbzqC>H7&-&2{9mu9!A+huMs((parrNdzZFB2<lMr
zCv02fnO{UMJ6J!$z9XS;{}rO(N0rnPwl#9fmn;G;C^V~jJ4I`I(Ma63EY*8H%*EDu
z{_+QmX`P}bsPeJjCUt!_`OUEqPh#$m9fRY6`UvXy_?<SA7tSHSqf40ZI4qJEJOz>p
zWAgLmJV93qRJZKUloWE{gC-JE6%F@aW%7pXUPSKUYIXhk=}msbw4!rYQZXk{8`sk=
zmXWNSDDyr?WnUa4VsBXp<R^6sx5s|SJRUS$T9Hi**Kc(}=ME<;?haf~X5#*q3wq`<
zgd7eV?j!hfd!R9;EIG;>U%e-@WJlp{mGj?j#J<lPRlSHw9o&jN2kxA3p8NRY(o5F+
zysrk-$+aj#G4A7<Vvt#6>xRXjL?#xF-kP_xupfs2iLo>sdv(tan;){$<=lIW1-HKy
z6kUknLLt`U{iX{~aA+mpb6h294pL*Nj@@EMS?lZR5X!>glhEpP&wZ4xdDCL6U7Iml
zF;Rf<rpX{2jgbD~qdz25T`qatDtHLlXL`P2BFLZu)agRS6D!^_Yy{~m4>K+)68f7-
zlEj~NlpgKHRNl=cHt!CP@X{~~z1%R&^ebyzU_82HLsP(fCp%y&s75;7w!+OMRoZmL
zuzmSJ&xZVj^K}8FlIe$E_YKtbb-DWzuV)@-2YA|Z;?hZB0)!J>kP;NE7Kg-75KHSw
zn;9fr7hYF0c<A`&lHRYI>08ZSJFTpYy1}`_=an7ua~tXCj8f(u&V3BAtalk7a1*M^
z7j+~OsonMO2|iA{yBji#<Rd&{yGv0R1&tQ#8eG8IOkg2YaOh}+149BN{TiLWjDPM#
z0>mPnN6}tcBzkdQ4(U;tD^moa?b!(8UR^0VmlVU(b5$@qi@@+;BhhuVctND!sphG^
zljh<eOGqBd=d*t&jOr57_ust$wSRxLe{9>w_ifa*+Niv<e3u6eXF{J;pRv3)xZi&=
zIU09Viauc<U{008mE7SLxqS5<9MhPRcCVjoQ5mB?bkT3ycjZ^7%yhlaV$6r(FMHfq
zBa!p<%27nbw9dtO&8B0vPDR$uF)ukxhGqB_Dt-`mUK)M?KCmy)QXl10JdWde2hXy!
zwZ_QWp9o(c+>dcGF;zNJWv2MDhkF#H=EVsE;+wTn795bV@e;V$Dc*7@6+L7(xwOS1
zdIlOi?z3`|!)7H@1`=`l-7?i`yEbs}CaFSB#QMbrEcsh<A2jxAxqH=^O|^p{lCOo%
zW!x(zEoWRR09Nmq-1)fU#zSi-w^1e^f$?|pzkxV}B@LH?;$z;irfeNIcyYmIC(|wJ
zxXX&bx)LrS3+mjI7WM^}OB{&1@F4;K60^d1=kk*bptchn;^xSHj=+BRK_l8?iD||8
zdzN`xNqKu8Pij%Rd}pjSCmI8<2n#y*xlPL5jWu&0IRD*(GIR2`!eX&WYx+)Yh79Pm
z`MV$rXCOS3O3*+HnaGKJMj$S~;*toz>e-uB@kS;9a!#?vXj1qTn<zn{5|*2Di@{c7
z7=<n;_lZq*Du|#wfpj3+yyz4P#C=;d1JQ%*W>R=TVX>iAPfnsqXZ$l}n6jEzYjh}+
zCv|@YT%yfk&$~Hr0{wla#H5TJQijzPgwxFxc2@V?qx!+vTc1ZB#0hWx&`G*y+!_fw
zEne&uotA@6;FNadA{gCJjslX;{OPfOl279stj}_Lw^N^`8S!1q=5of%@X0XaLE4G|
z$clNbAhbkr2PVgDzPE{xNnzL--3QQq`b4n0MDVsH9LvF6=*(oGrll9{gpSbR&vV7=
zg7hbvWCN$;1Ce;a7bN0|D?R5*kAjcb7bFQgiSKdVoIb4pUkvDLPmqY>HolK@(YI&~
zGHwtak5MUSOijOI8p6dT6xJTO&p{G)_Z(PtL4qZgHJb)B3zIO9lRRS6NJ2)-U<;7>
z3w+tIl-ExZlqFR+eK&IF3xH$lR^tjrSlQ`h+~*+HomvyJ@Uxb8GQ>Hj^ZN!x6>0pY
zi>{c)*M10PYj)jGDZ)9=M(>5*o42F;_BV9<gd*s@3~;qajtMy)a;S7Y=9-~i)n-59
zm2m{bvi$8~SVhhxOCJ9M#Rp}1siRln^>(h$uOPhq$ZB5Cu2@h;(iwG{d`gl}HS19U
z=X5;yjn$%C>(ahYwN>V{lT@po->l|@vo&<#7->tIdT+-P)Pkp572Gazw2|?2M~lnm
zxtZ1!nr(+yn~PeB2K4HN<`?)^gD?;1jw@z0^*zFF2ezv?evx?CHRD?>ih#<xvSEJ!
zX@(-irUMks?g&7dS8wQfB6HG4lTb&hzraaRI%dIpBk%B&>qTEkTxsqWB)GMCoC9+<
zz@0FZ*UC$<xUubk6cFORKWg>@dRv>imU2QlYJn8t&Vqg~r|&fh2`Q{w|BAp5s(!H7
zI269#`+cVg`xWsqbvSV{^?fV7CzV-UR+F~vSjwN%fmq*{H1B_eOXt6Ffdvrys|;?V
ztXOhMWYX)Xyj`(l-ffH~KJmW3$x6>CEeC5|bMyU~eGG+y=t8;GK;Lpn)Lo(`+nqrD
zQAyT<ysld4ox5@7L$V`&<uw6^v}E%@hcMjQa(2!cxJQPo$a~3dVeccsC_QPgM%hB4
zl1uJz=5@^nSDToo*k4{VZz{;6)mH?q9#(dy9q_D@tnvjMn2+LXfdQsg<^4RGUn7>0
zJD&x{t>pU@A;D4=jNV^g@f}cT!!-V+XmGfYhIf1$fAoT`kKvddIU}#%q&Qnx6;S;%
z5hOr~J7cjTmHaNPE~_<E%$?_tgNzzYK7E>8qYTXb7gL5b#ob;_*)vyqEgllG!NYwC
zXPo~k^&ad@K}+$#*g$PI-*gVvoVUSx%UntJ62zrG&94oBl|4|(w9nGYL9jd>;eFcP
z3a;Hv@jUky?|j;56T$uTEk?T=U+R!ws~$>%Z(dO4dtH2)X6U6@`sx|3&m<~YB+tH}
z|Drb;lFMK6XnKV3bX~N-KWSs`kA*z(dzqZ;i->D|t7&ju4%4dG{+^-Jb1wu$$aDHi
z9{2@Ihcd1TzX=4SgyL&?Vgr^N72mQoOWxcp0X?zWQ>eM8oBnXH`Bcf;<iO_!&`|A1
z^U)R^^<(=_oSR)2&g`vXHqsn9l2B1sMDQsnRklt+C-p&R0l+9JnLagQM**RJoQAW3
zT&7Qv+fhW9iY$M&bIXy?X)Db7z@GeKU#375hgiI>Q*Cn0h}LA{J<iWNxqz@B4)K?E
z>x+G&1D=Lg*urgWAbYn-QYvy~w$~*)JjT5p^8%~bA$|RJXz&~5!<AtLet2ld`I9ZW
zX-SWM&B~`Ik^c$DFFFir?mO0zy$~~}u7e#bUZqLHA8!!^-4nR)ti3Wds1rM}a2%PM
z?mR{#fy39SU-FEJ5AYuC6VJO_zy_7sp!aW!5(Lb>B3hmv&_nRJOasU2#X&fZ@Dh`M
zTA@DQL$|pNwaXngb?U+gR5VY=ADtI}8E`+Z0t)!K^x*O*ALFq;m{N1g{z?&a+VG=H
zbV-WXg~JY#2_N*khedjeRjzb_-v{3*P2Kbl2V)6{<Lj7Om(4JOF9j+6u!0}E5|#L*
zTXMu1$9njud9OTpjm=u>w$TuI-k8sZ!=_5#y2fo$PtfT~cbDF$-vOfXi_W%3&hEkR
zTYJ~$GzL?dGiX{8hCpNMEM<rt30oo+b#9nWjBUt`P&%cc4!n{&c>4N>oe}v8>UNcV
z=r+?|zl~;MIdaeqbQnu_8nL%wnl=2C5qV5tNN*VKEc1IAaCh&@f84#3;kRK3=0p?B
z)X4=Siu0`&JP!IZ8D88hktXMW;=v_8Ov{wCQAU-x!CHg21MP1#jjbd+&XV?_U`};?
zcdG}U0js2DJ@d2m1`CIs{l+E4_+^VaSN_ai_fxkRzp}rmG7+H220T3unGV^~R|YEs
zBDDDc)NgrY!_%^1AhbIvJF})iwZNgshCiof@TA3|_?}*x!nmBpiAFg)rNQUolAp>n
zP{Z@3J|X1o369%+o)ACS*g1hK14XV^zMbZHhY4BrsdL;>kR3<*i{QS?_9P2;`CqBp
z?RRXxz;(3B*YGskq|X9dr-!bv6_RZY>()x5c)%x|Vs_=%nmRsDbYFFjZ*ob%QTfcf
z1TJoW^v9Lo5$dyahxz`E;D~gTdtuowu%h>DzYQ@)9LgIfO_Dd|Ie)t*Tt147dtnxJ
z5Ws$j&Uz2a_T<nkg2u{Dj^FYqWfK0`<6!r4PjW<`hO$|`yUQ=sH1(x$Ie3L0Qjj1Y
zdG2S4xec}ha~}gFg>w?vCDy~~(->Ht{RR0m0iyN%UoHbMZ2rtHOM&g7JN|FbVwudZ
zgWP?9<Z}eL4doV@n@QQb#z{L#6LFz5Y4>Y>u+2f`!&^1ZeP^0u7f)E%jwWDfB>8He
z4u7KQ>gVd}n<4oEopapv?&Ge}a&R#t&f-(s;Ng2FrB`dCAXQUzd>#3<%MQ#M3;r9M
zwztclcaprQPJOtXB`srk6+9HnukkJu2_5ZDLeC<@$det*@*I>;@izb~To7QO%7N$p
zTm#t=a3d%s`YpSzE!`sV90=>|i2#_LO@vLItK*Cl635CbD-4T3b*HM$pE)VKT`oVl
zSfE&mlL2}B`aHMPUPxJW`VuC<T`6M0SzIh1uzST--flv|DqRM(qi){-`QF&7)?<QQ
zxsxFc`FS$H_eUM5Z$dh__k(iqr|kf#bU%Kvqw?z+<JNJnxrFqf63P8$(oYkQU+bh6
zdSGkNx!h8)JQlV>Oe>Q)(RQ?|D^U^dWV8Mh!+wMHQ%>}ec4{9<(v7h1_=)S_72nxC
z+-J)S`(pkVeN`u%DY~WkV4c46l9fh8DLekzLcUc3P3M;dOo}-zKg#qJvl=446YH~h
zlF|F({3V8}OMDl2h0Hh43BI0xz5bSCLUZ}lmTd?9W;hAi@%d5Kykfm$iAnzOc^d^I
z(AR!BnmY-~*}~fLW2k@thyw{X!by^b6)i&g%9MuBwA=RQcfUkPUJu?{dU?GS-rsDA
zf+3DU8tmshnnfR$_=VE?Fbil^8H?j!h~pG&%lN>>=^GkY`C6Hty8A95;tXPD|1H?Z
z5x(lD8Vqg9LMRnzPWsNr@|XVhTGiw|v%lMZYR_-~A#%0qU}41vMOJDtud|C#*x53K
za+gAFp@(!+@a_-VLi<Zn4_mC_3gnz^&y^CARVh*T0H`3}BrtGTdl&6&g{DU0D_W`X
zIGm03Rh`2-$h|*qo4o@9eLo4L?&}o@E~9xdr9)-#LLSFFwt1~`)66;l+i4x@`hGOV
zW&_(MbG~M`p;bTQ!K(hC>M>8v!Iep&393K$w?enBciP*sv_nz?>ywIUh6JX^N`Z&S
zunc=@a7O)VE;Rf-TGluEO~-o$ckC;xCB*_La_d|Njnrz1*x#3IB(2H6MaTm+@1NT5
z4lzf-U^VkS3J6~NzQ;SU%2)9L`i%i3n?VG0Hvr+HCx#da_*_8sTSg~%FZ2XU+dwx?
z3PE4+KB@DZwg4}0XgK!Z`^t@cX44B09v(cImsM!}ZMouaWNbs#9(ayj*nOrGid>4<
zZrLNgX*{HD*&~^W^7WvUL)tt)`0t+ce53RGZUJ7%k}2$ph=tZ1o8i{7-w%FP<yR2r
z6-;P)$Gj%nLb<$W5(s(loJY#5XrYH6>2+~fD*^n7<-SJ9BN@=X@!H^x@Y|sWpHH^d
z`f}z_K3lN}djPAh3;C*WCeQ5yXg`?4jGRGCc-{9HREgNzWD&GQysdLeWqP}+$?<W}
zG~?!NZbeL!M{t^~eN%vp^^0<F)RnmNQ9URCEJ69lJ5z1-L6y>chimd6bC&W~l~x)*
zKvMcaia7^$mz=kiCxhyg?~fK)VidCPz7TyKW5Lpb^=<ci-spN+s6u|Nr319XqZr)H
z$}a&kauay?rzP3|sd_@t3BNO0<<VSfRy7qgr&>T8EOOtxmn80onC(8k`J-~D)Nt8#
zy~gvvvKHcZ5SaP14Yt*6-dTS)8hRy)WMwm&MLt^d*E?0~K5C&S?bE3LfCcQ9?w~G0
z)F1a=D3$5k0#$5_Y#X7ru7zpxmIlWw#ughFryt~gFt7A0I9*x3jr~BJ!kM0JxOe|L
zafc~7gukQ~i9DDn(Xlmn)|3&sv4LoClcM=U+DZ*KJ?>*zr~@ILk6AzH37J+qXo6p_
zUl4qGfJ<mfKj~ed)0J8dT22&{2w1annW#-O|Ik{y)KV>{d<d-PK1PIHsJ{5U!E443
zlM%TX`$5m6koDdcQ?pUg5PH@dSni(xu&UbgQj+i1>%T}~p*6?scJ<Lh>m@xE<}p9g
zpy8d=x-qF}KzRPlqo{Q+{Wp@FcIYu)Jx(IkA>y##><joJfhM1xBvTs?#Y9Xl@hc&m
zYWEvky+$0`$?Ng=K^AM$#8-2sk^zzm^lLOpy&8L(oIwZy*7#pghkl^L*EmN@w3XPH
z$C@0Ygsq##nnF=T+OGeqd}mi?b7!q`ftl`J`%e2pL7Z|rN$++E3B%W<cv+a83*WLm
zL0qWPkYJiv#kTfP`<KqLP%{T3Rl?jjUae%e?0tTxA`CQ*@Uj?ho)yZL38L0ckl92}
z;R?O%-NL>Ay*Ckk+8k?v-b<3$f{dmdY%l0RR3szQ-#WHINCu;@3FkfXupV&%-WZIs
z!T$}T9TfR44LpN^*G{^;%!pTm_%0^_Vpp1J_m!aVbvcrSz9H#2#_IZ~UuO)KX5E2e
zy&qj}&L8ET)31<a4gGCA)c<udp;lxo9}uDjX5jwb6Gi8^0v~t!{Pv!^Mn}b82XQ)_
z#42j?J_iOt`A#}u=G~ms--#U!5KZ>G13DsQE@6|NNNs8+^u4Y4R=(zmwr#!^rbQBB
zM~T2|r`06TEBymmag}fTx3o0tYEP}crAL10#^?7X4xY=TMigUGiOD&0N`I#QMacAY
z!qy$@Slharo3%1GBzxwf0i>&2a$VL8ip~e7OV~y@xL3DGu}+5Gv_?!Tke&`HuLyO+
z9i)IuRKnMT?4gs~0brbPuMlTu{>-2NYzq-rusE9G&RzJD^(RIuT$~58|M3eZd2lxd
zZw!(Br?NE(0~TXNgOu@_6CffaRq09HVXIP^DX5VQqy03gaobt*rbwS?g~YEF9tU%u
zCY}CCJl1U4yEm13RN@@a515&>7w#FiI0*HASU=5nZ~>Cz6?W~yH`QIIzKqBgy{I~J
zW&lp8mAXZNsUyXLR)L|o_2M6q@e%ZiKR$2HpAFgXDku%(gXOYvJ#aVUWq(H+s>@IS
z+ND&7Z~ktIna@&S_!0XlzF=)cDwgqi?>$2B_R9I-2lO1<iC%hs#ZyxmA)g(>u-Lq>
z)HjK{F6#2<AXM2jnSdDS)z2~P!^SO?*vf;r(SoL+_UU?SnlSV5WV%4P9H;GxPPwd1
zrox=K=g&WZYpN=^KqyO%Ob$V-UqP*Md8r^jlEI>wlX`VgCiY<gyZ-6As1fOkHAU*K
zA==G2D5qt>H(TzzwP~uDhkBK9xs{r0>fmbt0R?8?3a2;PtN=|hn1``(K#NI9yOyBM
z&7~GOt-n8huv+?T#$F@WG#1&4S;9TzzN>vQ=ML6jn@49Ol#F+B+2^?Kf$<BNAXf<g
zZOVk-s{)EcvkGFJRgb#0DzGZ=Uz<OdrVNU4*PC=#*IP;Q#@m&JfnN;MYlm~oz(O~z
zjw*(!#<8P(_A5u_6ZirQ2J^fuVs&UQ2H)<&-~toAdU_%{_NBT%*IPL8q=OznrjHA{
z9c-fupAB0?EhHK?F-Dtg&l?VG#V*<g#%)O-rxS(?x^TnJsY;<`ekbx-DRs)jO8L=g
z%(an?VPd{^KhOqH3z)!rC6RU{UEK)<bD`E6)vS*xX$oF!#GOk@aeO^1C-B_%a^Hb)
zIwZJ5PoO6OFQ;YOj&1M?UwZUv*>I%A@j~i|Ee*xnX9*JOdrYsbHF9IOZ`{OtJeq@2
zuhGjQc}aOK_SQQQ%`t*b%}!nJ^vqd&*=c<(aS%E}``q;h$pKhyCv}U1JB9^%5BUEY
zI!2~pY&3oo{q#~qt@A8*U@tXRH0I<v%iZ0Nl+CY~1`fIsd{v%F#oL?+B-hfT`?auC
zxIfU1^ArhnPM2<kN?}g)9CZ?LVW3l6e<{nOa0W^cD$QJu_|+%RIOBl?dTLliigm&7
zN$a+z+)s06V~Wi17+z-QT@a}F_+hD4#XEUtFUv!=esOuxZ3GJXb#Y(Mn*3^iz7B(n
z$LY*Ky5~Qd*f#aFcops->s&{Z%cq+%5Ves<%URl&i+N-Hbsp>IuLchH!8@<riOD7&
zmPvueK@T?4bMVcESRLb$V&m&<g(SAkRjB?;Vj3X;3tfbyNx8h0mX5aRSelRsYW<Fp
zkc;Rmx^t?62FRs(Z$L3$%wV^fz%rr!A925iZLKeZyW_61hY9~zYw6ROA$>G;)al2G
zXzNLhrYdt_FTt2=;!*S32ixORKj+E!&}s9~{v-Fgm9FxAi}*J(`i@1^GhP4;0ki&3
z2d)cz7f8qC3ZDFj*DpNf0V<oWVe|<5|9k@gW{(3`oX_^r`X4_4_|UNVqkcXG4_)1V
zp5xzP{C~t6cT*LN{p#~On5-7vk3S5yIx~OhYi5-!1dk|&w>Wy%%<M9<n~lG)VL*Sn
zce~^mJ*c`qWIkxPLSy^y@UKhRw)&;pI@=Qi6#_IFK3_Tk^SHTETKwb^hMaGG?P8Wp
z|JRfM$z}L7fd(uAmv%#s|L8L<M?Uj^bB|Ph?6>z7hv<a!nQ6mvf|Ygy7X<W4V~s3u
zp0%+?*(x7~NW9g|RF|wI16WuE3G0~g@|L4g9=e?R6eqy2MFjus)tr6u2CAsXc{4Uj
z_2`1H{m+gfY4_Si(r0;Rwf`6umjIvF92ziU`%jP9b`7|qzrn}kKR)5DqbIy|PFMOr
zM#Wd)ihqak-*fP<HU4*B`~R0U?xx<N=zMV9=JAbP8LJVnvp&NCbS!HnCFc7PI|-Tc
zS{3I#_}55Vk(2(U<bwc(yOFV6akFYsUAu6bFFzyB$XW~clfJY~g_`srL7~%f!O_JF
z4)c+$Prto2Ka}+AnB(o*?IM@Wk&pz1#?7~$=SSZS-vp}GG?sx1XU|_eYge*u0|IEz
zf*3D!!T==PZW)_|00^??CaJ|0deoAHd~n+G`!sE+9g5$Z8TiW|-{cXwzrEw$NQw?v
zz%SawNoNd6DE1d|pXZiyKlxWWk9SN=BZkMP`0iJk^Ni`z<$`(I`DVAxkuJ?T8Fj)v
zc@uTPS^Eczk4OjB6IqE1_Tv|U>3{v`4RrdnUw>N45q$l#SFz0n0IUMbH{=cr0Ljol
z=d;c-FwU~IBpq5bm@z4A*XDZQU^CKv&CA?UtgHyS-`fzyHP$qV099<}!_)mnl`6*x
zqj?eV{5iePo+zzR0UgV`8u|*IE(Xn?MoNqYg(9o|sYdPryA_vYIOsuJx{9(x6&?M_
zUoWcgi8C%?a&R$Q#6g)n+t^G&S%EAS^kT?UrHqF14O%!Uxn4l}%)L3Zb#vdTU8B7<
zxTb{vgfEfYN@MLDh*e6#kPy<ZLJMS!L`_X#+`i#lO2vl5>`95=)xL^8&tJ5ydYPj@
z?m8@`FJlTttu3TcTUY%%n^Z{UA`ZK$$kG$g3<+DFR{Bjr13t3zd!#N!k)1GI=ZMzt
zgdKHCaGe^ckjI?bB39KE*v6KLHSz;HIL{oN6a7EV2_S&I0x9)g-|mwOP48N3Z53pm
z9)g30IvHn_rw(lD{<{~T#<h?iF3_7UG(B1Wsf2S8m1Rryb>%R1{C>axjIZb9Q?2B?
zcY?RqQZk!|7f5?TxrW5|7g_vfW^SbI?_44&K~DYB*qVI|ur=kQou6)OTI}3MMtvC1
z0_a=Xz|2~&s=3sN0-4HBX!{9Yq6)rU=P~#12d1a225L%hg?k@s7Ms3Lu}d_b^z}mX
zWM+Ub{?Y9=3z3fRPE6B&626h{YFcqOnrIwVE1z|=|D~KAa9hWk+mLSrOu~WCF@PAp
zyO?dudZHcQ0C;pP5&!MA=n(^atKO}9QC^xXV%B&shQp&zms|G11|#+Ba)t#SBS@a#
z-I%*5M352bD?-TP`FVat9*Kx7K(4nQd&Lg$(7j7X8qYW2#1RQV06*uNA$P4qST1~s
zC2e>45sHmVXZq|>*e$C?4W^qKF<cuGTuR<o<FB6bb-|cDe=dP$8LRey_nJ4zt(g0U
zp_TJRx1d<KWr!}4y?zECZr>53MomQ>u}MC_W_<Bhpln-|^vnEfK!9rfIu9%c<^mxx
z2nqxYn!$vBisZTblXS|#`i<;tjpstQqKxPGvPeMJrQhMpuiGWXx_Z^L%T{qp<c35s
zL#+duZPPtJs?K<=M{}Z}@gu!rW9@RelC0W7TbZT6>HCnsc6)0(AFEyMi<kDEf4ZE+
znRHJp@=o-^ELO2pme`(0XJ*yPvRu1NKiqWG>Jh6@=JhmnqoFgK=QB1!JGa!d9p>;N
z@z9xUqY5LNWz&iq9F*ld9@jNs+EcK-5ipD6E-#y7-yf;*2EU9t1NXW!mvfzIXm5YG
zVQz@vp?AepgQh5W-3vK5?q(>X-F#feV*JWI0|Rx$eyx$PrJNo2?tP!In`&n?cl7!k
zwn#OlnH_1*HayZJ4-Wb)8npaZ$DLPA%e>89(1lK&Y`v-QN6<_KTeRoYO*a|$q;oFv
zx!LB7^*TlDE@tpztJi<JhKPyycrjbVmk#0|w>7Y~Q?K<)$iW;l>(hwp+w;SJ*&L^S
zHR5RvkGqovZ|D+DQ`|%qbuFZexD!!7!Xp=m&kPr0T@E{&Mm*x1zy<90j8yKK-W4fJ
zN5@G9)h2s#XE1ShFagx4jb8=HbI=SNuzv{pOPEa0<NdM67&h(!XAq7{nD)ts^wadF
zVUf1IX<=Y*QD0d~M792*b5%fvobkPr+*L9VWWZ!Gu*a+46c_L3lF>T34U)Z^QSY9B
zbM8+zUE{hnJ+YgAcHB{Y3`d@jmvHNnK!!*cBKjD67e%c_v-YJ-)>>zuH?G%usxG3>
z0gznxc0GMNSA(bOa2mw65P?F(x7S}J1Wj%FT`$Y38qU{VyrR3XXX#nX!}LyD-k&5+
z39-bB*%IJAVUHsnn)lp)bQ^CHP{>aH6U<Lz{mWWuxg_NaUY`=%HDWu%9$)i29pG8-
zY@Mx-xq?;M4`fq8lK%KS<|+N*r@zc?7l*DblV4aXP&y}Dd{7Dg_VO_7adj8tFM)%)
zPR99?P64s$n|WIK?-VewR_2yT(^B0eOP*_vCn<_9q09c`ub_YQ)5Jgu;s!wz_@*pm
zVA&LPDYDv+=80@!<xy~2_@>O?LHA(Tt(&iRqd7OJcyuyU1DWNL4Ujw<J`ynDy0cy^
z^dK~I)GvG5vpWD-MFaV+QV96gRPg*}3&3axDerpsuMsKFS9x5?Uc01(mYiwnC{K@@
z`r{k3&bUB8-upDI6yK^hdT;0;R~;L_GL5wL48*G;`9l6aI+<s(poQ-A*B{E>8|Doa
zwT+>PMAmgaT#2%U)@^Pu{?$%ZX^w%ChKd{g^z^Ad2g=@aHDWzK9)BzNJQ&H0IR_aO
zJ7t^u`i4-foti}cqrnzmBn=y4dIv>02_~9W+zGJuuae%xCTL~A&w3tWBD^~sIl5X+
zZSEO&r}P*r%8m&P)U|6quYLN`Eu0B{XkIUR3k5QSc#Q0f%#e1m5N5})({F>HM|kJ;
zE|DjO==1p|1I@J}O9*%4Vg>T{&J7e>!$u=q19;BM-N{lpbJ{@xMV2-3zOJKfG+K;x
z@It?U60oitRluI)nVH@x3z2_HOQ!T8(=K5li=q}nSsBl^Zvno~X8_pT;8qSY-<H+?
zV~5BVabxUW;%Pwt0AQOHy$DqtyJZ6(sOWI(F(?n@c=05p1#XbK$&LQja$~4|y1CCt
zs0eK&Zh!Fg@AO<^a^JpsK;%QCAz<0UB$~4`LB`5HKe#K^5}J@!?f8o~VPUI3b6-6z
z^g&RI^cm{}rWsPxzMX7=8^>UFeg0_v*@}>j=+h2jmC(?+5>j43$M(g7qALHharG->
zw?R<FpR}%Xi&?i%^sf*(9%gx{FDP&IN1AXSnAiO|vu`_!v^DUQdlX8^H*yOe{25U;
zNOkrnI4m1<rdI?fr9tsP93@}F>%L{!Blln-2pJ~d<@C_3!O8B!Nn1&VyvyB*Ro#z1
zAymZYrpxTv_8f<-gveeAc<tf$2gCis76{b`>4HvD#==<_U$6>m(k+q}V#1uemMIyI
zZ4rvOHX?^IkI(Ze-L&1mZw?FH(Eu9I=A64{R5_jkkk3%FNmKOe(Q_FtEm!b4TzH=2
z3MSS>yG$-LXC1~Lv`&B*8!)Rmp;;nL$UEm+kS^*yDR<Wn(eKd<H5b_&r>SL|Bdsas
zw0L07zyRSPVA$xBdPvxkhz=cqFd$(c{c(763B%SJQDj@nc<NV&)`LHLHiui<=1Pw@
zzW<*8=2qV6d$^gW)jhd0?Rm0LvB))I(|cI$!0_#gq+xA{l2c1SR)_8k0#vXK-NO`_
zsM#RwzgU6r*%(1r--#5IMr@6Gtg{TnDQ0+1+Ip%aaw_m(T-Cf*JZH`pNxRbM-f3u}
zLZ5qPKfeiW%{5TPnT7;Vm5_0J`cr|?TgwCJ3{xmuV1;c?Qwx~nfmYbdOqY)PQ}-Ap
z!((*p!LKJOwgKdmvy0uU7#JadhxTe0TTp*W9!VSJ*g0j1c!XCSdJ`4Y2?`ZWMD{6c
zrlV6`?9ydorncoi(dmnxTQL)uxng5c0l1Bi`amOIj1rAU;%8y1s)35xn&Hb5TRaTw
zs)6n*e42p$=-1PsisH!KE#k-V@{u#g8Q%hg0e~Ll<&W?PsN%*%BIj?LH$^UXpp~U-
zat}O&vy`?~lJj+B;j|*C>h9~4Ssn~T+IffGq%uGdW%{ewarr*WOB?$uU`no_fO<z{
zkIdAz3kye(vRp++(O>@rCg~FGC?-lNN_q(q7=37T$0tQ(N6$QGp`Q8gYT6ZHgEr0u
zy$edhelSQjOZ^qmuN(IrDO8c_5Xv2-&*WkxX|hiyD^%~yShk)q=_Rr6QE}RB>#0#m
zKRqWJk77`7bI*I>`Al<Y2q3+638^60+=8ioJ9K$~ec5I_vjaf1>=<2+9^{UES=E;b
zRjfzM!%~k}da1QvdTRGVw<gNpV}4v!rc<7E>b9JmqEOMxGEVbx-Q+QbDOg)T!wJg=
zg(Ui`-|wSeE_$*Cw0PP&<~MHS7N_<8u&E0%Cn2;kROZ=~ipd#zsakkboL-l+*Uc~S
z&!6adV8$#tGhu%c(4dJs+NO?-_@1;uf=8c}c%$aY%|$W~^wta28H2qC<+dUt_%D;`
z57vSGfgAL=&9`YxizsvLGBvwZRq7Y!8X!x=10@D9{J4YTfa>$y?KuZf4t@OR$@CC1
z8$oC3K`r%X7d|;3&(Ht3i2i6$zr&0Z@$iT$P#=@-;We%lspcf`Sr?8bbf*#AZ{D`<
zH7W=hB-lx<j>A#C{J>TV>7gp>_(3=`ogt}UI>gi|GEf=UC@>AeDc0{{dy?)YErg5>
znujS_Tbd95dBy3Bk3tf<Kg;fgX3Vm5XZdUS49eWUnJ3F)+LOXxVCM6?ApO`bnmhRB
zDvaQKxm)dEZBnu!H`IC0b%fm<?v=qM=leuyZ=02<VTcIX%Z*RNAr>_2@~nG;ya&_F
zd0nzxZj2uXb~OVe1qL=81WLjA_lkh(I-r#ZSi>8bX;>p4JqWMvITj9`K3DeS+MFhz
z_xwGWmX`TG<C(PIYB`xJ<RXpkU|d)@Ha2PupTHWRGswo$u)N4=hSHOJec#@5cZF+i
ze5Z4e9~$WhpOTdo=y+nAt+D9jRDQ@{@<)yV+V@@r9eVgc+Wy81ItejtVLtijw)JNU
zJ`$TEv=(TsPM0&hB5a;Q<ZFQmlpNal+Hwo7_ZwogBTW!8PZS&#f&WvG>oI+M?hY!!
z8OL*D@ob15{-8$A$aw7iF^1De!WejN=>O5Py}7utF~TV-sI4`46C2N?Q1!tz_dD-H
z-!Yn3)ps@iRn9GQt+s;z8~-?V(bT%g3j*+0vnjUzJ={iDA3VHiQ2j)lFjXI?^A*u4
zcNoZ4iI~~alj!;U8e>%KAWj%-QXQ*42k~jxF*~=EHH4^=k|O^|5wW(~8a2@8BzJJ7
zHNJ2h3-P9@W~L|2=WsB0t(+{;88_|zd7F6KV^Yt}7r`{E=wd%{zL8d>zd+kryIdv@
zWYY^D>Qww`8dQoI{HfidJ`y&zs=W%pHW;Xz7bp4Bv;YI>l<8XM+)&|D;{2qUtntwf
zF*CD09ape3RwpwpFA^=0RLh-lx&9{5T*{=)n)a+Oy?-s}(~_@@tmbXQl?7~Og7CvX
zH^KnO++rH;&`lR`)J|H5Rs^NHxcG)m8@OQBAe*bG;nLXd#CxJy2=9`k!g{2<`i4ia
z4$uRbQ14=6y43+2+Tp%n9q7MgiHkZ2SWeEA_*)U-ZBns)qo-T_h%clcRX8KJDoTN>
z)>-W%<ft0@dU~K@u{S!$`>1U6k&n?)0)kHy@c`u)eH~Ly=(9iA?BxHjC}R6}8g5fp
z>;&B{jdp@_R6o<j?Kz3qq|a^26q-+)tQpJpN1h<tv?(#S=!uYj$0oE!ECsvny0{#e
zuUS^YcZx)QGX0gVX(cdkBJ2eE%@pzqzYfF0&o)#7G)oBW?q90#^(uf6KpCspI3dsD
zs*U7fEmOI6)Zqi5J6oOO9NY$AIFk<&g%6Grq;1A8$j1pOS3VeK8lCTvyfN(jUbsed
zfZA19g+=MPj4RAT(>zwDs?!2e;7Iz7Sp~At1NX!LB(LE1-i#tM+}!{tfB9oFZ3pQb
zsX!Ub>6j0-|I-7o^hZ$7(9}xO8_?g0FY-0w_ZS>|r6jm5_wuvMYZY=lq~4Sbqu*&;
z!bucp?kcA!w``En0c<h&6}u<$t0%CzBx?`a>+ALn{glwAijx9ZY|6)4p?~V>XKdNF
zJLdrDJ9Ywd&rW@dcoDpN0q`(j&&(0Lmm^eUAErVTnO||m*8=dKP*3o&*+{fgTi8Uj
zwp>%##A-<F?`V4OR*HRS=x1yqL07rcT74VqY@gK>5-&S%bq#7BjusTKi=~T~^>#;R
z%u@?&6J-T9N6-3I_0$!)Y;F{ad;jKtywFP0=&I9K5|9&#Q6wZjNZDQ^OiRsA$2!c<
z7kTeKRex<nHg6R-_JnNsfeE3w&Nm%dakd9k`NCe~o+PrT_H_MY{6zPqTFL9*?+m~#
zd$L=avZjpAaGY0eH>puazy<&4q}sn-y@t~WR+sl*P5OZfy-|X37G}8a8*k+~@Y|7j
zYOm=mn4nDv?He{xf#RTtYEhKtf~Y#^Mmsxc+(No6p-0l^;Zc*WG!SQ0N-4zfdo!RO
z`6_mu11z=<xbSd={6<CCKYA8HJ#77=unhXW#9~@o5}npfs=;@EqFkTPHvjCmq><I7
zofRr#ER<NIUh4K{0_NE`uTW%G?;F!?n(uJBkzUO*Pl#25$Jo}omYoe*KIvAzdnQl2
zC*Nc8t$N!LnfjE$%oIjQuR(n|U9*_pMt3Ut8r!<_QQ?q~^87a=Mus$YBY20FFCZH-
zUzp3jA)-U<(iU@HPTx08%Wh>dU_K9d=4xEz&~5n0rq#zFX0ei0SO`gD`HIeqP}rCV
zNNyCMta3svIHwCd`#ufL=2}REZdi<m&U~?g>`V@|c<I)(#?Om=v3)-5-~CmsWFh<7
zN1NQIH;9KhnI`4a!j=IJpL;QJ8=PN4_eU%8UQQQ3N4RUszUZzCYBw2gnudG+K%$8E
zqL)pg{GWBQ0`@xv<Q_dF&vwtn9M&a_J)?I0ks<?VI|a5VVkjVZfkpcFrtY<U2!z*v
zZC^m2e1YW+f!BIW4OqsXh&*rp!v)ybYVhOj=8SPlk7NDCEm=Wogkp174#svN(?Xp*
zaFHZ;IU2&rX+1`HPe#RmJ8Tr4XMl0G9M1d=&I2pr?9zf-Vrt>cfBle)o{cto9@94+
zyg-e+A*BD+-ggExwQP+lVnL5o1?fmts)B$Z&4UP`9;HcFI?|-~CMwc}P=ruK+My)^
zQe%Q5y+uL^HAt6c3=l#I;oHG`?)AK<-~0L6;Sa;i?3uOJUVUaSe9!&{8%+`1NUL};
zxkS$YrpndR#z6z5S?-S2l`ksRIwm!HK8$K(*yu`^$bCm1skvKi8h{IxZzpx&rRJk5
zrRHFA-Q}NyqKpXhT^k`A)#^RhAlzH46WU1sSzoz^c-&MMgOpB!E=($*&3Y$@tm#f~
z*&SrrMC*wQ>+4)F8KHdk+L3)Il3$TGN0k9@bI+cGQsczd@X&!Nn@V+DQ*YuD1FeI+
zj{*hP{(P#%td*1<M2tDHqTuy*v39#vU$Q8;6O_YN9(s@$GzWVcI|rW<G#zMk8L2YV
ze916tC}Q*?L5ICtAVgOxe^_h2_T?~s(OXfivG(D`DYDGXqTT~_8MjGsAVZK;Rj8>c
zEydVmHg1H*&C%X1e1|i9`-hOYacN30>C3*P9hQm}-+pf6+kLQfDe~Sl@7)UPfTezD
zeAYNZtHqP(h#5Qmg>G+J$i%g%6(r?;<XlJkl=cTEg~v(;tRrbs5odONl3Bf^7Ce=!
z9oYNt2iuoe@7!IVeX}<o#N^Mt-!4k=c3j3Q)xEjkx9trA4{}`R%du;7Wl8!7lho^Y
z9PbqzW2+Rl>Qk6Rt9})BSZD|){xPQsw0ZHpztr*GxQ1?ipKkF{q=-dV`sIt#rD=7{
z$%q-!R|b}pv!ZlOeBt5nLmz%}|7>5#(h|nYT?5F;(JKQM3sCwSuHHrbn=6##Fh80(
zFJq68LRa!C;}q$f{f4peP|Qjx2m7OJtDWU0f~|SFEbMfh!<5nzKKDk&z>?#Zva-Jj
zOn0p#!00!&89yv3m)5I*qf*HUF;CuTU~yAa7%t{NxPI>XwMD9?yA>{1BxtpkM9_t~
z<phzb@8tpGoWERonh)eXXRCTC0EzE)-JNiuSkYs#7C^*t6-iC$j>hX0G3NmRifTzq
zD7*eZ3-+bdE&4Y)M9v2iN{1z2fMax7;4ye!>Lorvw*fg%6Tl>(GMR!X=~k2Tz=@vW
z<*nH0_m)z;Sa4T*=cqOG>g5X=l(Pg%KDrhlQngOo(ZfeiwE$5;;DpTC<ElrFrk|#N
z?&tJTK(jI|XE(i0SX$UfJLTb>?-iM-lkWm%^)e(|^LyFDKY`~S%ZLsEFtt<PD<8VL
zJEw@x)Nxw>6c*K4n;m4kk-%yByiY7sP~x=o_X<Am3xQW5?s`2Y{yQY6fGjHgB^L@-
zulWJTNAra(*e7Dpb=<CB_&|+;l1ND>DvGUSyb=12=&6>cz^>-kjy?T;mw-nYSn$pR
zekO`%QUHAF^+MDou27{j#oB1gPAe^?^n4eH=vy%#GZ3Ve_xn@p0MqZq5CNa%0zks{
zBdOo7HPAoO05abf{dHrHP=P2e*yT()r10olOU{g)B{<&j(qU;t3aRA)!;4~IKY3W$
ziHDwY1mZC&dJc#m8E*l_cbEz;mYnz(td!~BY5cDiko5;r(J0?MgTHnEIE#iC*!(72
z^27h>;lF0J6a#2(yRc|J{j2AHoce-?64m_!$bZQH4@LgB@rcTYZBe6{^oOmlE=F5{
z9zK6h6QSxQ{+<f3jv9`D_&;&86lUR3Y3efux)?104byM-a(5I^Q9DXJFZ_U0P1FtN
zzF*d@e({9j;=buGk^H-;{YN%bur$C&I{%9`dKhxm<8uxM9t3y`>PCidP>Hbjcp>Ri
zD98TK^8l6en@6YoS3oJxLP3}4sZQN80RZiKWy^x0$p56mIq?t2fm&yu&uSBXcC+ZP
zFAGr2xN>EO@2c>x3k5$+*LVcn)}X<@H=y`dKfNpU-h^_WW7o^~7vq$ARDkyX{|1bR
z$9*|U0e$4<?Dpj1s=;gBRDSQ0U!t1tqAWA*j`?bHMF{h;3+UOEI5h)j=t99vi+?`e
zT#>V$<w*z5U*T`3FZpT!JorKs)RYvexYR@iIt~P|vc1_a@4SCkIV<{0HGRrf7|_%D
zyuLquO^5H6XA$5`FSquj|89}@9QX{zR{N-^9C0>CT&Fbj_%m81ddz&R;k114*cBra
zusg?@o(pe86SUO(>7PRZPV`osOlIG2G&7CyysZjwAzRGcG&2z0)V($E?glk+S?GDj
zx&wbZj72g0bNA;jLHU2?CKPDSaOkhQ0Kg&5KbN!qdc%Ow{og~4h{vG2s3&C$l{W3R
z>zkdD(<qwcMma;YjC(Ta_-T#Q7{dbJ-Z9SwCkIXNZ5<{k*5Fd*aU)lAq4cv2h6&ut
zIb|_ePrRY$JS)qbFdZ$W!1p@EJC~@DGq$88<5I6J0yQlCfw&;CjyX@EpB`vD;|<`4
zQz}x19<xW~in#}GH@aw!pEKB13?g<^8Ft%}TJT0Z<PT=tDKYaRC)R+o@tHe3`|ru-
zC#P#H;RD1r8^R?fz|PWBw&Fj-&ZGkTKFXFP{6kP74ut=HAk{lP^~}J>Y?xjq^ZJYp
z`>t6DMZqXKZd&q{``xb#4>~v#C&cxz2Pr@fQet2~dt~}ko~oo<^Ff^-_kG{<^RwZ~
zXpMY<f}}t6zo4&fGV@$ZeVvp*a$43apuTy$Acj|mfm-CYfOkh^o)*&;dikWB7g*5L
zi?0V+>|6G-kV!;P-6VW30i~q3l_e+Th4q5whWhy~EZxI5o$t?gCXV>DPqNuu*cGLZ
z*mACmuNgKi8}8ip8S}gJ;)XEvfp(6Zm}Tf<e9tStF;B>s0q5$O#-sTHe>|a@31m>Z
zrrKwsVvfovwG@t7AvBlXp)x%Ee8q76y2%_cKC7hSf$-R0DfNrqZcKIw_buvuX(~=L
z1$7<2Zv8%~@_=hky$-5q4U~tw8oIviznU?fA>fRjSG4cVIgi15>X5#&_}zlYxU$_(
zkzTQ$Xz{?0H%(+VI1a?if}g`!t-xgnHI$BZOD>nmY>1c@lJ^8@3SapM|GH-f(gzpa
z+U<fmm#^Fpr9vUdx!b)VVV&lr-bmWS4?;QFR;o}Szz{m>p(rGn8goy@+<hWS2r3J0
z!a{Px>#?Mq057-=0Df+LJ+_|gGX%dCYypx{xk03b%idr@s=~KCCiTKtL+ZYmK^NCB
zlS;Ky5BI(_c^zyI;h=iS8zR>0gPk74kACe=k-E;|ca|Tk>;vCijq;ib?(w9g4U3s!
z^wdoSRKit`(L7%{OI-nZe2yM-X1(&lxuaAy^z<0#h(+{k7J5u9nV~V_1fyfW%Kn$4
zG%6{FUhUzKF!}K=6QNxFi!@fXvHM#S%E<kACdnvyzhw?~A*uNDRMe;Fc~o9qp>82G
z`_taO8Ghs_74`D(D(0{=YOa)#r86%XtoTv>E$j!;h23d(x8V<p&(6LNp)K{Di$s#w
zM)*PRah2U%{f#xFABP^7s2r}qrUB52$8i!^A^b?h2>?p=BPJ}sUXD~$jCi$mdS%WV
z@;A_&wL6+`g{yC=+tqz)G%OpbJ3yvpi$9<3POBL6_BEkp{{(gVv}C%ybRzdOfGpEJ
z(}j(DyRBAhrry#=sZs%Yq;}r2Ph|H%cyc?OniJ-ME(#ZNMU0&R2H0a(Qpc~Wz7hl&
zOy}+CI_Rz7X(fm!A7p1IZWXuGR_<ehe!snYgKsu^F(;0u(;hb9pq=O=4`otJ4)vXU
zfVm$0o}s@|wOtb)OpNrKohb`Tk!!+n?X@O`eVg@n9)#dKW<Sn=QA*KjvCM5nipFj&
zffIMyTgP076Y$`+b~$DF8yjJ@THOUD;F&i}C+tIYnr_vvU{qfZoXD<P>?Y5qVyvQt
zz<AvZCAlKqT($$VO5R}$Kg5^1fTod<MOa&S$cb%{aOo~-RAeqH<2;?ho_`$a+vH1y
z5YwvZ6_(07>2Ce-#UhWMqsMHDL&uG1HYQiX*xW;}3+pdpo!w%g?A{4`xtv@mLEM8z
zuN_n8n&+XN_8-TIqw>03{@!ohG0?6pG}vna6)$xA-39K1{cD2Sxr|I;qW_2H<NZii
z_=w|2w@R%l%*Q&q9n&IMR~PrQv+>Hba3QbV8E_MeIxb8Dy>R9#sW7bdC5UMzc1}rl
z$`Smfu5-a-eY*WNYAy$3z!gf4-fn#{m3o8FaYj#V7o3Jg$i%~8yS<s>K5<7P6pptL
z)*sCT=1AO?LTH<_U?59nxY{#-q_JSmY!gJc^P*Q~0zWhr_*_?s-j;7EM-^#mYF737
zxlHBtHD)UM>6!<8M9t*)bEi6c;mcc-pk7356s}bfROS9nj-@pRj;m=4Wl0h3;F2)8
z$4FET3?l`6$?Y22f3z8uM2_?Kx-}8FR&i&&wb>K2J;bi-Fe`5Q&XMpjX^Swh63WP(
zxKrQUU{dYS`h1j6GGqemq8miID%6&@$NkXA;&{n|&*!|kGZ4r#@<o#|ry(n=0;+tW
zgl>`oVL7%x44ysHh_f_zq6)d$*(^HN&eYa&ya_2R*!$9m*3)+Vslo2X-1EiR<!Xr-
zSL1Pw2ABE01HwJh78!2cpWJ$$tL+_7$2&}kLstH4&_b>Umd2sQ<0OYso@L<uo9h80
zV$}=12^;PW!sHDsWPX`UtWM<H50C_XvhqfcdTd*sG;(wf&F~e@(x&Z^*kH992xvb=
z|7SyZJrb>L4%>kbOu*<dt%L<K>!X9GmwBMED^GXqnaO{)_;?_`O`#h(^KJ!C1`eA!
z$EKBQYSuX+e6u&D+{y3izr>ueLB9o!ZlR^;;XX?_{9Rhs+EpC7nZF%a_rI>+lEt(o
zl5xo+u*^a?C3a;&Y%noiJ7{TL&H~I@FJ<4?A$T)U+a6PFS8WMtH4(}_za+XnjrtA6
zq2(|gw&ENq8NFfD8MiIY?%T^DA-1%-v*Hd{f;@5Wf34;MAM)+5@k)OQndp9Ed*a)s
zt*@u4d*C_?wdz-H#*?c)D)uLkXocfnLl*k$m%b|7yCZGjTm62sz4>cnt~N7oFL!Eh
zc4m0--A0_BYMMsZ&(5qQ6AN`x?=@-LCrD@@H8i^$JFQ~8HO8_ey#lu~uiXq=;%tfu
zg6_B$y2fiFw}o|@i}wi{SOQlzyls8H+s1x<e&i)+R&q_u0x9YSLJp3}WmGn)NwbU7
zg*?3HYwiTG7{+l7B%^MQ-8N+w%$;}s+9+K+R_=!$E*ixb9bD%bRex<4n}%Nwo6-%%
zc4dvrm-v1ADw1BiJQncLld%7LxXKzJC#hPWp0Ct|rDy7&nQ5%YW?}t^rsh;Y)6(4C
z<w2YgMPz1mTt@C_w8)nGVG$J?X_lA8#7t{D;Mr9yv>~>RGBi_V>aco#le<NJ$-yFG
z0%us-rnoOKCMw`H3ihWwFl&{2v~V@JaN4AXLt!z^HZGSOdHoSA^0f|R806`p_D*5F
z@MRMJaXOu}qaZDKtt(JcATe66EjU@H#ZNQs^YyPCv%-iv52m)(jykLEtf~8mvopKh
zVdt0XyVFn(Avte}D1U*`iLK^piIgWWgX*Q+ml>k!UVF#Fy0KqaI~Q7o1iIVaY9)Uw
zoL@_vO6(2`v(eTf@6PU{l;Zcu1l0ANH#Vg$An>;v{92z#UsAkY>#aY%YswsoS0mYN
z@8j#*xx0cHQpAnD{E{ym^d(K1+n6oV%8M<e^&}pJubqzy^_e=|eJNfK`Dz!xhG{Qm
zYPUzWux-ugdyw%C<&_oa$ff#5A$B=BrKPNq6%qKYUA3Vq{>p<*=Ys_H1N@$b1EM&$
z6%s|3bK?xQYp9j^T6-t!`Zx9ro5JYrwLtd_MI*a*T}GZ4>EZQU7om%U<!j@y6oDE=
zlHA^1qNX%2Sq@UM71WDESw5|dyizTJ#JNS%HU#+AzV0zy_Nk08k!KIx9ysW^UkkEF
zS$cJ%x&@{OW;w^|605<sv&em7=O9GNT~}di)g~j%*icuQe9-!ye>z8SdH^lCGs81^
zZEJ)tp<=n}Au81(Vc|W3uKdLlJ@zjXC0<$U75cLYR#=9RvU_X=V|@mf0wcl{u8Q7R
zA=MwFOO$E~4Q}8M4vf69H7@9;gj?4}%ZsUU1ziCJ!?JE#vZ`dhB@><++k(G2A-r|A
zaom2I95ux7RXdnq^{R+SHdrFrP3~a*x+gADn16b}S!M|<C9aWHa9L~?Ji0fODpO(B
z-V1{4t=5}ug`y=|X~%62>c6#ASEV=M`{9+>Q1MA+?2#MPr{=_Ypy~~F3oV3+sq6()
zeRHcFOwmlB*FJSU?svf7X(jv~rhdjXn8N*zI9t_tbzWp%f%B+dtZhRY`mS%}Krkdk
z!lb*=yLZ*1c1pk`p@<}T#crI_|8ps!WU7?6;iV;5kU%#YHeXH*ZZ{hB={6Qc<z!~M
z)R)lzsrh+`Xe`j&REzqMYNR8}tK$$>EMNiI&$kUIEbV%ARNYYHOZxD^!p$fL2~J4Q
zLzvEzh5hBsPN`y}@j+~-RarT5PJ2o1*d8ujG{0JR0po2%YGEC!Gj@#<rsw%X1n?(!
zaC{yJBitWe@O$P~gcd*xZ*9S+tN~}Km0<0!cg87>f|>@-Mm0f=7kRP9x!-sxZt`vP
zc@S?!tsSWVKPuP=t!3U@cJ*7E5DRkbsV@bmOeRZD4`gf-?(Dh@3yr%p4))g6nX|*<
zg5?BtGcIVQiIyaa*O;_W*%WJcBp`#T5>*Tf)iXA74ZzQF1J1zZOHGIF^t91Vs~6=?
zQp1`OmTN7h&K0|`MZ0dJ5E{c#0>apgh;Tt{!W;vA)^Ze6#Iy71c|O$xUe*)90mj|0
zB#1*{fz~sDl?X)JIL9Hk%e`Cl2}q=1laABBT4NW#%^P59C(B_`<?T_Sj`-HyD>(4%
znWCKN23RXYIm|6}NM3;b*03=sJrk7P8Q{^<BxUg~r932?oRa2UjZuOS;w$!CvrX8F
zwWK>SyKKe2>{g#+ZEeur3w};=a}!`suEDJ18)fC=jXv{`hN2Zzo!gN79!5~ahy+8|
zYBGz(MdgM`q6J)v1f2)<Akuuyn3*$$-cFgNnvIn%wJ9dcrKQeUd@8TVfMeVtdQk|9
znYuBYV#<sWQPS~1ypHChX49uQDC`^iBDKg?LW~|@P94z(i5e{|o#3@kp@xjEH>;Mc
zUAtem?g(rQ^l}drdI*~pBMr-TLkjy8XGykgA?^M%4MLK$m&_J~Xa?(UBQkaZ9JeDq
zhC3bFAK0Z0l~iP`#H!!NCzG(aP1<xZSYZ72^0}^ZUPGs$^eNU17sep{0`_tlgOXLL
z@jv!gqK-tYQ_bvZ(s@h@@v$5Qz)Y^U>~CS9ia#{$@jK-6W>YhPtwMrO<7-Z(>dUgu
zV+KQP)5u1b`iD;OPCjptUVuKY_N$z&z0sBfUrQaZ@cHs756vH}dv>tuZsTfig9GVG
z0!St_#9{CT{zEaYeKSMKdbk{Av)pre)Z|laGHZX`{`~NW^?;alw*=+@YKIY*;EnKg
zt`m_R<EGu!mDES9XRO+Z5U1SQ0}%t2V4*fUKkT`sxb3$tZy(f+Yyj$Zks$j#!PPhf
z$t<|&9`?<hAkQ4n#Pi9Yf?JRW0+0P*y=-DGQB-VKPMujC4k%Gsl&o?SoEfv><z+ZP
z|Khns^5RI)0CqG9xkrX)Jn`yIGnBwLd5>0I*cmRX9M`qdNq#ZU?b9wH>!!^<d2O_O
z{ZG{dVaDjxkE=uZ#s$ji9KpAIC$!SV<L_`M#N0UWRgZ&Q7q{8mu1?fyVHpBfKt4dT
zUD&e30lN?&g!XK)JlPu9iB^012bcfXN*6|@$qAot(GD<=duLe0lAl}U$3;?SJ`1n6
zB+JFD=*%LZFgQJCMau|IeQGe3f&gX+KFBe~fPs9}_f1TtG05($SQTz(H-B{?zMpT{
zot6>m5Uj+P6SOn>u>ITnd}8a6tQDt2)<L%abn0UF(3CZ}x4Nl`_#tSh*6_FUrb5w}
z?AoczNWU>+)kiV-W!I|{kynSaRi-S<u=qNqUH3_8^X@by;cC`ZC-vZJ^e~zg4+K~`
z#z5Rh9*tQUVwWyv15|C`*w<7QJP>9LDNA`E0`nIPRL$LW^~Mot=P5)cUYzvbd=*01
zm#{?)Ym#b90ez_mWj_cdwASzCh1t^T=`j**+QN*WUA1OzEUw^qfq~@Ojm<N9Fzl@@
zqPP7{zMdi*tZ5^#&}Ut-UofM=+?3g{+HxydK+9%(;G@mfgq)#oU473k(L#3B)XqW(
z0#!L!^XtP-aMJB7qR&1M7O@eGPgMSmooz{Ub6322p|8)kvb^V6RT=TddZeGRvH`BC
zSc*wg3v}$>;NID#aFwG#Xvi=Vc(m!&@$1(-5DRo_=CFngkyCRb6yJ9Td83yg4|MBU
z0^KGTEiW=yJ=ZHtzIt|d?3HbF#&AaUQd<Fwh1~UL6GY4f*#|BK&aWjdU5=(x-r;e3
zH~Xyqt1LzUqAQLXT*KA`Wj*SlnKz~UN0H#!H}1BHlj~6sn=gE-Qfp~x$xqMBW*;Cq
zBVq4&+?rNu>q)!al3IvCyQQ%J!`BM?&7b!*?Zu0UeywMfW2XdHkh!5)r>k@1i&umC
z%1^7ZD!O@3$j$Yw;$3&$^z#yq^{U?g6wdcrb$lxWvhULMWc#Z`7$c59HxZrewsqsd
z*xZHnkw}kaLzWiqs7WRVGHK?e*@Dy`+;`2~$ArdLD~S7Y%oPu8Mvbu{d~O;@7w0c%
z#K5yrajUR{?3YquZmM)Q!>BV4nN_xo1(_x*0>yCr@tt^sw<)U7d4qhd&bgJ4sq6tz
z(Eh3aQ|XyA_!0xjBCg567CRPmX5%SuA5n|iYs`XD9RqU#yZR=h_xE)@mgpqnYsSkh
z^13QJt1bYhN&r1?W>kJJ3A8-5|9L9kt604ASviA#v7VTp&bVzPMkmniZeI2nhei|q
zNd02l)d%P&8cg|-Fg6ZFI5Ey=*hCh}5o}k!G2e*wTI`MX0JqsUYJ%5Qxsf+Ez|hN(
zJ|&Ir&5QvX^dM+-dUO1>)o%))->l-u{qLxUSL)qJpUsNfB%YDPy=J-NI5{0G{6OW9
z)x<Z`f$S}VsN(kKA^T4E;d}>g$2!RXD=X7u#1V-cuARF@I}W#z954YI94A;JPUfE9
z{!24SiQ9S{xjT<}EM}2;T2nf;9ikDbq0zD-TZ?!?Y+qbXCrdy`atJ?Eex>;tR|5Ie
zwSc1@AubE7u|UNqLl~I-9LBlt5)?DhbDsJk9}hIK_gnNzO+aiWs%9pzH@BwV(yRLS
zcg=CzzXuB&#yQn-`X!2pH}W?6ELo~mq!!mMR~t?Q&x`d3Z5T>D>b4xLRE^pmnwM>n
zF>`|`W(j_#WZEv$<O<ddG>)g0n5`Z0EPpii3TNwF)VUq4FW7dH8~6moH#D%RZlAPu
zeKR~_UZzB61u4B;(W5uYPpaLojn_goiH^N>+P1Y%sH-qNc8UXW@V<U^)2mycW-+xV
z@hZ4IU8}hmgp&fYMf{@**WoOxA!prjb5bOPjh-%YRTH_U+4U~@IDTdv*7}AeH)e6_
zLK3LCILy;`K7+*oe$mS!vC>SEk6a&V<QksUH_V;w5^S#Fyow<xIwz{w01`bDXwwwg
zI@nZiSzRmu#q?;oQu$n@2(%BLOFCVqg^;P}<bklad}=xlP%1>yFwS{#%`aMca&yuD
zvdKyEQwE8)K_`9du^uN78fxdgh8C02vag_1`1WnYt!%B-(QdxP2b{4eOI~f`PujOv
zAj8^iNOLq-6+ta^_sZ0~mj~r)R}prrh&^l)nJ$J|Y?y@5Y2V_k+V}3Uk-_J{zp~2m
z+h{n{>uE5qNPz_&nhJ)bLLXR-ZSSsBa4%*DSaO7I;_>Uw60IxlO<ej#deJ7GjM7e%
z@r`chCgDDbkz1_vKpijV8Y1*}JWT;^jPz6>BO*NnSK0{XBPw0m(#1xd%neeo<RtiN
zgY278IkK`D5lG8TjkMci4#ktRpC^g&U$c$Hx~l?%ILBaF0=a^y@vw%v=4BtvFx&`K
zwZ~LmXiR{BCi?5l5Ar3%h9si~m2>?0(Y<Cu0=W$}$p_v`gO_*R>%2Jp-cMJ0tg~F<
zjPlk_>&jqB4S{yCd28%elzNjqGjiVQ8v3Bvy#qJbYD^SJ&ETs6ZEs(ulB6{Of|NZR
zlcS=3c<7MS1V4@0^7KHE@|iHPTZS@^sOAs7#fDIRN{G~e+>>s=rRqyMd#XhYPJU(K
z-iNLJ@l~<LEnT~0W&GVd>HK^qX$fWQmST$8cZ9t;4&4Xs^s1oX0lm><&B)kgby>on
ziQR@{t{PLz5_j`EY2p;-!Jfpy{r=G7A&HS>dE~_QZHp?q{<e<C&!DzI4oct(Ez4WL
zPJc>l|GW%jpkOwi1hHB5*cR?bObA5}M6}Yqx|-X7gvN^!Lf<&qA6?1TIeC~uJxqI2
za;g7r@W>vG-k!)B<o!?AzsD$z02+;!#nuJh?<v^74N+En0SUhq?56vW;fE!Em=y7j
zntx`)+KU0m*ZytWf6eL8QQ=jR6{`8!7_g#>C6I>=sBCyn$@l(b&YU0*LoNht`m-?r
zNgfFRw|67vw|;==$AvtZUOY$jg2aBhHh^0?fSaX@_^(LQKq1XS0rQVb{s3f$7J!?C
z49l-bGXaps%j<6JuW%CpaASeQ{;=YYG*)o~NYfx!qV@~i))@iZVtdtoMVfzJ`~Ru0
z{gW`P%-p~^!a1z!&tX@`aFxna6pdibTI#`g$kQH*09Tza0Te(1UEdoT`i{dxE6r9x
z9v-M{MAR4NnA`8;wqFMroY4F^bF^OKVX%tR>wQV{qbB(G+*ghOXT~nvVZHQo&OVnP
zE<MBkr6k+08mGYa+*I~B&nJqqx^h~TBD4E|Cr)rEn{Q?U4uEhO7XaD!0sK}>Me*=y
zGZk}*)kPa`9Wxc*dM9NoKlOj_`nN{BC=bI_2b~J>=j{9G?Q#AY$kv9B-!H~H0O5!y
z9r4!t+p7Pb3~bMf{BO7aRGPF0tNwa&-zPY`rtso-4e`nYNN%<fFgFhA@~0LMyoyWL
z97<rT@crAtl}d86f<M)x5w9unUQD~~i+{uLx5gjk0Kl!gb8(PEZID!ht~hdp8V$O2
z)8MDC=;vttZONa)@$(n@&lbP10RPbN7uM$&HtQco`iGHzshS*Ts1CTvi}P{Zf-S*E
PfFF>W?k(u=_aFZk<w{Lu

diff --git a/src/pages/docs/administration/sync-instances/index.md b/src/pages/docs/administration/sync-instances/index.md
index c4051d96e7..a404c4683d 100644
--- a/src/pages/docs/administration/sync-instances/index.md
+++ b/src/pages/docs/administration/sync-instances/index.md
@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-10-04
+modDate: 2026-08-27
 title: Sync multiple instances
 description: How to keep two or more Octopus Deploy instances in sync.
 navOrder: 45
@@ -14,58 +14,26 @@ Keeping multiple instances in sync is a complex task involving dozens if not hun
 
 :::div{.problem}
 
-TL;DR; copying projects between instances should be done when all other options have been exhausted.  There is no provided tooling to support syncing instances with different environments, tenants, or variable values.  Due to the number of decisions and business rules, you will have to create and maintain a custom syncing process.  Before making this decision, reach out to [customersuccess@octopus.com](mailto:customersuccess@octopus.com) to see if there are alternatives.
+TL;DR; copying projects between instances should be done when all other options have been exhausted.  There is no provided tooling to support syncing instances with different environments, tenants, or variable values.  Due to the number of decisions and business rules, you will have to create and maintain a custom syncing process.  Before making this decision, reach out to [support@octopus.com](mailto:support@octopus.com) to see if there are alternatives.
 :::
 
-## Suitable scenarios
-
-Split and sync instances only when Octopus lacks a critical feature to satisfy a company policy, industry regulation, or a business contract.  The use cases we've seen in the past are:
-
-- A separate **Dev/Test** instance and a **Staging/Production** instance so developers can have unlimited access to make changes, but **Production** must be locked down because of a business contract.
-- A primary **Dev/Test/Staging/Production** instance with an isolated **Production** only instance for a set of targets to satisfy a contract requiring an instance hosted in Azure Gov.
-- A separate instance for a specific set of tenants.  Like the above use case, except all the environments are the same, only the tenants are different.
-
-The expectation is the source instance is the source of truth and the destination instance(s) contain copies of that data.  The syncing process will run periodically to ensure changes made on the source instance are added to the destination instance.
-
-:::div{.hint}
-If you wish to do a one-time split of an instance and have no desire to keep anything in sync afterwards, then we recommend the [Export/Import Projects](/docs/projects/export-import) feature.  
-:::
-
-## Consider alternatives
-
-As you will soon see, a syncing process is complex an requires constant care and maintenance.  Even if we provided a built-in tool, you'd still need to monitor and maintain the process.  Below are the common reasons we hear for splitting an instance.  Please reach out to reach out to [customersuccess@octopus.com](mailto:customersuccess@octopus.com) if your use case is not mentioned and you'd like to discuss alternatives.
-
-:::div{.hint}
-We've been asked if splitting environments, tenants or deployment targets by space is a safer alternative.  [Spaces](/docs/administration/spaces) are hard walls and do not allow the sharing of environments, projects, variable sets, step templates, script modules, deployment targets and more.  For all intents and purposes, a space is a unique instance.  Any problems you encounter when syncing instances will happen when trying to sync spaces.
-:::
-
-### Built-in role-based access control
-
-In talking to users, the primary reason for splitting an instance is due to permissions.  Before doing splitting an instance, research the built-in role-based access control as it supports a variety of common permissions use cases.
-
-- Developers can modify the deployment process, deploy to **Development**, **Test**, and **Staging** but not **Production**.
-- System admins can modify deployment targets in Octopus and deploy to **Production**, but cannot modify a deployment process.
-- An engineering team is permitted to modify the set of projects they own.  All other projects are read-only.
-- Release managers can modify the variables on a set of tenants assigned to them.  All other tenants are read-only.
-
-### Approval process
+## Unsuitable Scenarios
 
-Another reason we hear about is needing an approval process for changes to the deployment process.  Please see our [config as code feature](/docs/projects/version-control) as that integrates with git, which allows for branching and pull requests.  
+We know of a very small subset of customers who have successfully split their instances and sync between the processes between them.  Almost universally those customers started on older versions (pre-2021) and did so to address limitations of Octopus Deploy at that time.  Today, the most common scenario we hear for splitting an instance is:
 
-### Performance improvement
+- An instance per environment for example one instance in **Development**, another in **Test**, and another in **Production**.  
+- Releases are promoted between environments. For example, a release starts in the **Development** instance, is promoted to the **Test** instance, and finally the **Production** instance.
 
-The final reason we hear about is to "speed up the deployment."  We typically hear this when Octopus is located in one data center and deployment targets are located in a data center in another country or continent.  That can lead to long package acquisition from the built-in repository and latency.
+Typically the concerns are:
 
-- If package acquisition is taking a long time to transfer to the targets, consider:
-    - Enabling [delta compression for package transfers](/docs/deployments/packages/delta-compression-for-package-transfers) to reduce the amount of data to transfer.  
-    - Leveraging an external feed such as Artifactory, GitHub Packages, AWS CodeArtifact, or Feedz.io and configure Octopus to download the packages directly from the external feeds.
-- If there appears to be latency when running scripts on the Octopus Server to make database changes, run e2e tests, or any other similar task, then leverage [workers](/docs/infrastructure/workers).  Workers can execute tasks that don't need to run on individual deployment targets.  They can be located in the same data center as your database or applications.
+- Approval process for any changes to the deployment process.
+- Separate VLANs or networks for each environment.
+- Specific steps are included for every **Production** deployment.
 
-## Unsuitable Scenarios
+Octopus Deploy includes functionality to mitigate those concerns.  That enables large banks, hospitals, retail companies, software vendors, insurance agencies, and government clients to have all environments on the same instance.
 
-Do not split an instance and sync it for any of the following use cases.
+Other unsuitable use cases for splitting instance include:
 
-- You want an approval process for any changes to your deployment process.  Please see our [config as code feature](/docs/projects/version-control) as that integrates with git.
 - You want to move a project from the default space to another space on the same instance (or different instance).  Please see our documentation on our [Export/Import Projects feature](/docs/projects/export-import).
 - You want to create a test instance to test out upgrades or try out new processes.  Please see our guide on [creating a test instance](/docs/administration/upgrading/guide/creating-test-instance)
 - You want to upgrade the underlying VM hosting Octopus Deploy from Windows Server 2012 to Windows Server 2019.  Please see our guide on [moving the Octopus Server](/docs/administration/managing-infrastructure/moving-your-octopus/move-the-server).
@@ -73,451 +41,115 @@ Do not split an instance and sync it for any of the following use cases.
 - You want to migrate from self-hosted Octopus to Octopus Cloud.  Please see our [migration guide](/docs/octopus-cloud/migrations/) on how to leverage the [Export/Import Projects feature](/docs/projects/export-import) to accomplish this.
 - You want to consolidate multiple Octopus Deploy instances into a single Octopus Deploy instance.  Please see our documentation on our [Export/Import Projects feature](/docs/projects/export-import).
 
-## Syncing is not cloning
-
-Syncing is not the same as cloning.  Cloning an instance will result in an exact replica (or copy) of data from the source.  In addition to having all the same targets, environments, variables, tenants, projects, etc., the unique identifiers stored in the Octopus database will be the same; including the Server thumbprint and database master key.  Cloning is typically a one-time operation, such as standing up a new server.  
-
-Syncing instances involves copying projects and all required scaffolding data between Octopus Deploy instances with different environments, accounts, lifecycles, targets, tenants, or even variable values.  Each instance will have different ids, Server thumbprint, and database master key.
-
-## Tools and features to avoid
-
-Unfortunately, there is not first-class tooling available to support syncing two instances, due to the many decisions and business rules when working with different environments, tenants, variable values, etc.  In the past, our users have attempted to repurpose provided features and tooling to support their syncing process.  However, they were not designed for syncing use cases; the result was often frustration because of lack of customization, or hand editing files causing corrupted projects.
-
-### Migrator and Export/Import Project
-
-The [Migrator](/docs/administration/data/data-migration/) and the [Export/Import Project](/docs/projects/export-import) feature were designed to migrate or clone a project to another instance (or space for Export/Import Project).  The primary use case for both tools is that a user wants to move a project to a new instance and deprecate the older instance.  For example, when migrating from a self-hosted Octopus Server to Octopus Cloud.
-
-The Migrator and Export/Import Project feature can be run multiple times for the same project.  But they will ensure the source and destination instances match.  There is no way to exclude specific environments, tenants, or any specific data you wish to keep separate.  While it is possible to modify the JSON exported by those tools, such an approach is error-prone and unsupported.  
+## Suitable scenarios  
 
-### Octopus CLI
+With the capabilities available in Octopus Deploy today, the only suitable scenarios for splitting an instance and syncing them are true "air-gapped" networks.  
 
-The [Octopus CLI](/docs/octopus-rest-api/octopus-cli/) includes the [export](/docs/octopus-rest-api/octopus-cli/export/) and [import](/docs/octopus-rest-api/octopus-cli/import) commands.  Those commands are deprecated and should not be used.  
+For example:
 
-### Config as Code and Octopus Terraform Provider
+- A primary **Dev/Test/Staging/Production** instance running on a public cloud (e.g. Azure) with an isolated **Production** only instance for a set of targets hosted in a government cloud (e.g. Azure Gov).
+- Same scenario as above, but using multi-tenancy.  The primary instance and isolated instance have different tenants and targets.
 
-Terraform uses Hashicorp Configuration Language or HCL.  The [Config as Code feature](/docs/projects/version-control) uses Octopus Configuration Language (OCL) and that is based on HCL.  HCL does not support complex logic.  That means you'd need a unique set of files per instance.  To sync instances using these features, you'd need to use a comparison tool such as Beyond Compare to move changes between instances manually.  Anything manual is error-prone and will eventually fail.
+In both scenarios:
 
-You can write a tool to compare files between instances automatically and make the necessary modifications.  You will run into the a lot of the same roadblocks as below as you'll need to consider dependencies, environment mis-matches, and more.  
+- Both instances have a **Production** environment.
+- The same application is hosted in multiple **Production** environments.
+- A new release is created in the isolated instance to deploy those **Production** targets.
 
-## Tooling to use
-
-We recommend creating a custom tool that leverages the [Octopus Deploy REST API](/docs/octopus-rest-api), or one of the API wrappers, such as the [Octopus.Client .NET library](https://github.com/OctopusDeploy/OctopusClients), [Octopus Go API Client](https://github.com/OctopusDeploy/go-octopusdeploy), or the [TypeScript API Client](https://github.com/OctopusDeploy/api-client.ts).  
-
-We make that recommendation because, as you'll soon see, there are a lot of business rules and decisions to make.  
-
-The Octopus team has written a sample PowerShell tool, [SpaceCloner](https://github.com/OctopusDeployLabs/SpaceCloner), you can use as a reference or example for your syncing process.  A lot of this documentation used lessons from writing that tool.  While the SpaceCloner supports syncing instances with a known delta, we recommend using that tool as a guide.  It was created with specific use cases in mind and probably won't support your hyper-specific use case.
-
-## Syncing process
-
-If you do determine the best course of action is to sync projects across multiple Octopus Deploy instances, then you will need to start designing a syncing process.  While the actual business rules and decisions will vary between implementations, the core rules for any syncing process will remain the same.
+The expectation is the source instance is the source of truth and the destination instance(s) contain copies of that data.  The syncing process will run periodically to ensure changes made on the source instance are added to the destination instance.
 
-:::div{.warning}
-As the syncing process requires the use of the Octopus Deploy REST API, or one of the API wrappers, you should be comfortable with the Octopus Deploy data model and API endpoint structure before starting.  
+:::div{.hint}
+If you wish to do a one-time split of an instance and have no desire to keep anything in sync afterwards, then we recommend the [Export/Import Projects](/docs/projects/export-import) feature.  
 :::
 
-### Avoid mismatched versions
+## Avoiding syncing multiple instances
 
-It is possible to take JSON data retrieved via a `GET` request on an instance running 2020.1, make some modifications, and then `POST` that data to an instance running 2021.3.  But there is no guarantee that the data model will be the same between versions.  Something could've changed, a new required property, a property type was updated, or any other reason a model changes when there are over 12 months between releases.  The risk of error is directly correlated to the delta between versions—the greater the delta, the greater the risk.
+The syncing process is complex an requires constant care and maintenance.  Even if we provided a built-in tool, you'd still need to monitor and maintain the process.
 
 :::div{.hint}
-In late 2020 an engineering effort was made to move from NancyFX to ASP.NET for the Octopus Deploy API Controllers.  Since that conversion started, missing or additional previously tolerated fields will now cause a 400 bad request error.  Looking at the SpaceCloner code, you will see several invocations of an "add field if missing" method because of a model change.
+We've been asked if splitting environments, tenants or deployment targets by space is a safer alternative.  [Spaces](/docs/administration/spaces) are hard walls and do not allow the sharing of environments, projects, variable sets, step templates, script modules, deployment targets and more.  For all intents and purposes, a space is a unique instance.  Any problems you encounter when syncing instances will happen when trying to sync spaces.
 :::
 
-A rule of thumb to follow is don't have instances more than one minor version apart.  For example, the source instance runs **Octopus 2021.2**, and the destination instance runs **Octopus 2021.3**.  Ideally, all instances would be on the same `Major.Minor` version.  Do not sync between major releases, for example the source instance runs **Octopus 2020.6** and the destination instance is on **Octopus 2021.3**.  If you run into unexpected 400 bad request errors, the typical remediation is to upgrade both instances to the same version.
-
-### Have a single source of truth
-
-It is much easier to sync everything in a one-way direction.  The source instance should remain the source instance every time the syncing process runs.  It shouldn't be the source instance one day, and the destination instance the next day.  
-
-It will be nearly impossible to know which instance is "right" and whether the change should be accepted when a conflict is found.  For example, both instances have a step added to the same deployment process; on one instance, it is a new manual intervention step, while in the other instance, it is a run a script step.  Should both exist?  Only one copied over?  You'd need a comparison tool similar to Beyond Compare to reconcile this conflict.
-
-It's okay to have known differences between the instances, such as different environments, lifecycles, variable values, tenants, deployment targets, channels, and more.  But when something new is added, such as a new variable or step, it should be done on one instance and synced to the other instance.  It is hard enough to detect when something is "new". A one-way sync will help keep conflicts to a minimum, and reduce complexity.
-
-### Data to sync
-
-Octopus Deploy is more than a deployment process and variables.  A lot of scaffolding data is needed for everything to work correctly.  The syncing process should allow for the syncing of the following data:
-
-- Infrastructure
-    - Accounts
-    - Environments
-    - Worker Pools
-- Library
-    - Certificates
-    - External Feeds
-    - Lifecycles
-    - Script Modules
-    - Step Templates
-    - Variable Sets
-    - Tenant Tags
-    - Packages
-- Server Configuration
-    - Teams
-    - User Roles
-- Tenants
-- Project Groups
-    - Projects
-        - Deployment Process
-        - Runbooks and Runbook Processes
-        - Variables
-        - Channels
-        - Settings
-
-### Matching by name
-
-Each instance will have different database identifiers.  For example, Project "OctoFx" in the source instance can have an id of `Projects-1234` while the destination instance's project id is `Projects-7789`.  That means all data matching between instances must be by name.
-
-What makes that complex is that items such as lifecycles, environments, accounts, etc., are referred to by id in projects, deployment process steps, and more.  For example, a project has a default lifecycle.  When syncing any project, the process will need to:
-
-1. Translate the lifecycle id on the project to the lifecycle name using data from the source instance.
-2. Translate the lifecycle name to the lifecycle id on the destination instance.
-3. Update the project's default lifecycle id before saving it on the destination instance.
-
-That complexity is further exacerbated by the fact that some data is required, for example, a project's default lifecycle, while other data is not, for example, a step scoped to an environment.
-
-### Data that must be an exact match
-
-The following items must be an exact match between your instances.  Otherwise, you'll get missing data errors, corrupted projects, 400 bad requests or unexpected results from deployments or runbook runs.
-
-- Script Modules
-- Step Templates
-- Tenant Tags
-
-### Data with the same name but different details
-
-Most of the data referenced by your deployment and runbook processes have to exist, but the details of the data can be different.  For example, a deployment process references the worker pool **Ubuntu Worker Pool**.  On the source instance that worker pool could have 5 EC2 instances in a West Coast region, while the destination instance could have 3 EC2 instances in a different region.  As long as the worker pool **Ubuntu Worker Pool** exists in both instances with running workers, everything will work fine.
-
-The data that must exist but can have different details is:
-
-- Infrastructure
-    - Accounts: Same account type, different credentials
-    - Worker Pools: Different workers
-    - Machine Policies: Different health check frequency, tentacle, and calamari update settings
-- Library
-    - Certificates: same certificate type, different cert
-    - External Feeds: same feed type, different credentials
-    - Lifecycles: different phases and retention policies
-- Server Configuration
-    - Teams: user role mapping, different members
-- Project Groups: You don't have to sync all the projects in a project group; only the project group has to exist.
-
-Variables can be used instead of directly referencing that data in a deployment or runbook process.  The deployment process will work as long as the variable exists, is of the correct type, and is assigned to something that exists on the destination instance.  For example, a variable named `Project.AWS.Account` refers to an account called `Dev/Test Account` on the source instance.  That same variable can refer to the `Staging/Prod Account` on the destination instance.
-
-Items that can be variables are:
-
-- Infrastructure
-    - Accounts
-    - Worker Pools
-- Library
-    - Certificates
-
-### Data not to sync
-
-The astute reader will note that the above list of data items is not ALL the data stored in Octopus Deploy.  It is possible to sync the following data, though we recommend against it.  
-
-- Infrastructure
-    - Deployment Targets
-    - Workers
-    - Machine Proxies
-- System Configuration
-    - System Settings (server folders, SMTP, etc.)
-    - External Auth Providers
-    - Issue Trackers
-    - Users
-    - Subscriptions
-    - System Level Teams
-
-One of the primary reasons for having separate instances is to isolate deployment targets and workers.  Besides, each tentacle would have to be configured to trust all the instances.
-
-Items in the system configuration list are set and forget.  Or, set and update once a year.  Most of that data requires admin-level permission.  It is too risky to include system configuration in a syncing process.
-
-### Syncing Packages
-
-Packages size can be substantial; we've seen some that are 1 GB+ in size.  Syncing files of that size between instances can take a tremendous amount of time.  We recommend excluding them from your syncing process and instead do one of the following:
-
-- Switch over to an external feed such as Feedz.io, Artifactory, Azure Artifacts, etc.
-- Update your build server integration to push to multiple instances.
-
-### Data you cannot sync
-
-The Octopus Deploy REST API is powerful, but it has intentional limits put in place for security and auditability.  Namely, it doesn't return sensitive information or allow you to modify audit history.  Because of that, you cannot sync:
-
-- Sensitive Data
-    - Sensitive Variables
-    - External Feed Credentials
-    - User Passwords
-    - Infrastructure Account Credentials
-- Audit Data
-    - Releases
-    - Runbook Snapshots
-    - Deployments
-    - Runbook Runs
-    - Audit history
-    - Task history
-
-For sensitive data, decrypting and returning that data via the API has never been built into Octopus Deploy.  We have considered it, but there are several security concerns, and we'd want to ensure they were all met or mitigated before adding such functionality.
-
-For auditability, Octopus Deploy prevents the updating of any auditable / snapshot data as well as limiting how that data is created.  For example, the release endpoint accepts a `POST` command.  In addition to creating a release, the variables, package versions, and deployment process is snapshotted using data as it exists at that point in time.  That prevents the ability to sync a release created six months ago via the Octopus Deploy REST API.  If you did, it wouldn't use the variables and deployment process from six months ago; it would use the variables and deployment process as it exists right now on the destination instance.
-
-A deployment, and runbook run, have the same limitation.  Issuing a `POST` command to those endpoints will trigger a deployment or a runbook run.  You cannot copy the task history, artifacts, or task logs via the Octopus Deploy REST API.  That is because that deployment or runbook run you are attempting to sync *did not happen* on the destination instance, only the source instance.  Not only that, the associated releases and runbook snapshots will have different variable values and deployment processes.  
-
-What this comes back to is auditability.  If that data can be modified by any outside process then it is not auditable.
-
-### Syncing order
-
-In our experience, it is far easier to group data by type and sync them all together.  For example, sync all the Project Groups before syncing Projects.  That requires an order of precedence in syncing due to data dependencies.  That order of precedence is:
-
-- No Dependencies, can be done in any order
-    - Environments
-    - Project Groups
-    - Tenant Tags
-    - External Feeds
-    - Teams (exclude any scoped permissions on creation)
-    - Machine Policies
-    - Worker Pools (not workers)
-- Dependencies, order matters
-    - Infrastructure Accounts
-    - Step Templates
-    - Script Modules
-    - Lifecycles
-    - Tenants (Tenant name only)
-    - Workers
-    - Targets
-    - Certificates
-    - Variable Sets
-    - Projects
-        - Project Settings
-        - Channels (no channel version rules)
-        - Deployment Process
-        - Runbooks and Runbook Processes
-        - Variables
-        - Channel Version Rules
-        - Release Version Strategy
-        - Built-in package repository trigger
-        - Logo
-    - Tenants
-        - Tenant / Project relationship
-        - Variables
-    - Team Permissions
-
-### Keep a log of data to clean-up
-
-The syncing process will encounter data it can't sync precisely because of a limitation, for example, a sensitive variable.  The variable name must exist on both the source and destination instances because it is referenced by the Deployment or Runbook process.  But the value will be different.  If the sensitive variable name doesn't exist on the destination instance, it should create the variable but insert dummy data.  When that occurs, a log entry should be written to know that data needs to be clean-up once the syncing process is complete.
-
-**Please Note:** The syncing process should only do that only for new data.  Any existing data where it can't match and sync exactly should be left alone.  For example, if the sensitive variable already exists on the destination instance.
-
-### Log everything
-
-Log everything, from API calls, before and after logic gates, to lookups.  There is no such thing as too much logging with a syncing process.  The syncing process is translating JSON data from one instance to another.  You are going to find it fail in strange and unexpected ways.  There are many business rules, meaning there are a lot of potential bugs.
-
-## Handling different environments
-
-There is a ripple effect when the source and destination instance have different environments.  These are the three possible use cases for instances with different environments.
-
-- The destination instance has a subset of environments of the source instance.  For example, **Dev/Test/Staging/Production** on the source instance and **Staging/Production** on the destination.  
-- The destination and source instance has a different set of environments.  For example, **Dev/Test** on the source instance and **Staging/Production** on the destination.
-- It is a combo of both use cases.  For example, **Dev/Test/Staging** on the source and **Staging/Production** on the destination.
-
-One or more environments are excluded from the syncing process in all those use cases.  Consider all the data that can reference an environment:
-
-- Infrastructure
-    - Accounts
-    - Deployment Targets
-- Library
-    - Certificates
-    - Lifecycles
-    - Variable Sets
-- Tenants
-- Projects
-    - Channels
-    - Deployment Process Steps
-    - Runbook Process Steps
-    - Variables
-
-### Lifecycles and Channels
-
-Different environments per instance mean different lifecycles, which can mean different channels, and channels can be scoped to deployment process steps and variables.  
-
-For example, there are two lifecycles on the source instance:
-
-- Default lifecycle with **Development**, **Test**, **Staging** and **Production**.
-- QA lifecycle with **Development** and **Test**.
-
-The project to be synced also has two channels on the source instance:
-
-- Default channel
-- QA channel
-    - A manual intervention step is scoped to only run on the QA channel.
-    - A variable value is scoped to the QA channel.
-
-The destination instance has **Staging** and **Production**.
-
-It makes sense to include the Default lifecycle and channel and exclude the QA lifecycle and channel in the sync for this scenario.  Excluding the QA lifecycle and channel has a cascading effect.
-
-- What should happen to the manual intervention step scoped to the QA channel?  In this scenario, it makes sense to exclude it.  However, what if the step ran an E2E test that QA wants to run on the other instance?
-- What should happen to the variable value scoped to the QA channel?  If the manual intervention step only uses it, it makes sense to exclude it, but if other steps use it, should that value be synced across or something else?
-
-### Tenants
-
-In Octopus Deploy, a Tenant is tied to both a Project and 1 to N Environments.  There are two data items to consider when mixing tenants and environments:
-
-- Not all tenants should be synced between instances.  It is common to have a different list of tenants on each instance.  There could be some overlap (typically with test tenants) or no overlap.  
-- The environments a tenant is scoped to for a project affect the Tenant Variables to copy over.
-
-For example, the source instance has **Development**, **Test**, **Staging** and **Production** and the destination instance has **Staging** and **Production**.  On the source instance, the Tenant **Internal** tied to all four environments and another tenant **Development Team A** is tied to **Development** and **Test**.  
-
-For this scenario, should both tenants be cloned?  It makes sense to sync the **Internal** Tenant and tie it to **Staging** and **Production** on the destination instance and not sync **Development Team A**.  For the **Internal** Tenant, should all the variables in **Staging** and **Production** for that Tenant be copied over as well?  Or, should you have to manually enter the values as they'll be different between instances?
-
-### Deployment and Runbook Processes
-
-A common use for environments is to scope them to steps in Deployment and Runbook Processes.  For example, the source instance has **Development** and **Test** with a manual intervention step scoped to **Test**.  That step pauses a deployment so the QA team can review the newly deployed release before starting their integration tests.  Should that step be included with the destination instance if it has **Staging** and **Production**?  There are valid use cases for both yes and no.
-
-- Yes, QA runs integration tests in **Staging**.  It should be cloned but scoped to run in **Staging**.
-- No, QA only runs integration tests in **Test**.  
-- Yes, QA needs to sign off on each release before promoting to **Production**.  It should be cloned but scoped to only run in **Staging**.
-- Yes, QA needs to sign off on each release in each environment after **Development**.  It should be cloned but configured to run in any environment.
-
-### Accounts and Certificates
-
-Both Accounts and Certificates are referenced by variables in either projects or variable sets.  They can be scoped to environments directly or by environment variable scoping.  
-
-Best practices recommend different AWS, GCP, and Azure accounts per environment or instance.  For example, an AWS account for **Non-Production** workloads and another account for **Production**.
-
-- Certificates can either be a wildcard, for example, `*.octopusdemos.app`, or tied to a specific domain and subdomain, for example, `mail.octopusdemos.app`.  We typically see either a different domain per environment, `testoctopusdemos.app` and `octopusdemos.app` or different subdomains, `test.octopusdemos.app` and `octopusdemos.app`.
-
-In most cases, it doesn't make much sense to sync Accounts and Certificates.  But the variables referencing the Accounts and Certificates are used in Deployment and Runbook processes.  You have a few options:
-
-- Create an Account or Certificate with the same name on each instance but different details.  You don't have to modify any variables.
-- Re-use the same variable name but associate it to different Accounts or Certificates.  The syncing process will only create new variables and insert dummy data.
-
-### Variable scoping
-
-Syncing variables between instances with different environments is very complex due to scoping and variable types.
-
-For all the examples below, the source instance has **Development** and **Test** while the destination instance has **Staging** and **Production**.  The source instance has the following variables.
-
-| Variable Name             | Value                                   | Scope       |
-| ------------------------- | --------------------------------------- | ----------- |
-| Application.Database.Name | `OctoFx-Dev`                            | Development |
-|                           | `OctoFX-Test`                           | Test        |
-| ConnectionString          | `Database=#{Application.Database.Name}` |             |
-
-Syncing `ConnectionString` as-is to the destination instance makes sense as it has no scoping.  You'll need to sync over the variable `Application.Database.Name` as `ConnectionString` references it.  But what about the values?  Those values are tied to environments that do not exist on the destination instance.  
-
-There are a couple of options.  Clone the variable values as-is with no environment scoping and then change the values after the sync.  That is useful when the destination instance has unique values per environment.  The initial sync would look like this:
-
-| Variable Name             | Value                                   | Scope |
-| ------------------------- | --------------------------------------- | ----- |
-| Application.Database.Name | `OctoFx-Dev`                            |       |
-|                           | `OctoFX-Test`                           |       |
-| ConnectionString          | `Database=#{Application.Database.Name}` |       |
-
-The downside to the above option is knowing the values to clean up.  Another option is to copy the variable name with text indicating that it needed replacing and exclude any scoping.  The initial sync would look like this:
+### Built-in role-based access control
 
-| Variable Name             | Value                                   | Scope |
-| ------------------------- | --------------------------------------- | ----- |
-| Application.Database.Name | `Replace Me`                            |       |
-| ConnectionString          | `Database=#{Application.Database.Name}` |       |
+Octopus Deploy provides fine-grained RBAC controls to allow for these common compliance scenarios:
 
-That only covers the initial sync.  Recurring syncs will add additional challenges, as there will be a combination of:
+- Developers can modify the deployment process, deploy to **Development**, **Test**, and **Staging** but not **Production**.
+- System admins can modify deployment targets in Octopus and deploy to **Production**, but cannot modify a deployment process.
+- An engineering team is permitted to modify the set of projects they own.  All other projects are read-only.
+- Release managers can modify the variables on a set of tenants assigned to them.  All other tenants are read-only.
 
-- Changed variable values
-- Changed variable scoping on existing variables
-- Additional variable values
-- New variables
-- Unchanged variables
+### Development, Testing, and Production targets connecting to the same Octopus instance
 
-The syncing process will need to compare the variable lists and determine the status of each variable.  The hardest challenge to solve is calculating which variables are "new" vs. existing with updated scoping.  That is because a variable can be scoped to 0 to N of these items:
+Often **Development**, **Testing**, **Staging** and **Production** deployment targets are hosted in isolated networks or VLANs.  This presents two concerns:
 
-- Environments
-- Channels
-- Process Owner (deployment process or runbooks)
-- Deployment Process Steps
-- Roles
-- Deployment Targets
-- Tenant Tags
+1. A single instance requires at least three cross-boundary connections.  
+2. It's possible misconfigure a **Development** deployment target for **Production** or vice versa.
 
-Some of those items, Tenant Tags, Roles, Process Owner, will be *exactly* alike between instances.  While other items, Environments, Channels, Deployment Process Steps, Deployment Targets, will be different.  
+To mitigate cross-boundary connections:
 
-For example, the variables on the source instance were changed from:
+- Host Octopus Deploy in a "neutral" internal network.  
+- Have a worker pools for each environment's network.  Those worker pools can only see the "neutral" network and targets in their environment.  
+- Create a [variable set](/docs/projects/variables/library-variable-sets), a worker pool variable, and scope each environment's worker pool to the appropriate environment.
 
-| Variable Name             | Value                                   | Scope       |
-| ------------------------- | --------------------------------------- | ----------- |
-| Application.Database.Name | `OctoFx-Dev`                            | Development |
-|                           | `OctoFX-Test`                           | Test        |
-| ConnectionString          | `Database=#{Application.Database.Name}` |             |
+To mitigate misconfigurations, leverage Octopus Deploy's built-in RBAC controls.  A person lacking **Production** permissions cannot add a new **Development** deployment target to **Production**.  They can only add and edit targets in environments where they have permissions.
 
-To this:
+To mitigate misconfigurations:
 
-| Variable Name             | Value                                      | Scope             |
-| ------------------------- | ------------------------------------------ | ----------------- |
-| Application.Database.Name | `OctoFx-#{Octopus.Environment.Name}`       |                   |
-| ConnectionString          | `Database=#{Application.Database.Name}`    | SQL-Server (role) |
-|                           | `Data Source=#{Application.Database.Name}` | Oracle (role)     |
+- A deployment targets using scripts instead of using the Octopus Deploy UI.
+- Use an API Key or Token of a [service account](/docs/security/users-and-teams/service-accounts) scoped to specific environments.
+- Limit who can modify deployment targets in all environments to a centralized administration team.
 
-The desired result on the destination instance will be:
+### Approval process
 
-- Leave `Application.Database.Name` alone.  
-- Add the scoping of `SQL-Server` to the `ConnectionString` variable with the value `Database=#{Application.Database.Name}`.
-- Add an additional `ConnectionString` option with the value set to `Data Source=#{Application.Database.Name}` and the scoping set to `Oracle`.
+If an approval is required for any deployment process going to **Production** then use [config as code feature](/docs/projects/version-control) as that integrates with git, which allows for branching and pull requests.  The main or primary branch is restricted from direct edits.  All changes to the deployment process are done in a branch and merged via a pull request.  
 
-Variable syncing is so complex because the rules for each project and variable scoping mismatch are different.  The syncing process will need some logic in it that you can configure.
+### Standards and Compliance
 
-- Should you ever overwrite values on the destination instance?
-- How to handle scoping mismatches.
-    - Options
-        - Skip the variable unless the scoping is an exact match.  For example, a variable on Dev/Test is scoped to the role `OctoFX-Web`; any variables with the same name would be ignored unless it is also scoped to `OctoFX-Web`.
-        - Skip the variable unless the scoping is a partial match.  For example, a variable is scoped to **Staging** and **Production** on a source instance with **Dev/Test/Staging/Prod**.  The destination instance only has **Production**.  Include the variable value because it is scope to one of the environments.
-        - Ignore mismatch.  Clone the value regardless of the scoping.
-        - Ignore mismatch on new but leave existing alone.  If the variable is new, ignore the mismatch; otherwise, leave everything as is.
-    - Potential Scoping Mismatches
-        - Environments: guaranteed to be different.
-        - Channels: will most likely be different.
-        - Process Owners: will be the same (unless runbooks are not synced).
-        - Deployment Process Steps: will most likely be the same (depends on the rules for syncing the deployment process)
-        - Roles: will be the same.
-        - Deployment Targets: guaranteed to be different.
-        - Tenant Tags: will most likely be the same.
+Requiring specific steps and ITSM approval is very common.  A separate **Production** instance that is "locked down" where only a handful of people can change the deployment process is no longer necessary with addition of Platform Hub.  
 
-## Handling different Tenants
+- [Process templates](/docs/platform-hub/templates/process-templates) enables centralized teams to create reusable sets of deployment steps that can be shared across multiple spaces in Octopus Deploy.
+- [Project templates](/docs/platform-hub/templates/project-templates) enables centralized teams to create compliant reusable project blueprints that teams can use as a starting point for new projects. Teams supply the required parameter values but can't modify the deployment process.
+- [Policies](/docs/platform-hub/policies) ensure required steps and templates are present along with ITSM approval.  They will fail any deployment that attempts to start that is noncompliant.
 
-It is common to have a different list of Tenants on each Octopus Deploy instance.  Unlike Environments, a different Tenant list is much easier to support in the syncing process.  Tenants are directly tied to the following in Octopus Deploy:
+### Performance improvement
 
-- Deployment Targets
-- Accounts
-- Certificates
-- Team User Role Scoping
-- Projects
+The final reason we hear about is to "speed up the deployment."  We typically hear this when Octopus is located in one data center and deployment targets are located in a data center in another country or continent.  That can lead to long package acquisition from the built-in repository and latency.
 
-### Deployment Targets
+- If package acquisition is taking a long time to transfer to the targets, consider:
+    - Enabling [delta compression for package transfers](/docs/deployments/packages/delta-compression-for-package-transfers) to reduce the amount of data to transfer.  
+    - Leveraging an external feed such as Artifactory, GitHub Packages, AWS CodeArtifact, or Feedz.io and configure Octopus to download the packages directly from the external feeds.
+- If there appears to be latency when running scripts on the Octopus Server to make database changes, run e2e tests, or any other similar task, then leverage [workers](/docs/infrastructure/workers).  Workers can execute tasks that don't need to run on individual deployment targets.  They can be located in the same data center as your database or applications.
 
-If a Tenant isn't synced between instances, chances are the deployment targets associated with that Tenant do not need to be synced either.  Deployment and Runbook processes do not reference deployment targets directly. Instead, they are referenced by the roles tied to the deployment target.  
+## Syncing is not cloning
 
-The one thing to watch out for is that it is possible to scope variables to specific deployment targets.  In that case, the best option is to skip the variable value unless there is a partial match.  For example, `Application.Database.Name` has the value `OctoFX-Tenant` scoped to `Machine1`, `Machine2`, and `Machine3` on the source instance.  That value should be skipped unless the destination instance has one of those deployment targets.
+Syncing is not the same as cloning.  Cloning an instance will result in an exact replica (or copy) of data from the source.  In addition to having all the same targets, environments, variables, tenants, projects, etc., the unique identifiers stored in the Octopus database will be the same; including the Server thumbprint and database master key.  Cloning is typically a one-time operation, such as standing up a new server.  
 
-### Accounts and Certificates
+Syncing instances involves copying projects and all required scaffolding data between Octopus Deploy instances with different environments, accounts, lifecycles, targets, tenants, or even variable values.  Each instance will have different ids, Server thumbprint, and database master key.
 
-Both Accounts and Certificates are referenced by variables in either projects or variable sets.  It is common to have different Accounts and Certificates per Tenant.
+## Tools and features to avoid
 
-In most cases, it doesn't make much sense to sync Accounts and Certificates.  But the variables referencing the Accounts and Certificates are used in Deployment and Runbook processes.  In this case, the best option is to re-use the same variable name but associate it with different Accounts or Certificates.
+Unfortunately, there is not first-class tooling available to support syncing two instances, due to the many decisions and business rules when working with different environments, tenants, variable values, etc.  In the past, our users have attempted to repurpose provided features and tooling to support their syncing process.  However, they were not designed for syncing use cases; the result was often frustration because of lack of customization, or hand editing files causing corrupted projects.
 
-### Team User Role scoping
+### Migrator and Export/Import Project
 
-The Team user role scoping is used for permissions.  For example, a team has access to edit a specific set of Tenants.  In this case, it makes sense to exclude any Tenants not found on the destination instance from the team user role scope.  It won't hurt anything as that Tenant doesn't exist.  Most likely, the list of Tenants that particular team has permission to edit will be very different.
+The [Migrator](/docs/administration/data/data-migration/) and the [Export/Import Project](/docs/projects/export-import) feature were designed to migrate or clone a project to another instance (or space for Export/Import Project).  The primary use case for both tools is that a user wants to move a project to a new instance and deprecate the older instance.  For example, when migrating from a self-hosted Octopus Server to Octopus Cloud.
 
-### Projects
+The Migrator and Export/Import Project feature can be run multiple times for the same project.  But they will ensure the source and destination instances match.  There is no way to exclude specific environments, tenants, or any specific data you wish to keep separate.  While it is possible to modify the JSON exported by those tools, such an approach is error-prone and unsupported.  
 
-The Tenant/Project relationship indicates that Tenant can deploy releases from that project to a specific set of Environments.  There is no impact if the Tenant doesn't exist on the destination instance.  The Tenant/Project relationship won't exist.
+### Config as Code
 
-## Handling different Deployment Targets
+Terraform uses Hashicorp Configuration Language or HCL.  The [Config as Code feature](/docs/projects/version-control) uses Octopus Configuration Language (OCL) and that is based on HCL.  To sync instances using these features, you'd need to use a comparison tool such as Beyond Compare to move changes between instances manually.  Anything manual is error-prone and will eventually fail.
 
-It is common to have a different list of Deployment Targets on each Octopus Deploy instance.  Deployment Targets are not referenced anywhere directly within Octopus Deploy outside of variable scoping.  
+You can write a tool to compare files between instances automatically and make the necessary modifications, but you'll be responsible to modify that tool if and when we add or remove properties in the OCL files.
 
-All other references are indirect; the role associated with a Deployment Target is how it is tied to a Deployment or Runbook process.  A Deployment or Runbook process can reference a role not associated with any Deployment Targets.  Each project has a setting to tell Octopus what to do when that happens, fail the deployment, or let it skip steps associated with that role.
+## Tooling to use
 
-For variable scoping, the best option is to skip the variable value unless there is a partial match.  For example, `Application.Database.Name` has the value `OctoFX-Tenant` scoped to `Machine1`, `Machine2`, and `Machine3` on the source instance.  That value should be skipped unless the destination instance has one of those deployment targets.
+We recommend creating a custom tool that leverages:
 
-## Ongoing maintenance
+- The [Octopus Terraform Provider](https://registry.terraform.io/providers/OctopusDeploy/octopusdeploy/latest) to store the desired state of the deployment process and other Octopus resources in git.
+- Or, the [Octopus Deploy REST API](/docs/octopus-rest-api), or one of the API wrappers, such as the [Octopus.Client .NET library](https://github.com/OctopusDeploy/OctopusClients), [Octopus Go API Client](https://github.com/OctopusDeploy/go-octopusdeploy), or the [TypeScript API Client](https://github.com/OctopusDeploy/api-client.ts).  
 
-Each new major/minor release of Octopus Deploy will require significant testing of your syncing process.  Along with fixing any bugs found because of an unexpected edge case.  
+If you opt to use the API, the Octopus team has written a sample PowerShell tool, [SpaceCloner](https://github.com/OctopusDeployLabs/SpaceCloner).  You can use it as a reference or example for your syncing process.  Keep in mind to use it as a reference as it was created with specific use cases in mind and probably won't support your hyper-specific use case.
 
-As you can see with all the rules and decisions from above, this is a complex problem requiring time and money to solve.  We only recommend syncing and splitting two instances when no other options are available.  
+Each new major/minor release of Octopus Deploy will require significant testing of your syncing process.  Along with fixing any bugs found because of an unexpected edge case.\
diff --git a/src/pages/docs/best-practices/platform-engineering/enterprise-patterns.md b/src/pages/docs/best-practices/platform-engineering/enterprise-patterns.md
index e28e780c35..232018cc97 100644
--- a/src/pages/docs/best-practices/platform-engineering/enterprise-patterns.md
+++ b/src/pages/docs/best-practices/platform-engineering/enterprise-patterns.md
@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2026-08-25
+modDate: 2026-08-27
 title: Octopus enterprise patterns
 description: This section describes common patterns for deploying octopus in enterprise environments.
 navOrder: 2
@@ -160,28 +160,6 @@ You can find more information about the [Octopus REST API in our documentation](
 | Supports geographically disperse teams/customers | ✓            |
 | Robust RBAC support                              | ✓            |
 
-## Managed instance per environment
-
-![Multiple environments diagram](/docs/img/platform-engineering/multiple-environments.png)
-
-This pattern creates Octopus installations in each environment. It treats Octopus upgrades and other maintenance tasks in the same manner as a regular application deployment by promoting the changes through environments like development, test, and production.
-
-You need to synchronize the Octopus installations to ensure their configuration is as similar to one another as possible.
-
-Unlike the previous patterns, this pattern is less concerned with providing the ability for teams and customers to log into Octopus installations. Rather, DevOps teams use non-production Octopus installations to test upgrades and validate project changes.
-
-This pattern may also be used to isolate Octopus installations for compliance reasons, such as PCI. Having a separate Octopus installation for the production environment makes it easy to demonstrate access controls and other security measures when undertaking
-security audits.
-
-| Feature                                          | Solves |
-| ------------------------------------------------ | ------ |
-| Independent projects, runbooks, dashboards etc   | N/A    |
-| Task execution guarantees for team/customer      | N/A    |
-| Shared authentication settings                   | N/A    |
-| Synchronized projects, runbooks, dashboards etc  | ✓      |
-| Supports geographically disperse teams/customers | N/A    |
-| Robust RBAC support                              | N/A    |
-
 ## Conclusion
 
 The patterns described in this section cover most implementations we expect enterprise customers will adopt as they scale their use of Octopus to support business units and customers.

From 6bdf8375745144bc7886751acd2aa3cdbbe550b8 Mon Sep 17 00:00:00 2001
From: Bob Walker <bob.walker@octopus.com>
Date: Thu, 27 Aug 2026 11:03:45 -0500
Subject: [PATCH 2/2] Some line edits

---
 src/pages/docs/administration/sync-instances/index.md     | 8 ++++----
 .../platform-engineering/enterprise-patterns.md           | 1 -
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/pages/docs/administration/sync-instances/index.md b/src/pages/docs/administration/sync-instances/index.md
index a404c4683d..b6abab6714 100644
--- a/src/pages/docs/administration/sync-instances/index.md
+++ b/src/pages/docs/administration/sync-instances/index.md
@@ -30,7 +30,7 @@ Typically the concerns are:
 - Separate VLANs or networks for each environment.
 - Specific steps are included for every **Production** deployment.
 
-Octopus Deploy includes functionality to mitigate those concerns.  That enables large banks, hospitals, retail companies, software vendors, insurance agencies, and government clients to have all environments on the same instance.
+Octopus Deploy includes functionality to mitigate those concerns.  That enables large banks, hospitals, retail companies, software vendors, insurance agencies, and government clients to have all environments on the same instance.  This page includes details on how to mitigate those concerns.
 
 Other unsuitable use cases for splitting instance include:
 
@@ -47,7 +47,7 @@ With the capabilities available in Octopus Deploy today, the only suitable scena
 
 For example:
 
-- A primary **Dev/Test/Staging/Production** instance running on a public cloud (e.g. Azure) with an isolated **Production** only instance for a set of targets hosted in a government cloud (e.g. Azure Gov).
+- A primary **Dev/Test/Staging/Production** instance running in a datacenter with an isolated **Production** only instance for targets with no physical network connections between the two instances.
 - Same scenario as above, but using multi-tenancy.  The primary instance and isolated instance have different tenants and targets.
 
 In both scenarios:
@@ -56,7 +56,7 @@ In both scenarios:
 - The same application is hosted in multiple **Production** environments.
 - A new release is created in the isolated instance to deploy those **Production** targets.
 
-The expectation is the source instance is the source of truth and the destination instance(s) contain copies of that data.  The syncing process will run periodically to ensure changes made on the source instance are added to the destination instance.
+The primary source instance is the source of truth and the isolated destination instance contain copies of that data.  The syncing process will run on a machine that has connectivity to both networks periodically.
 
 :::div{.hint}
 If you wish to do a one-time split of an instance and have no desire to keep anything in sync afterwards, then we recommend the [Export/Import Projects](/docs/projects/export-import) feature.  
@@ -64,7 +64,7 @@ If you wish to do a one-time split of an instance and have no desire to keep any
 
 ## Avoiding syncing multiple instances
 
-The syncing process is complex an requires constant care and maintenance.  Even if we provided a built-in tool, you'd still need to monitor and maintain the process.
+The syncing process is complex an requires constant care and maintenance.  Even if we provided a built-in tool, you'd still need to monitor and maintain the process.  It is not something we recommend, encourage, or can easily support.  In addition, Octopus Deploy includes functionality that mitigates most needs to split and sync instances.
 
 :::div{.hint}
 We've been asked if splitting environments, tenants or deployment targets by space is a safer alternative.  [Spaces](/docs/administration/spaces) are hard walls and do not allow the sharing of environments, projects, variable sets, step templates, script modules, deployment targets and more.  For all intents and purposes, a space is a unique instance.  Any problems you encounter when syncing instances will happen when trying to sync spaces.
diff --git a/src/pages/docs/best-practices/platform-engineering/enterprise-patterns.md b/src/pages/docs/best-practices/platform-engineering/enterprise-patterns.md
index 232018cc97..e1608ee397 100644
--- a/src/pages/docs/best-practices/platform-engineering/enterprise-patterns.md
+++ b/src/pages/docs/best-practices/platform-engineering/enterprise-patterns.md
@@ -176,4 +176,3 @@ The following patterns are implemented using the strategies documented in the [m
 
 - Managed space per business unit/application
 - Managed instance per business unit/region
-- Managed instance per environment