NavViewTZ — Metodolojia ya Vipimo (Metrics Methodology)

Toleo: 1.4
Tarehe: Septemba 2026
Hali: Nyaraka Inayoendelea (Living Document)

Hati hii ni rejeleo rasmi kwa kila kipimo cha kifedha ambacho NavViewTZ inakokotoa na kuonyesha. Inarekodi fomula iliyotumika, sababu za kuichagua badala ya zingine, na changamoto zinazojulikana. Inatumikia watazamaji watatu:

1. Wasanidi programu wanaotekeleza au kurekebisha enrich.performanceMetrics.js na interestRates.ts — ili mantiki ya hesabu isibadilike bila kuelewa kwa nini iliundwa hivyo.
2. Ukurasa wa mbele wa /methodology — hati hii ndiyo chanzo cha ukweli kwa kile watumiaji wanachosoma wanapouliza "hii imekokotolewaje?"
3. Wachangiaji wa siku zijazo — ili maamuzi ya muundo yaliyofanywa mapema yasibatilishwe kwa bahati mbaya.

Yaliyomo

1. Misingi ya Kimsingi
2. Sheria ya Alama mbili za Muda (Two-Timestamp Rule)
3. Sheria ya Muktadha Miwili (Two-Context Rule)
4. Tarehe ya Makubaliano ya Bei (Consensus Pricing Date)
5. Muda wa Data: Kuchelewa kwa Ripoti dhidi ya Data iliyopitwa na Wakati
6. Hesabu za Mapato
7. Kiwango Halisi cha Kila Mwaka (EAR)
8. Ubora wa Data & Viwango vya Kujiamini
9. Maelezo ya KPI — Ngazi ya 1 (Inaonekana Kila Wakati)
10. Maelezo ya KPI — Ngazi ya 2 (Ulinganisho & Uchambuzi)
11. Maelezo ya KPI — Ngazi ya 3 (Sifa za Mfuko)
12. Sehemu ya Soko & Vigawanyo vya Sekta (Market Share & Industry Denominators)
13. Mbinu Zisizofaa (Anti-Patterns) — Yale Ambayo Hatufanyi kwa Makusudi
14. Historia ya Mabadiliko (Changelog)

1. Misingi ya Kimsingi

Kila kipimo kwenye NavViewTZ kimeundwa kulingana na misingi mitatu isiyoweza kujadiliwa:

1.1 Thamani tupu (Null) ni uaminifu. Sufuri (0) si uaminifu.

Wakati hakuna historia ya kutosha kukokotoa kipimo, tunaonyesha — (null). Hatujawahi kuonyesha 0% wakati jibu halisi ni "hatujui." Mapato ya sifuri na mapato yasiyojulikana ni vitu viwili tofauti kabisa. Kuvichanganya kunapotosha watumiaji kufikiri mfuko hauna historia ya utendaji wakati kwa kweli data haipo bado.

1.2 Ulinganisho unahitaji nanga inayofanana.

Kiwango cha mapato kinachoonyeshwa peke yake (kwa mfano, kwenye ukurasa wa uchambuzi wa mfuko mmoja) kinaweza kunangwa kwenye data ya mfuko huo yenyewe. Lakini takwimu yoyote ya mapato inayotumika kulinganisha mifuko lazima inangwe kwenye marejeleo sawa ya kalenda. Vinginevyo unalinganisha vipindi tofauti vya muda na ulinganisho huo hauna usahihi wa hisabati, hata kama kila nambari ni sahihi yenyewe.

1.3 Onyesha hesabu zako.

Kila kipimo kinachoonyeshwa lazima kiweze kufuatiliwa hadi kwenye vyanzo vyake. Tarehe halisi ya kuanza, tarehe ya kumaliza, idadi ya siku, na thamani za NAV zilizotumiwa zinapaswa kupatikana kupitia tooltip. Mtumiaji anayetaka kuthibitisha nambari anapaswa kuwa na uwezo wa kufanya hivyo kila wakati. Hii ndiyo inayotofautisha jukwaa la data linaloaminika na sanduku la siri (black box).

2. Sheria ya Alama mbili za Muda (Two-Timestamp Rule)

Kila safu katika mfumo wa data wa NavViewTZ hubeba sehemu mbili za tarehe ambazo zina madhumuni tofauti kabisa. Kuzichanganya ndio chanzo kikuu cha makosa ya hesabu.

Kwa nini hii ni muhimu katika vitendo

Meneja wa mfuko anaweza kuchapisha matokeo ya NAV ya tarehe 12 Aprili mnamo tarehe 14 Aprili. Scraper yetu inaipata tarehe 14 Aprili na kuandika collected_at = April 14, date = April 12. Ukiangalia collected_at ili kuhukumu upya wa data, mfuko huu unaonekana ni wa sasa. Ukiangalia date, uko nyuma kwa siku 2. Sehemu ya date ndio ukweli. Tathmini ya kifedha ni ya tarehe 12 Aprili bila kujali tulikusanya lini.

Sheria: collected_at haitumiwi kamwe katika hesabu yoyote ya kifedha. Hesabu zote za mapato, ulinganisho, na viashiria vya upya wa data hutumia sehemu ya date pekee.

2.1 date si hali moja ya upya — AUM na utendaji hutofautiana

date hujibu swali "mfuko ulithaminiwa lini?" Haijibu swali "mapato ya mfuko huu yalikokotolewa hadi lini?" Hizo ni tarehe mbili tofauti kila mfuko unapochapisha mbele ya tarehe ya makubaliano (Sehemu ya 4), jambo ambalo kwa mchapishaji wa haraka hutokea takriban kila siku.

Mfuko unaweza kuwa na AUM ya tarehe 24 Agosti wakati mapato yake bado yamefungamanishwa na makubaliano ya tarehe 21 Agosti. Namba zote mbili ni sahihi. Kosa ni kuripoti hali moja ya upya kwa zote mbili — hilo humshawishi msomaji kuweka tarehe ya mapato kwa kutumia tathmini iliyotokea baada ya kipindi ambacho mapato hayo yalikokotolewa.

Sheria: kurasa za umma huchapisha sehemu zote mbili. Mapato hupewa tarehe na performance_as_of; kiwango cha AUM hupewa tarehe na aum_as_of. Hakuna inayochukua nafasi ya nyingine, na data_as_of peke yake haitoshi kuweka tarehe kwa chochote.

3. Sheria ya Muktadha Miwili (Two-Context Rule)

Kipimo kile kile cha mapato kinahitaji nanga tofauti za hesabu kulingana na mahali kinapoonyeshwa. Tunatofautisha muktadha miwili waziwazi.

