> ## Content Index > Fetch the complete content index at: https://abundance.alloconomy.com/llms.txt > Use this file to discover other available public pages before exploring further. # Which Version of the Past? - URL: https://abundance.alloconomy.com/alloconomy/which-version-of-the-past/ - Published: 2026-10-28T17:01:57.000Z - Updated: 2026-10-28T17:01:57.000Z - Description: The same history can answer two different questions: what happened under the structure of the time, and how that history looks under today's structure. - Author: Sathya Narayanan - Tags: Alloconomy, Data Engineering **Personal views. Public sources. Fictional examples.** I write in a personal capacity. These views and teaching examples are my own; they do not represent my employer or carry its approval or endorsement. No confidential or nonpublic employer information is used. The people, businesses, products, dates and amounts in the examples below are fictional. Public index methodologies are linked where discussed. Type 1 and Type 2 slowly changing dimensions are familiar territory in data engineering and data warehousing. Overwrite a value, or preserve its history. It is an old, well-understood distinction, almost common sense by now. The situations we apply it to can still be surprisingly interesting. A new leader wants the full sales history of the products now in her department. A customer moves from Small Business to Enterprise. A stock-market index keeps a continuous chart while companies enter and leave. This article takes a fresh look at that familiar idea through these everyday situations. When should we read the past using the world as it was then, and when should we apply the world as it is now? ## The same sales, two useful histories Imagine a company that sells reading lamps, desks and chairs. Until June, lamps belong to Lighting; desks and chairs belong to Furniture. On 1 July, the company creates a Home Office department and moves lamps and desks into it. Chairs remain in Furniture. The new Home Office leader wants the full sales history of the products now in the department. These are the products she must plan for. Their older sales are useful even though Home Office did not exist then. Take three January sales: $100 of reading lamps, $200 of desks and $300 of chairs. The July reorganization gives us two ways to group that same $600. 01 / Same transactions · different grouping**January sales. A July reorganization.**Read the earlier sales through the structure of the time, or through the new structure. **1 JULY · REORGANIZATION**Lamps and desks move to Home Office. Chairs stay in Furniture. January → 30 June Point in time**Use the department at the sale date** **Lighting**$100 - Reading lamps$100 **Furniture**$500 - Desks$200 - Chairs$300 January company sales$600 Lighting $100 · Furniture $500 1 July → onward Latest structure**Use the department effective 1 July** **Home Office**$300 - Reading lamps$100 - Desks$200 **Furniture**$300 - Chairs$300 January company sales$600 Home Office $300 · Furniture $300 **$600 before. $600 after.** No sale was added or removed. The department assignment changed. Illustrative amounts. The first view answers: **Which department owned each sale when it happened?** This is often called an **as-was** view. The second answers: **What is the sales history of the products assigned to each department today?** This is an **as-is**, or current-structure, view. Both are useful. The first helps explain historical responsibility. The second helps plan the business that exists now. But “the history of the products I now lead” is different from “the results achieved under my leadership.” A reorganization cannot move a leader's start date backward. Evaluating her tenure needs the appropriate dates and ownership history too. Even “today” needs a date on the report. If products move again in October, the current-structure view can change again. Labeling this report **January sales, grouped by the organization effective 1 July** makes the choice reproducible. ## We make this choice in ordinary work Once we name the question, the time basis usually becomes clear. 02 / Choose the question**The same choice, five familiar settings**Historical responsibility and today's planning needs call for different groupings. - **Sales territories**Boundaries redrawn Point in timeWhich territory owned each order at the time? Latest stateWhat is the past demand in the territory I now cover? - **Customer segments**Small Business → Enterprise Point in timeHow much revenue came from enterprise customers as classified in each year? Latest stateHow much have today's enterprise customers bought over their lifetimes? - **Product categories**Products move into Outdoor Point in timeWhat sold under Outdoor as it existed each season? Latest stateWhat is the sales history of today's Outdoor range? - **Employee teams**People transfer between teams Point in timeWhich team did each person belong to when they completed the training? Latest stateWhat training have the people on my current team completed? - **Customer residence**A customer moves to another city Point in timeWhere were they living when they placed past orders? Latest stateWhere do our long-standing customers live now? **Name the time basis.** “Today’s enterprise customers over their lifetimes” and “enterprise revenue in each year” are different measures. For that last historical question, residence is still different from delivery address. The parcel may have gone somewhere else. We need the fact that matches the question, as well as the right date. The enterprise example exposes a particularly quiet trap. If today's enterprise customers were small businesses three years ago, putting all their earlier spending under Enterprise does not measure the enterprise segment as it existed three years ago. It measures the earlier spending of a group selected today. A useful report can become misleading simply by losing that sentence from its label. ## What Type 1 and Type 2 actually do In a dimensional warehouse, **facts** record events or measurements: a sale, its date, its product and its amount. **Dimensions** supply descriptive context: the product's category, the customer's segment or the employee's team. Slowly changing dimensions give us ways to manage that context. The important decision is which changes to retain, and which reporting perspectives the model must support. **Type 1 overwrites an attribute.** If the lamp's department changes from Lighting to Home Office, its stored department becomes Home Office. Earlier sales joined through that updated record are now grouped under Home Office too. The old department value is no longer available from that attribute. This can be appropriate for a deliberate current-only view or a spelling correction. [Kimball Group: Type 1](https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/type-1/?ref=abundance.alloconomy.com). **Type 2 adds a version.** The warehouse retains the Lighting version and adds a Home Office version with its effective period and a distinct version key. Historical sales remain associated with the applicable version. [Kimball Group: Type 2](https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/type-2/?ref=abundance.alloconomy.com). The lamp makes the difference visible. After the July update, a June sale can still carry its historical assignment if that version was retained. 03 / What the warehouse retains**Overwrite a value. Or preserve a version.**The choice changes which context is available when historical facts are queried. **ONE PRODUCT · LAMP-01**Lighting until 30 June. Home Office from 1 July. Type 1 · overwrite**Keep the current assignment** Before the update**Lighting** ↓ Stored value after the update**Home Office**The department attribute now holds the latest value. A 30 June sale, grouped through this attribute:**Home Office** Type 2 · add a version**Keep the effective periods** Version 101 · LAMP-01**Lighting**1 January ≤ sale date < 1 July Version 102 · LAMP-01**Home Office**Sale date ≥ 1 July A 30 June sale linked to version 101:**Lighting** **Both reporting views can coexist.** Retain the versions, then use stable product identity to add a current mapping when the question calls for it. A sale on 30 June uses version 101; a sale on 1 July uses 102\. The boundary belongs to exactly one version. If a June sale arrives in the warehouse in August, its event date still determines the historical version. Type 1 and Type 2 are storage techniques. They are not a requirement to offer only one reporting perspective. We can retain historical versions and also provide a current mapping through the stable product identity. One report uses the historical department; another uses the current department. Kimball describes hybrid approaches for this, including Type 7, which supports both perspectives. [Kimball Group: Type 7](https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/type-7/?ref=abundance.alloconomy.com). In the reorganization example, I would preserve the historical assignments and offer both views with explicit labels. Planning with today's organization does not require deleting the old organization. This works cleanly because each product has one department in each view. If a product is split across departments, the report also needs an explicit allocation rule. Otherwise, joining one sale to two departments can accidentally count it twice. ## Back to the index chart For an official index series, the normal treatment is the historical-membership approach. Routine constituent changes take effect from their specified dates; they do not rebuild the earlier series using today's members. NSE Indices describes an evolving index whose returns remain comparable across membership changes. [NSE Indices: index concepts](https://www.niftyindices.com/resources/index-concepts/faqs?ref=abundance.alloconomy.com). For a capitalization-weighted index, the level is broadly the included market capitalization divided by an **index divisor**. When a replacement changes the included capitalization, the divisor is adjusted to preserve continuity. The replacement itself should not manufacture a gain or loss. [S&P Dow Jones Indices: index mathematics](https://www.spglobal.com/spdji/en/methodology/article/index-mathematics-methodology/?ref=abundance.alloconomy.com). At the replacement boundary, the adjustment looks like this: 04 / An evolving basket**Membership changes. The level stays continuous.**An illustrative capitalization-weighted index replaces Company A with Company C. **AT THE CHANGE**Prices held constant. Only membership and the continuity adjustment change. Before replacement AB A leaves; B remains. Included market value ÷ divisor1,000 ÷ 10 = **100** After replacement BC C joins; B remains. Included market value ÷ divisor1,200 ÷ 12 = **100** **100**→**100** **Earlier history keeps the earlier basket.** The new basket drives subsequent movements. These numbers illustrate the adjustment, not actual market returns or equal constituent weights. The new basket then drives subsequent movements. The chart carries the performance of an evolving basket through time. Historical membership alone is not enough to reproduce it; weights, prices and the calculation rules matter too. A chart made by selecting today's members and looking backward answers a different question: how did this currently selected group perform? If presented as a historical investment opportunity, it can introduce survivorship and look-ahead bias. We used later information to choose the earlier universe. That is the connection to our department example. Applying today's grouping backward can be useful when the question explicitly asks for it. It becomes misleading when presented as the experience of the group that actually existed then. The chart's shape—line or candlestick—does not resolve this. Check the series underneath it. A price-return index and a total-return index treat dividends differently, and an ETF, futures contract or CFD is a different instrument. TradingView's own documentation explains that apparently similar instruments can have different data sources. We should not assume every app or ticker is identical. [S&P index varieties](https://www.spglobal.com/spdji/en/methodology/article/index-mathematics-methodology/?ref=abundance.alloconomy.com); [TradingView: instrument sources](https://www.tradingview.com/support/solutions/43000709178-what-does-tvc-stand-for-in-the-instrument-ticker/?ref=abundance.alloconomy.com). Nor should we say history is *never* revised. Providers can correct errors, and history before an index's launch may be a hypothetical backtest. S&P documents both qualifications. Those are different from routinely replacing past membership with today's list. [S&P equity policies, recalculation and backtested data](https://www.spglobal.com/spdji/en/documents/methodologies/methodology-sp-equity-indices-policies-practices.pdf?ref=abundance.alloconomy.com). ## What was true then, and what we knew then There is one more meaning of “point in time.” Suppose the lamp's move took effect on 1 July, but the data team learned about it on 10 July. A report produced on 5 July may still have shown Lighting. Two historical questions now differ: “Which department was responsible on 5 July?” and “What did our system report on 5 July?” 05 / Effective time · recorded time**The change happened before the system knew.**Both questions concern 5 July. They use different knowledge cutoffs. 1. **1 July**The product move **takes effect.** 2. **5 July**A report is produced **before the update arrives.** 3. **10 July**The data team **records the change.** Effective history Who owned the product on 5 July, using the corrected history? **Home Office** The move was effective on 1 July. Recorded knowledge What department did the system show in its 5 July report? **Lighting** The update arrived on 10 July. **Two dates, two responsibilities.** Effective time supports the historical business view. Recorded time preserves what the system knew when a report or decision was made. The first uses the business-effective date. The second also needs the history of when information reached the system. Keeping both is called **bitemporal modeling**. A basic Type 2 table with only business-effective dates does not automatically preserve both histories. [Martin Fowler: bitemporal history](https://www.martinfowler.com/articles/bitemporal-history.html?ref=abundance.alloconomy.com). That distinction matters when reproducing a report or asking what someone could have known when they made a decision. Use it where the question requires both histories. ## Give the report a complete sentence Before building the chart, finish the request: - Show past events using the classifications that applied **when each event happened**. - Show past events using the classifications effective **on this chosen date**. - Reproduce what the system could have shown **with the information available on that date**. These choices deserve visible labels, not assumptions buried in a query. The Home Office leader needs the history of the products she now owns. The person reviewing last year's departments needs the structure of last year. The reader of an index chart needs to know which series and membership rules the chart represents. Agree on the time basis before writing the query. A historical number is useful only when we know which version of the world it describes.