Muktadha A — Kulenga Mfuko Pekee (Ukurasa wa uchambuzi wa mfuko mmoja)

Swali linalojibiwa: "Je, mfuko huu maalum umefanya nini?"

• Nanga ya mwisho: thamani ya hivi karibuni ya date ya mfuko yenyewe.
• Kipindi: hasa siku N za kalenda kabla ya nanga hiyo ya mwisho.
• Sababu: huongeza usahihi wa mfuko huo. Hakuna ulinganisho wa mifuko unaofanyika, kwa hivyo hatuhitaji nanga inayofanana ambayo ingeleta makadirio yasiyo sahihi.

end_date   = tarehe ya mwisho ya NAV ya mfuko
start_date = end_date − N siku za kalenda
return     = (NAV_end / NAV_start) − 1

Onyesho: "Mapato ya mwezi 1 kuanzia tarehe 12 Aprili" — tarehe ya kuanzia inaonyeshwa kila wakati.

Muktadha B — Ulinganisho (Jedwali la nyumbani, comparator, momentum pulse, viwango)

Swali linalojibiwa: "Mfuko huu unalinganishwaje na mingine hivi sasa?"

• Nanga ya mwisho: tarehe ya makubaliano ya bei (tazama Sehemu ya 4) — inayoshirikiwa katika mifuko yote.
• Mfuko ambao hauna data kwenye tarehe ya makubaliano hutumia NAV yake ya hivi karibuni zaidi ya tarehe hiyo au kabla yake, na huwekwa alama ya kuchelewa (staleness badge).
• Sababu: ikiwa "mapato ya mwezi 1" ya Mfuko A yanahusu tarehe 14 Aprili → 15 Machi, na ya Mfuko B yanahusu tarehe 10 Aprili → 11 Machi, kuyalinganisha upande kwa upande ni kulinganisha vipindi tofauti vya siku 30. Masoko yanaweza kubadilika ndani ya siku 4. Ulinganisho huo unapotosha.

end_date   = tarehe ya mwisho ya NAV ya mfuko tarehe ya makubaliano au kabla
start_date = tarehe_ya_makubaliano − N siku za kalenda
            (kisha pata tarehe ya NAV ya mfuko iliyo karibu zaidi na mwanzo huo)
return     = (NAV_end / NAV_start) − 1

Onyesho: Kichwa cha jedwali kinaonyesha "Mapato kuanzia [consensus_date]". Kila seli ya mfuko uliochelewa inaonyesha alama inayoonyesha ni siku ngapi uko nyuma.

3.3 Mkataba wa majina ya sehemu (Field naming convention)

Muktadha yote miwili inakokotolewa kwenye kila kazi ya uboreshaji na kuhifadhiwa kwenye hati moja. UI inachagua seti gani ya kuonyesha kulingana na mahali nambari inapoonekana.

Tofauti rahisi (zisizo za kila mwaka) zinafuata muundo huo huo: ret_1m dhidi ya ret_1m_act.

4. Tarehe ya Makubaliano ya Bei (Consensus Pricing Date)

Tarehe ya makubaliano ya bei ndiyo nanga ya mwisho inayoshirikiwa inayotumiwa kwa hesabu zote za kulinganisha. Inakokotolewa upya kila wakati mfumo wa uboreshaji wa data unapoendeshwa.

Algorithm

1. Soma sehemu ya `date` (tarehe ya NAV, si collected_at) kwa kila 
   mfuko kutoka _latestFundData.

2. Kwa kila tarehe ya mgombea D (kuanzia ya hivi karibuni, kurudi nyuma):
     hesabu = idadi ya mifuko ambayo tarehe yao ya mwisho iko ndani ya [D − 2, D]
     ikiwa hesabu / jumla_ya_mifuko >= 0.70:
       consensus_date = D
       break

3. Hifadhi consensus_date katika _enrichedFundData kama thamani moja ya metadata inayoshirikiwa.

Kwa nini 70% na siku ±2?

• 70%: Wengi rahisi haitoshi wakati mchapishaji mmoja anachelewa mara kwa mara. 70% inamaanisha makubaliano yanaonyesha soko kubwa. Ikiwa chini ya 70% ya mifuko inakubaliana kwenye tarehe yoyote, soko lenyewe limegawanyika na tarehe ya makubaliano inarudi nyuma hadi inapopata makubaliano.
• siku ±2: Wasimamizi wa mifuko ya CIS ya Tanzania wanachapisha kwa ratiba tofauti. Wengine wanachapisha siku hiyo hiyo, wengine siku inayofuata (T+1) au baada ya siku mbili (T+2). Dirisha la siku ±2 linakubali hili bila kuwa pana sana kiasi cha kufanya mfuko uliochelewa kwa siku 5 uonekane mpya.

Nini tarehe ya makubaliano SIYO

Tarehe ya makubaliano siyo "leo." Siyo "tarehe ambayo mifuko mingi ilikusanywa." Ni tarehe ya hivi karibuni zaidi ya NAV ambayo mifuko mingi ya soko imeainishwa kwayo. Katika siku ya kawaida ya biashara hii itakuwa T-1 au T-2 kwa sababu wasimamizi wa mifuko hawachapishi NAV za siku hiyo hiyo kila wakati.

5. Muda wa Data: Kuchelewa kwa Ripoti dhidi ya Data iliyopitwa na Wakati

Mfuko ambao tarehe yake (date) iko nyuma ya tarehe ya makubaliano unaweza kuwa katika moja ya hali mbili. Hizi zinawasilishwa tofauti kwa watumiaji.

5.1 Kuchelewa kwa Muundo wa Ripoti (inatarajiwa, kawaida)

Wasimamizi wengine wa mifuko wanachapisha kwa ratiba thabiti ya T+1 au T+2. Hii ni sera yao, si tatizo la ubora wa data. Karatasi ya metadata ya fundsOverview ina sehemu ya reporting_lag (kwa mfano, "T+1", "T+2") kwa kila mfuko.

Mfuko uko katika kuchelewa kwa muundo ikiwa:

days_behind_consensus <= reporting_lag_days

Matibabu ya UI: Alama ndogo ya habari. "Data kuanzia [tarehe] — mfuko huu unaripoti kwa ratiba ya T+2." Hakuna kengele ya hatari. Ni muktadha tu.

5.2 Data Iliyopitwa na Wakati Halisi (haikutarajiwa, chunguza)

Mfuko una data iliyopitwa na wakati ikiwa tarehe yake iko nyuma ya tarehe ya makubaliano kwa zaidi ya muda wake wa kawaida wa kuchelewa kuripoti:

days_behind_consensus > reporting_lag_days

Matibabu ya UI: Kiashiria cha njano au nyekundu (kulingana na ukali). "Sasisho la mwisho siku [N] zilizopita." Hii ni ishara inayopaswa kuonekana kwa watumiaji kwenye kadi ya mfuko pia.

Viwango vya kuchelewa (Staleness thresholds)

6. Hesabu za Mapato

6.1 Utafutaji wa tarehe ya marejeleo — kwa tarehe, si kwa nafasi ya safu

Usitafute NAV za kihistoria kwa nafasi ya safu (kwa mfano, "safu 5 nyuma = wiki 1"). Hii inaharibika kimyakimya wakati wowote mfuko unaporuka siku kutokana na wikendi, likizo, au hitilafu ya data.

Tafuta kwa tarehe ya kalenda na dirisha la ustahimilivu (tolerance window):

findNAV(targetDate, rows, toleranceDays = 3):
  tafuta safu kwa tarehe ya karibu zaidi d ambapo:
    d <= targetDate NA (targetDate − d) <= toleranceDays
  ikiwa imepatikana: rudisha NAV kwenye d, rekodi tarehe_halisi = d
  ikiwa haijapatikana: rudisha null (INSUFFICIENT)

Dirisha la ustahimilivu linapendelea tarehe za tarehe ya lengo au kabla yake (si baada) kwa sababu hatutaki kutumia NAV ya baadaye kukokotoa mapato yaliyopita.

6.2 Maelezo ya vipindi

end_anchor ni consensus_date kwa ajili ya Muktadha wa Ulinganisho na tarehe ya mwisho ya NAV ya mfuko yenyewe kwa Muktadha wa Kulenga Mfuko. Ustahimilivu na sheria ni sawa katika kesi zote mbili.

Kiwango cha chini cha historia kinazuia kuonyesha "mapato ya mwaka 1" yaliyokokotolewa kutoka kwa data ya miezi 2 tu. Katika hali kama hiyo, kipimo kinaonyeshwa kama — (INSUFFICIENT).

6.3 Fomula ya mapato rahisi

simple_return = (NAV_end / NAV_start) − 1

Mapato rahisi yanatumika kama thamani za kati tu. Hayaonyeshwi kwa watumiaji moja kwa moja (tazama Sehemu ya 7 kuhusu EAR).

7. Kiwango Halisi cha Kila Mwaka (EAR - Effective Annual Rate)

Kwa nini EAR, na si mapato rahisi

Mifuko ya CIS ya Tanzania hasa ni mifuko ya soko la fedha na mifuko ya dhamana. NAV yao inakua polepole na kwa uthabiti — ongezeko la kila siku la takriban 0.03%. Mapato rahisi ya mwezi 1 ya 0.95% ni sahihi lakini yanatoa ufahamu mdogo kwa mwekezaji anayeamua wapi pa kuweka akiba yake. Wanafikiria kwa masharti ya kila mwaka: "pesa yangu itapata nini mwaka huu?"

EAR inabadilisha mapato ya kipindi chochote kuwa sawa na kiwango cha mwaka, ikiruhusu ulinganisho sahihi bila kujali urefu wa kipindi.

Fomula

EAR = (1 + simple_return) ^ (365 / actual_days) − 1

Ambapo actual_days ni idadi halisi ya siku za kalenda kati ya tarehe za kuanza na kumaliza za NAV zilizotumiwa (si urefu wa kipindi cha lengo). Hii ni muhimu: ikiwa tarehe ya karibu zaidi inayopatikana kwa "siku 30 zilizopita" ni siku 28 zilizopita, tunatumia 28 kama kigawanyaji, si 30.

Mfano wa hesabu

Mfuko A: NAV tarehe 14 Aprili = 116.45
         NAV tarehe 15 Machi = 115.35  (siku 30 kabla, mechi kamili)

simple_return = (116.45 / 115.35) − 1 = 0.00954 = 0.954%
EAR           = (1.00954) ^ (365/30) − 1 = 0.1206 = 12.06%

Onyesho: "1M: 12.1% p.a."
Tooltip: "NAV 116.45 (Apr 14) dhidi ya 115.35 (Mar 15) · siku 30 · kwa mwaka"

EAR kwa vipindi vifupi (1D, 1W)

EAR inakuza mabadiliko ya vipindi vifupi sana. Mabadiliko ya NAV ya siku moja yakibadilishwa kuwa ya kila mwaka yanaweza kutoa nambari za kuvutia macho (chanya au hasi) ambazo hazina maana ya kweli. Sheria za kuonyesha:

• 1D: Onyesha EAR lakini weka lebo wazi kama "kila siku kwa mwaka — mabadiliko makubwa." Usitumie kwenye viwango vya mifuko.
• 1W: Onyesha EAR. Tumia kwa tahadhari katika viwango.
• 1M na zaidi: Kipimo kikuu. Tumia katika viwango vyote na ulinganisho.

8. Ubora wa Data & Viwango vya Kujiamini

Kila kipimo kilichokokotolewa hubeba kiwango cha kujiamini kinachoamua jinsi kinavyoonyeshwa.

Kiwango cha kujiamini kinahifadhiwa kwenye muundo wa data uliotajirishwa pamoja na thamani ili UI iweze kuonyesha ipasavyo bila kuhitaji kukokotoa upya.

9. Maelezo ya KPI — Ngazi ya 1 (Inaonekana Kila Wakati)

Haya yanaonekana kwenye kila kadi ya mfuko na jedwali kuu la dashibodi. Lazima yawe sahihi kabisa.

9.1 Kiwango Halisi cha Mapato ya Mwaka — 1M (kipimo kikuu)

Ni nini: Mapato ya kila mwaka katika kipindi cha hivi karibuni cha siku 30.

Kwa nini 1M ndio kuu: Kwa mifuko ya soko la fedha na dhamana, mabadiliko ya kila siku ni kelele tu. Utendaji wa kila mwezi ndio ishara fupi yenye maana kwa aina hizi za uwekezaji.

Fomula: EAR yenye siku 30 za kuangalia nyuma. Tazama Sehemu ya 7.

Lebo ya kuonyesha: "1M p.a." ikiwa na tooltip inayoonyesha tarehe halisi na NAV zilizotumiwa.

9.2 Mapato ya YTD (Year-To-Date)

Ni nini: EAR kuanzia Desemba 31 ya mwaka uliopita wa kalenda hadi tarehe ya makubaliano.

Kwa nini YTD: Wawekezaji kawaida wanafikiria kwa miaka ya kalenda. YTD ndio muundo unaojulikana zaidi katika mazungumzo ya kifedha ya kibinafsi.

Nanga ya kuanza: Desemba 31 ya mwaka uliopita. Ikiwa tarehe iko tarehe 5 Januari au kabla yake, tumia tarehe ya kwanza inayopatikana ya mfuko ya mwaka wa sasa ili kuepuka kipindi cha siku sifuri.

Fomula: EAR = (1 + simple_ytd) ^ (365 / days_since_jan1) − 1

9.3 Mapato ya Mwaka 1

Ni nini: EAR katika kipindi cha siku 365 zilizopita.

Kwa nini 1Y: Kipimo kikuu cha rekodi ya utendaji. Ndio kipindi pekee cha kutosha kunasa mzunguko kamili wa soko kwa mifuko hii.

Kiwango cha chini cha historia: Data point 300. Chini ya hii, onyesha —.

Fomula: EAR yenye siku 365 za kuangalia nyuma. Tazama Sehemu ya 7.

9.3a Wastani wa Soko — Uliopimwa kwa NAV

Ni nini: KPI ya Avg NAV Return (1Y) kwenye ukurasa wa nyumbani — kipimo kimoja kinachowakilisha mapato ya soko kwa ujumla.

Kwa nini upimwe kwa NAV: Wastani wa kawaida (arithmetic mean) hutendea mfuko mdogo wa TZS 5 bn sawa na mfuko mkubwa wa TZS 500 bn. Lengo la kipimo hiki ni kuonyesha mapato ya shilingi ya wastani iliyowekezwa sokoni, si ya mfuko wa wastani. Kwa hivyo mapato ya kila mfuko yanapimwa kwa NAV yake.

Fomula:

avg_nav_return_1y = Σ (nav_total_i × ret_1y_i) / Σ nav_total_i

kwa mifuko ambapo nav_total > 0 na ret_1y ipo.

Mifuko isiyojumuishwa:

1. Mifuko ya NAV isiyobadilika (mf. sanlam.pesammf, sanlam.usdFixedIncome) haijumuishwi. Mifuko hii hudumisha nav_per_unit kwenye 1 na hulipa mapato kama vipande vya ziada (units), hivyo ret_1y inayotokana na NAV ni ≈0% hata wakati mwekezaji anapata riba. Kuijumuisha kungesukuma wastani kuelekea 0 na kupotosha taswira ya soko. Orodha ya mifuko hii inapatikana kwenye src/utils/fundClassification.ts.
2. Mifuko isiyokuwa na nav_total, yenye nav_total ≤ 0, au isiyokuwa na ret_1y huachwa kwenye hesabu.

Kama hakuna mfuko unaofaa, onyesha — badala ya 0% au NaN%.

Kumbuka: Majedwali ya mfuko mmoja-mmoja (orodha ya nyumbani, ulinganishi, ripoti ya wiki) bado yanaonyesha ret_1y ya kila mfuko. Ni wastani wa kiwango cha soko pekee ndio unaopimwa kwa NAV.

9.4 Kiashiria cha Upya wa Data

Ni nini: Ishara ya kuona inayoonyesha jinsi data ya sasa ya NAV ya mfuko ilivyo, ikilinganishwa na tarehe ya makubaliano ya bei.

Kwa nini ni Ngazi ya 1: Kiwango cha mapato kinaaminika tu kama data yake ya msingi. Mwekezaji anayelinganisha mifuko anastahili kujua kuwa mapato ya mfuko mmoja ya leo yanategemea data ya siku 5 zilizopita.

Hesabu:

days_behind = consensus_date − tarehe ya mwisho ya NAV ya mfuko

Uchoraji wa picha (Visual mapping): Tazama viwango vya staleness vya Sehemu ya 5.

Muhimu zaidi: Hii hutumia sehemu ya date (tarehe halisi ya NAV), na kamwe haitumii collected_at (muda wa kusanya).

10. Maelezo ya KPI — Ngazi ya 2 (Ulinganisho & Uchambuzi)

Haya yanaonekana kwenye jedwali la kulinganisha, mtazamo wa uchambuzi, na momentum pulse.

10.0 Sparkline (siku 7)

Ni nini: Mfululizo mdogo wa thamani za NAV kwa kila kitengo zinazotumiwa kuchora chati ndogo kwenye kila kadi ya mfuko.

Kipindi: Kuanzia mwanzo wa kipindi halisi cha wiki 1 ya mfuko huo (w1.start_date kutoka kwa vipimo vya Kulenga Mfuko) hadi tarehe ya mwisho ya NAV ya mfuko huo, kuanzia ya zamani zaidi.

Mbadala (Fallback): Ikiwa hakuna data ya kutosha kwenye dirisha hilo (kwa mfano, pengo la data), safu 2 za mwisho za NAV zinazopatikana zinatumika ili chati isiwe tupu.

10.1 Mapato ya Miezi 3

Ni nini: EAR katika kipindi cha siku 91 zilizopita.

Kwa nini ongeza 3M: Robo mwaka ni kitengo cha kawaida cha ripoti kwa wawekezaji wa taasisi na waandishi wa habari wa kifedha. Pia inanasa mifumo ya msimu ambayo 1M inaikosa.

10.2 Ugeugeu / Volatility (siku 30)

Ni nini: Mkengeuko wa kawaida (standard deviation) wa mabadiliko ya asilimia ya NAV ya kila siku katika siku 30 zilizopita.

Kwa nini ni muhimu: Mifuko miwili yenye mapato sawa ya 1Y sio sawa ikiwa mmoja unakua vizuri na mwingine unayumba sana. Ugeugeu ndio kipimo rahisi zaidi cha tofauti hii. Kwa mifuko ya soko la fedha, wawekezaji wanatarajia ugeugeu wa karibu sifuri.

Fomula:

daily_returns = [(NAV[i] / NAV[i-1]) − 1 kwa kila jozi mfululizo katika siku 30 zilizopita]
volatility    = mkengeuko_wa_kawaida(daily_returns) × sqrt(252)  [kwa mwaka]

Onyesho: Kama asilimia. Lebo ya "Chini / Kati / Juu" kwa watumiaji wa kawaida, na % halisi kwenye tooltip.

10.3 Kupungua kwa Juu / Maximum Drawdown (muda wote)

Ni nini: Kupungua kwa kiwango kikubwa zaidi kutoka kwenye kilele hadi chini kabisa katika historia ya mfuko mzima.

Kwa nini ni muhimu: Inajibu swali: "Je, ni hasara gani kubwa zaidi ambayo mfuko huu umewahi kumpa mwekezaji?" Kwa mifuko ya soko la fedha hii inapaswa kuwa karibu na sifuri.

Fomula:

peak = running maximum ya NAV_per_unit hadi kila tarehe
drawdown[i] = (NAV[i] − peak[i]) / peak[i]
max_drawdown = minimum(drawdown)   [thamani hasi zaidi]

Onyesho: Kama asilimia hasi. Thamani ya -0.3% inamaanisha mfuko uliwahi kushuka kwa 0.3% kutoka kiwango chake cha juu cha kihistoria.

10.4 Alama ya Uthabiti (Consistency Score)

Ni nini: Asilimia ya miezi ya kalenda ambayo mfuko ulipata mapato chanya, yaliyokokotolewa katika historia yake yote inayopatikana.

Kwa nini ni muhimu: Inapima uaminifu wa mfuko katika nambari moja ambayo watumiaji wanaielewa kwa urahisi.

Fomula:

monthly_returns = mapato kwa kila mwezi kamili wa kalenda katika historia ya mfuko
consistency     = idadi(monthly_returns > 0) / idadi(monthly_returns)

Kiwango cha chini cha historia: Miezi 12 kamili ya kalenda.

10.5 Mwenendo wa AUM (Miezi 3)

Ni nini: Mabadiliko ya asilimia katika nav_total (jumla ya mali zinazosimamiwa) katika siku 91 zilizopita.

Kwa nini ni muhimu: Ukuaji wa AUM unaonyesha imani ya wawekezaji. Hili siyo kipimo cha mapato — ni kipimo cha afya ya mfuko.

Fomula: Mabadiliko ya asilimia rahisi kwenye nav_total, si kwa mwaka.

aum_trend_3m = (nav_total_leo / nav_total_siku_91_zilizopita) − 1

10.6 Mabadiliko ya AUM na Vitengo (AUM Change & Units Change)

Ni nini: Mabadiliko rahisi ya asilimia (si ya kila mwaka) katika nav_total na units_outstanding, yaliyokokotolewa kwa vipindi vyote (1D/1W/1M/3M/YTD/1Y) kwa kutumia injini ile ile ya utafutaji wa tarehe na ngazi za kujiamini (EXACT/APPROXIMATE/STALE/INSUFFICIENT) kama ret_* (§6, §8) — ikitumika kwa nav_total/units_outstanding badala ya nav_per_unit. Muktadha yote miwili ipo, sawa na mapato: jina la kawaida = Makubaliano (aum_chg_1m), kiuambishi _act = Kulenga Mfuko (aum_chg_1m_act).

Kwa nini hizi ndizo msingi, si makadirio. Zote mbili zinakokotolewa moja kwa moja kutoka kwa data iliyochapishwa — hakuna dhana, hakuna uigaji. Ikiwa vitengo vinabadilika kutoka 1.00bn hadi 1.08bn, tunaweza kusema kwa uhakika kamili: "vitengo vilivyopo +8.0%." Hilo ni tamko lenye nguvu zaidi kuliko "wawekezaji waliweka TZS 8bn kwenye mfuko huu," ambalo linahitaji kudhania tabia ya mwekezaji kutoka kwa hesabu ghafi. Pendelea kuonyesha units_chg_* kwanza kwenye UI yoyote inayoonyesha safu hii — ndicho kinachohitaji uigaji mdogo zaidi katika mfumo huu mzima.

Fomula:

aum_chg   = (nav_total_mwisho / nav_total_mwanzo) − 1
units_chg = (units_outstanding_mwisho / units_outstanding_mwanzo) − 1

Hakuna toleo la EAR — kufanya mabadiliko ya AUM au vitengo kuwa ya kila mwaka kunazidisha kelele kuliko manufaa yanayopatikana.

Uhusiano na aum_trend_3m (§10.5): fomula na dirisha sawa — aum_chg_3m inachukua nafasi ya aum_trend_3m. Sehemu ya zamani inabakizwa kwa uoanifu wa nyuma; watumiaji wapya wasome aum_chg_3m.

10.7 Mchango Uliokadiriwa wa Fedha na Kiwango Kilichokadiriwa cha Ukuaji wa Asili

Ni nini — safu ya kwanza ya makadirio. Kila kitu kilicho hapo juu ni data iliyochapishwa au hesabu ya moja kwa moja juu ya nambari zilizochapishwa. Mchango Uliokadiriwa wa Fedha (Estimated Net Flow) ni nambari ya kwanza inayohitaji dhana: inakadiria fedha halisi za wawekezaji (usajili ukiondoa uondoaji) kwa kuuliza "AUM ya mfuko huu ingekuwa nini leo kama utendaji ndio kitu pekee kilichoibadilisha — na nambari halisi iko mbali kiasi gani na hiyo?"

Fomula:

expected_aum = units_outstanding_mwanzo × nav_per_unit_mwisho
net_flow     = nav_total_mwisho − expected_aum

Kiwango Kilichokadiriwa cha Ukuaji wa Asili kinaonyesha fedha hiyo hiyo kama asilimia ya mali za mwanzo — fasili ya kimtindo cha Morningstar:

organic_growth_rate = net_flow / nav_total_mwanzo

Hii SIYO mapato ya NAV-kwa-kitengo — hiyo ingekuwa ret_3m tena kwa jina tofauti (toleo la awali la hati hii lilifanya kosa hilo hasa; tazama kumbukumbu ya mabadiliko ya v1.3). Ukuaji wa asili hapa unamaanisha ukuaji unaotokana na fedha zinazoingia, ukionyeshwa kulingana na ukubwa wa mfuko.

Sehemu zote mbili zinakokotolewa kwa vipindi vyote sita, muktadha yote miwili (jina la kawaida = Makubaliano, _act = Kulenga Mfuko), sawa na §10.6.

Uonyeshaji — weka lebo isiyo na shaka kama makadirio. Kamwe usionyeshe kama takwimu iliyoripotiwa na meneja:

Mchango Uliokadiriwa wa Fedha: + TZS 4.7bn Makadirio ya NavViewTZ kutokana na mabadiliko ya NAV ya mfuko, NAV/kitengo na vitengo vilivyopo.

Kidokezo — hiki ni makadirio, si kumbukumbu rasmi. Hatuna ufikiaji wa kumbukumbu halisi za usajili/uondoaji za wasimamizi wa mifuko. Ichukulie kama dalili, si nambari kamili.

Hali za null (sehemu zote mbili): msingi usio wa nav_return; mpaka wa AUM au vitengo kwa kipindi hicho ni INSUFFICIENT; au mipaka hiyo miwili inatatua tarehe tofauti za mwanzo/mwisho.

10.8 Flow Share of AUM Growth — YA NDANI TU, si kipimo cha umma

Ni nini: net_flow / ΔAUM — ni sehemu gani ya mabadiliko halisi ya AUM katika kipindi hicho inayotokana na fedha badala ya utendaji.

Kwa nini haichapishwi. Ni makadirio (net_flow) likigawanywa na kiasi kingine chenye kelele na kinachoweza kuwa karibu na sifuri (ΔAUM). Mabadiliko madogo katika nambari yoyote yanaweza kutoa asilimia za ajabu:

AUM inaanza kwa 100bn. Utendaji unaongeza +5bn. Wawekezaji wanaondoa −4bn. AUM ya mwisho = 101bn. ΔAUM = +1bn. Mchango uliokadiriwa wa fedha = −4bn. Flow share = −4 / 1 = −400%

Sahihi kihesabu, lakini msomaji wa kawaida hataelewa vizuri.

Mahali inapohifadhiwa: inakokotolewa na kuandikwa kwenye /funds/{id} na /funds/{id}/enriched/{date} kwa kila uboreshaji, kwa ajili ya mtazamo wa ndani wa baadaye. Imeachwa kimakusudi kutoka publicExports.ts na briefing.ts — haionekani kamwe kwenye API ya umma, taarifa ya AI, au jibu lolote la zana ya MCP.

Muundo wa umma, kwa rejea (kuaminika zaidi → makadirio zaidi):

11. Maelezo ya KPI — Ngazi ya 3 (Sifa za Mfuko)

Hizi hasa ni static metadata kutoka kwenye fundsOverview. Zinaelezea mfuko ni nini, si jinsi ulivyofanya kazi.

12. Sehemu ya Soko & Vigawanyo vya Sekta (Market Share & Industry Denominators)

Ukuaji wa AUM wa kila mfuko tayari unachapishwa (§10.6). Kuubadilisha kuwa sehemu ya soko (market share) kunahitaji kitu ambacho NavViewTZ bado haikitoi: jumla ya AUM ya sekta nzima katika kila tarehe ya kulinganisha.

Δ sehemu ya soko = AUM_mfuko,t1 / AUM_sekta,t1
                 − AUM_mfuko,t0 / AUM_sekta,t0

Sehemu ya juu (numerator) imeshatatuliwa. Kigawanyo (denominator) ndio ugumu wote, na kila njia ya kukikosea hutoa namba inayoonekana sahihi lakini ni ya uongo. Sehemu hii inarekodi maamuzi yaliyofanywa kabla ya utekelezaji.

12.1 Kigawanyo hufungamanishwa na tarehe ya makubaliano. Daima.

Kuna jumla mbili zenye maana, na haziwezi kubadilishana.

Sheria: Δ sehemu ya soko hukokotolewa kutoka jumla za makubaliano pekee. Jumla ya "hivi punde" haitolewi kamwe dhidi ya jumla nyingine.

Jumla ya "hivi punde" ni jopo lisilo sawa (ragged panel) — kila mfuko umethaminiwa kwa tarehe yake mwenyewe — hivyo jumla yake si ya tarehe yoyote. Kutoa jopo moja lisilo sawa kutoka jingine hutengeneza mwendo wa sehemu ya soko kutokana na muda wa kuchapisha pekee. Mfuko ulio kwenye T−0 ndani ya kigawanyo kilichofungamanishwa kwa T−3 hupewa sifa ya siku tatu za ukuaji wake mwenyewe ambazo hakuna mfuko mwingine aliyepewa. Hili si suala la kuzungusha namba: mifuko inayochapisha haraka mara nyingi ndiyo inayokua kwa kasi, hivyo kasoro hii huambatana na ishara ileile ambayo kipimo kinakusudia kugundua. Ingethibitisha dhana hata kama dhana yenyewe si kweli.

Jumla za "hivi punde" pia haziwezi kurudiwa. Mfuko mmoja unaochelewa ukijaza data yake ya nyuma hubadilisha kimyakimya kigawanyo cha t0 cha kihistoria baada ya kuchapishwa. Jumla za makubaliano hazibadiliki kwa muundo wake — /funds/{id}/enriched/{ret_as_of} inatumia tarehe ya kufungamanisha kama kitambulisho, hivyo kigawanyo cha tarehe fulani hubaki kilekile kikishaandikwa.

12.2 Kigawanyo kimoja kwa kila sarafu. Hakuna kuchanganya.

Sheria: sehemu ya soko hukokotolewa ndani ya kundi la sarafu moja. Mifuko ya TZS haijumuishwi kamwe na ya USD, na hakuna ubadilishaji wa fedha za kigeni (FX) unaotumika kujenga kigawanyo cha pamoja.

Kigawanyo kilichobadilishwa kwa FX hufanya sehemu ya soko isogee pale shilingi inaposogea. Mfuko wa TZS ungeweza kuonyesha "ongezeko" la sehemu wakati wa kushuka kwa thamani ya shilingi bila hata uwekezaji mmoja mpya, kwa sababu mifuko ya USD ilipungua ikipimwa kwa TZS. Hiyo ni kasoro ya FX iliyovaa vazi la ishara ya mtiririko wa fedha.

Muundo ni ramani yenye funguo (keyed map), si sehemu maalum kwa kila sarafu:

industry_totals: Record<string, IndustryTotal>   // "TZS", "USD", "UNKNOWN"

Sehemu tuli za total_aum_tzs / total_aum_usd zilikataliwa. Zinabana orodha ya sarafu za leo ndani ya mkataba wa data, hivyo kuongeza mfuko wa sarafu ya tatu kungevunja mkataba kwa kila mtumiaji; haziwezi kuwakilisha kundi la UNKNOWN ambalo largest_funds_by_currency tayari linabeba; na kila jumla inahitaji taarifa zake za kundi (§12.3), ambazo sehemu tuli zingeweza kuwakilisha tu kwa kuzidisha kuwa total_aum_tzs_fund_count, total_aum_tzs_imputed_count na kadhalika. Ramani yenye funguo pia inalingana na muundo ambao briefing.summary.largest_funds_by_currency tayari unautumia, na inafanya sheria kuwa ya kimuundo: hakuna sehemu ambayo mtumiaji angeweza kuiongeza kwenye nyingine.

12.3 Mabadiliko ya wigo hutangazwa, hayafichwi

"Sekta" ya NavViewTZ ni kundi la mifuko ambayo NavViewTZ inaifuatilia. Kundi hilo hukua — Ushindi na Thamani ziliongezwa Agosti 2026. Jumla isiyo makini huhesabu kuongezwa kwa mfuko kama ukuaji wa sekta, hivyo sehemu ya kila mfuko uliokuwepo hushuka siku hiyo kwa kiasi kisichotofautishwa na hasara halisi ya sehemu ya soko.

Sheria: Δ sehemu ya soko hukokotolewa juu ya kundi lisilobadilika (fixed cohort) — mifuko iliyokuwepo katika t0 na t1 vyote. Mfuko usiokuwepo katika mojawapo ya tarehe hizo huondolewa kwenye sehemu ya juu na kigawanyo kwa ulinganisho huo.

Kwa hiyo kila jumla inayochapishwa hubeba kitambulisho cha kundi lake:

Δ iliyokokotolewa kati ya cohort_id mbili tofauti si mabadiliko ya sehemu ya soko na lazima iitwe mabadiliko ya wigo badala yake. Vigawanyo vya kihistoria havibadiliki: kuongeza mfuko mpya hakubadilishi tarehe za nyuma. Mfululizo huonyesha mkato uliorekodiwa badala ya historia iliyoandikwa upya kimyakimya.

Kwa uhalisia kundi la mifuko inayofuatiliwa hukua mara kadhaa kwa mwaka, hivyo madirisha mengi yenye manufaa yana tukio la kuongezwa kwa mfuko, na kukataa kabisa kungejibu chochote. fixedCohort hupunguza pande zote mbili kubaki na mifuko iliyothaminiwa katika tarehe zote mbili kabla ya jumla kujengwa, hivyo cohort_id hulingana kwa muundo wake. Δ inayotokana hujibu swali finyu zaidi — jinsi sehemu za mifuko hii kwenye AUM yao ya pamoja zilivyobadilika — na vitambulisho vilivyoachwa nje huchapishwa pamoja nayo. Kigawanyo si soko lote linalofuatiliwa pale mifuko yoyote inapoachwa nje, na ukurasa unaoficha ukweli huo umerudi kuripoti kuwasili kwa mfuko mpya kama hasara ya mfuko uliokuwepo.

12.4 Washiriki waliochelewa husongeshwa mbele, na makadirio huchapishwa

Mfuko ulio nyuma ya tarehe ya makubaliano hauna NAV siku hiyo. Hakuna suluhu isiyo na gharama: kuuondoa hupunguza kigawanyo na kuongeza sehemu ya kila mfuko mwingine; kusongesha thamani yake ya mwisho mbele hupunguza ukuaji wa sekta na kuongeza sehemu kwa njia tofauti.

Sheria: songesha mbele NAV ya mwisho ya mshiriki iliyopo kabla au siku ya kufungamanisha, ndani ya kikomo cha STALE_HARD_CAP_DAYS (30, sawa na utafutaji wa NAV wa §6.1). Zaidi ya kikomo hicho mfuko huondoka kwenye kundi. Kila jumla hutangaza ni kiasi gani chake ni cha makadirio.

Tofauti kati ya jozi hizi mbili ni muhimu kuliko inavyoonekana. Tarehe ya kufungamanisha ni ya hivi punde inayofikia akidi ndani ya dirisha la siku ±2 (§4), hivyo mara nyingi ni tarehe ambayo mifuko mingi bado haijaifikia — siku ya kawaida wengi wao huwa kwenye anchor−1. Ikipimwa kwa data halisi ya tarehe 2 Septemba 2026, alama ya kusongesha mbele iliyofafanuliwa kama "tarehe ya tathmini ≠ anchor" iliweka 96% ya kigawanyo cha TZS kama makadirio, na kati ya hao wote isipokuwa wawili walikuwa nyuma kwa siku moja tu. imputed_aum ni kweli kihalisi lakini haina msaada peke yake; stale_imputed_aum ndiyo ya kuchukulia hatua.

Kusongesha mbele kumechaguliwa badala ya kuondoa kwa sababu sheria ya kundi (§12.3) tayari inalinda ulinganisho, na kundi thabiti la washiriki ni muhimu zaidi kwa kigawanyo kuliko usahihi mdogo wa mfuko mmoja uliochelewa. Sehemu za kutangaza zipo ili mtumiaji aweze kuamua kama upotoshaji huo una umuhimu kwa swali lake, badala ya uamuzi huo kufanywa kwa niaba yake.

12.5 Vigawanyo vya makundi hubandikwa, havikokotolewi wakati wa kusoma

Sehemu ya kundi la MMF ni takwimu yenye manufaa zaidi kuliko sehemu ya CIS yote. Pia ni dhaifu zaidi: kama uanachama wa kundi utakokotolewa wakati swali linapoulizwa, basi kubadilisha kundi la mfuko mmoja huandika upya kila sehemu ya kihistoria ya kundi hilo.

Sheria: uanachama wa kundi hubandikwa kwenye snapshot wakati wa uboreshaji (enrichment) na husomwa kutoka hapo, haukokotolewi upya kutoka taarifa za sasa.

Kumbuka performance_basis kwa sasa inatumika pia kama kiwakilishi cha mifuko ya NAV isiyobadilika (fundClassification.ts). Haipaswi kuwa pia ufunguo wa kundi — sehemu inayohudumia mabwana watatu haiwezi kubadilishwa kwa ajili ya mmoja wao.

12.6 Sehemu ya soko huripotiwa kwa basis points

Sheria: Δ sehemu ya soko huelezwa kwa basis points (bp), Δ share na share hazielezwi kamwe kama asilimia ya mabadiliko ya nyingine, na wala hazionyeshwi kando ya asilimia ya ukuaji wa AUM bila kipimo chake.

"+42.4% ukuaji wa AUM" na "+80 bp sehemu ya soko" hujibu maswali tofauti na hazishiriki kipimo chochote. Wakala anayesoma briefing atazichanganya kama data itaruhusu. Mfuko unaweza kukua kwa AUM kwa nguvu na bado kupoteza sehemu ya soko.

13. Mbinu Zisizofaa (Anti-Patterns) — Yale Ambayo Hatufanyi kwa Makusudi

Mbinu hizi zilizingatiwa na kukataliwa. Kuzirekodi kunazuia wachangiaji wa siku zijazo kuzileta tena.

❌ Utafutaji wa kihistoria kwa kutumia nafasi ya safu (Index-based lookups)

// MAKOSA — inaharibika wakati wowote kunapokuwa na pengo la siku
const nav1w = rows[rows.length - 6][3];

// SAHIHI — kwa tarehe maalum na dirisha la ustahimilivu
const nav1w = findNAV(endDate - siku 7, rows, tolerance = 3);

❌ Kujumlisha AUM ya hivi punde ya kila mfuko kuwa kigawanyo cha sehemu ya soko

// MAKOSA — jopo lisilo sawa; jumla yake si ya tarehe yoyote
const sekta = funds.reduce((t, f) => t + f.nav_total, 0);
const sehemu = fund.nav_total / sekta;

// SAHIHI — kila mshiriki amethaminiwa kwa tarehe moja
const sekta = cohort.reduce((t, f) => t + navAt(f, performanceAsOf), 0);

Kutoa jumla moja kutoka nyingine hutengeneza mwendo wa sehemu ya soko kutokana na muda wa kuchapisha, na kasoro hiyo huwapendelea wachapishaji wa haraka — ambao mara nyingi ndio mifuko inayokua kwa kasi. Ona §12.1.

❌ Kuruhusu mfuko mpya kupunguza sehemu za kihistoria

// MAKOSA — kila mfuko uliokuwepo "hupoteza sehemu" siku ya kuongezwa
const sehemu = fund.nav_total / jumlaYaMifukoYoteTunayofuatiliaSasa;

// SAHIHI — kundi lisilobadilika, lililopo katika tarehe zote mbili
const cohort = fundsPresentAt(t0).filter((f) => presentAt(f, t1));

Ukuaji wa wigo si ukuaji wa sekta. Δ inayovuka makundi mawili tofauti ni mabadiliko ya wigo, si mabadiliko ya sehemu ya soko, na lazima iitwe hivyo. Ona §12.3.

❌ Kuchanganya sarafu kuwa jumla moja ya sekta

// MAKOSA — sehemu ya soko sasa husogea pale shilingi inaposogea
const sekta = tzsFunds.total + usdFunds.total * fxRate;

// SAHIHI — kigawanyo kimoja kwa kila sarafu, hakuna ubadilishaji
const sekta = industryTotals[fund.currency];

Mfuko wa TZS ungeonyesha ongezeko la sehemu wakati wa kushuka kwa thamani ya shilingi bila hata uwekezaji mmoja mpya. Ona §12.2.

❌ Kutumia collected_at kwa upya wa data au hesabu

// MAKOSA — huu ni muda tuliokusanya data sisi, si wakati NAV ilipotolewa
const isStale = (today - row.collected_at) > siku 3;

// SAHIHI — tumia tarehe halisi ya toleo la NAV
const isStale = (consensusDate - row.date) > reportingLagDays;

Mfuko uliokusanywa leo lakini ukiwa na tarehe (date) ya siku 4 zilizopita ni mfuko uliochelewa.

❌ Kuonyesha mapato rahisi bila kuyafanya ya kila mwaka (EAR) kwenye ulinganisho

// MAKOSA — mapato ya 1M rahisi hayawezi kulinganishwa na mapato ya 1Y ya rahisi
ret_1m = 0.95%    // inaonekana ndogo sana
ret_1y = 11.8%    // inaonekana kubwa sana

// SAHIHI — yote yanaonyeshwa kama EAR (kwa mwaka)
ret_1m_ear = 12.1% p.a.   // sasa yanalinganishwa moja kwa moja
ret_1y_ear = 11.8% p.a.   // sasa yanalinganishwa moja kwa moja

Hati hii inapaswa kusasishwa kila hesabu inapobadilika. Tarehe na toleo lililo juu lazima lionyeshe hali ya sasa. Ikiwa fomula imebadilishwa, fomula ya zamani na sababu ya mabadiliko zinapaswa kuandikwa hapa chini.

14. Historia ya Mabadiliko (Changelog)

v1.4 — Septemba 2026

• Imeongezwa §2.1 — utenganisho wa aum_as_of / performance_as_of. date ilikuwa ikitumika kama hali moja ya upya kwa maswali mawili tofauti, hivyo mfuko ungeweza kuonyesha AUM ya tarehe 24 Agosti dhidi ya mapato yaliyofungamanishwa na makubaliano ya tarehe 21 Agosti bila chochote kinachozitofautisha. Sehemu zote mbili sasa zinachapishwa kwenye /api/v1/briefing, zana ya MCP get_market_briefing, na zana ya WebMCP.
• Maandishi ya tahadhari (caveat) yamerekebishwa. Yalidai vipimo vilivyopitwa na wakati vinaondolewa kwenye orodha za viwango wakati stale_fund_ids ilijengwa kwa kipimo tofauti kabisa cha kuchelewa kuchapisha, hivyo mifuko iliyoonekana kwenye zote mbili ilisomeka kama utata. Vipimo hivyo viwili sasa vinatajwa kwa majina tofauti popote vinaporipotiwa.
• Imeongezwa §12 Sehemu ya Soko & Vigawanyo vya Sekta — maamuzi yanayosimamia kigawanyo cha AUM ya sekta kabla ya utekelezaji: kufungamanisha na tarehe ya makubaliano (§12.1), jumla kwa kila sarafu bila kuchanganya FX (§12.2), makundi yasiyobadilika na kutangaza mabadiliko ya wigo (§12.3), kusongesha mbele kwa kikomo pamoja na kuchapisha makadirio (§12.4), uanachama wa makundi uliobandikwa (§12.5), na kuripoti kwa basis points (§12.6). Mbinu tatu zisizofaa zimeongezwa kwenye §13.
• Hakuna fomula iliyobadilika katika §6–§11.

v1.3 — Agosti 2026

• Marekebisho: §10.6 ya v1.2 "Kiwango Kilichokadiriwa cha Ukuaji wa Asili" ilifafanuliwa kama mapato ya NAV-kwa-kitengo (sawa na ret_3m) — hilo SI maana ya "organic growth rate" katika sekta hii (Morningstar/ICI): inamaanisha sehemu inayotokana na fedha, net_flow / AUM_ya_mwanzo. Imerekebishwa katika §10.7.
• Sehemu za zamani estimated_flow_contribution/ estimated_organic_growth_rate (dirisha moja la siku 91) zimebadilishwa na familia kamili ya vipindi: aum_chg_* na units_chg_* (§10.6, vipindi vyote sita, muktadha yote miwili), zikiwa na estimated_net_flow_* na estimated_organic_growth_rate_* iliyorekebishwa (§10.7) juu yake.
• Imeongezwa §10.8 Flow Share of AUM Growth — inakokotolewa na kuhifadhiwa, lakini kimakusudi SI sehemu ya taarifa yoyote ya umma.
• Sehemu za zamani estimated_flow_contribution/ estimated_organic_growth_rate zimeondolewa kwenye Firestore katika uboreshaji kamili unaofuata.

v1.2 — Agosti 2026

• Iliongezwa §10.6 Kiwango Kilichokadiriwa cha Ukuaji wa Asili na §10.7 Mchango Uliokadiriwa wa Fedha Ulioingia — mgawanyo wa mabadiliko ya AUM ya siku 91 katika ukuaji unaotokana na utendaji dhidi ya fedha zilizoingia, kwa mfuko mzima.
• Iliongezwa logo_url, fund_page_link, offer_doc_link kwenye jedwali la Ngazi ya 3 (§11). Nyongeza tu — hakuna fomula iliyobadilishwa.

v1.1 — Mei 2026

• Hali ya awali ya hati hii; hakuna kumbukumbu za changelog kabla ya v1.2.