Knowledge Objects — Ultra-Advanced Dividend Edition

Build robust dividend intelligence with schemas, reconciliation pipelines, audit trails, and a repeatable testing harness.

Offline HTML Copy buttons Schemas + rules + tests Dividend edge cases covered

1) Quickstart (what to do when you want perfect dividend answers)

  1. Pick listing: specify ticker + exchange (e.g., VAR / Oslo Børs).
  2. Provide/confirm one authoritative source: company release / exchange notice.
  3. Store a DividendEvent object for the specific dividend.
  4. Store guardrails: gross vs net, timezone, FX behavior, conflict resolution.
  5. Run the test harness: consistency + ambiguity + net/gross + corporate actions.
Shortcut: If you only remember one thing, remember this: dividend questions need listing + source + gross/net stance to be unambiguous.

2) What is a knowledge object? (in one sentence)

A knowledge object is a structured fact bundle with metadata (scope, source, validity, confidence) so the assistant can reuse it reliably.

Privacy: If you don’t want something stored, say “This chat only (do not remember).”

3) Two modes of “learning”

  • In-session: improves answers now.
  • Cross-session memory: persists when you ask to remember.
Best practice: Put stable rules (schemas, procedures, guardrails) in memory; keep one-off numbers “this chat only.”

4) Templates (copy/paste)

Template A — Store as memory

Please remember this as a knowledge object:
ID: (optional)
Version: (optional)
Type: Preference | Definition | Procedure | Dataset | Decision | Project
Content: …
Scope: Remember for future chats
Source: User | Link | Document | Meeting
Valid until: (optional)
Confidence: High | Medium | Low
Notes/Constraints: (optional)

Template B — This chat only (do not store)

Use this as a knowledge object for this conversation only (do not remember):
Type: …
Content: …
Source: …
AsOf: …
Confidence: High | Medium | Low

Template C — Versioned object with acceptance criteria

Please remember this as a knowledge object:
ID: _____
Version: 1.0
Type: Procedure | Definition | Decision
Content:
  - Purpose: …
  - Inputs: …
  - Outputs: …
  - Rules: …
  - Acceptance criteria:
      1) …
      2) …
Scope: Remember
Source: User
Change log:
  - v1.0 (YYYY-MM-DD): created

5) Dividend schemas (minimum → enterprise-grade)

Schemas ensure consistency. Start small, then add fields only when they reduce ambiguity.

5.1 DividendEvent (minimum viable)

Schema: DividendEvent.v1
Fields:
  - Company
  - Ticker
  - Listing (exchange + MIC)
  - AmountPerShare
  - Currency
  - ExDate
  - PayDate
  - DividendType (ordinary|interim|final|special)
  - Source
  - AsOf
  - Confidence

5.2 DividendEvent (extended for reconciliation)

Schema: DividendEvent.v2
Adds:
  - RecordDate
  - DeclarationDate
  - ApprovalBody (Board|AGM|EGM)
  - PaymentCurrency (if different)
  - FXReference (source + timestamp)
  - RoundingRule
  - GrossOrNet (default: Gross)
  - WithholdingRateAssumed (optional)
  - CorporateActionLink (optional)
  - Notes

5.3 ListingMap (multi-listings / ADRs)

Schema: ListingMap.v1
Fields:
  - Company
  - PrimaryListing: {Ticker, Exchange}
  - AlternateListings: [{Ticker, Exchange, InstrumentType (ADR|GDR|Local)}]
  - ADRRatio (if applicable)
  - Rule: Always confirm which listing the user means.

5.4 DividendPolicy (expectations, not facts)

Schema: DividendPolicy.v1
Fields:
  - Company
  - Frequency
  - TypicalTiming (relative to earnings)
  - CurrencyPreference
  - StatedPolicy (text)
  - Constraints/Caveats
  - Source
  - AsOf
Rule:
  - Policy ≠ announced dividend. Always separate policy objects from event objects.

5.5 JSON Schema (optional) — for strict validation

Open JSON Schema: DividendEvent.v2 (for machine validation)

Use this when you want strict field validation and predictable automation.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "DividendEvent.v2",
  "type": "object",
  "required": ["Company","Ticker","Listing","AmountPerShare","Currency","ExDate","PayDate","DividendType","Source","AsOf","Confidence"],
  "properties": {
    "Company": {"type":"string"},
    "Ticker": {"type":"string"},
    "Listing": {
      "type":"object",
      "required":["Exchange","MIC"],
      "properties": {
        "Exchange": {"type":"string"},
        "MIC": {"type":"string"}
      }
    },
    "AmountPerShare": {"type":"number"},
    "Currency": {"type":"string"},
    "PaymentCurrency": {"type":"string"},
    "ExDate": {"type":"string", "format":"date"},
    "RecordDate": {"type":"string", "format":"date"},
    "PayDate": {"type":"string", "format":"date"},
    "DeclarationDate": {"type":"string", "format":"date"},
    "DividendType": {"type":"string", "enum":["ordinary","interim","final","special"]},
    "ApprovalBody": {"type":"string", "enum":["Board","AGM","EGM","Other"]},
    "FXReference": {
      "type":"object",
      "properties": {
        "Source": {"type":"string"},
        "Timestamp": {"type":"string"},
        "RateDate": {"type":"string", "format":"date"}
      }
    },
    "RoundingRule": {"type":"string"},
    "GrossOrNet": {"type":"string", "enum":["Gross","Net"]},
    "WithholdingRateAssumed": {"type":"number"},
    "CorporateActionLink": {"type":"string"},
    "Notes": {"type":"string"},
    "Source": {"type":"string"},
    "AsOf": {"type":"string", "format":"date"},
    "Confidence": {"type":"string", "enum":["High","Medium","Low"]}
  }
}

6) Reconciliation pipeline (how to fuse multiple sources safely)

When sources disagree, don’t guess. Use a pipeline with explicit precedence + conflict reporting.

6.1 Source tiers

  • Tier 1: Company release / exchange notice (authoritative).
  • Tier 2: Institutional data vendors / reputable aggregators (may lag).
  • Tier 3: Media/blogs/forums (context only).

6.2 Pipeline stages

  1. Ingest: capture raw facts + source metadata (URL/title/time).
  2. Normalize: standardize dates (ISO), currency codes, listing IDs.
  3. Validate: schema validation (required fields present).
  4. Reconcile: apply precedence rules; detect conflicts.
  5. Explain: produce an audit trail of which facts came from where.
  6. Publish: answer format (summary + bullets + citations).

6.3 Reconcile rule object

Please remember this as a knowledge object:
ID: RULES-DIV-RECONCILE-001
Version: 1.0
Type: Procedure
Content:
  - Goal: reconcile dividend dates/amounts from multiple sources.
  - Precedence: Tier1 > Tier2 > Tier3.
  - If Tier1 exists: use Tier1, cite it.
  - If only Tier2 exists: label as “not confirmed by company release”.
  - If conflict across tiers: show both values + flag discrepancy + ask which to trust.
  - Output must include: AmountPerShare, Currency, ExDate, PayDate, Source.
Scope: Remember
Valid until: until changed
Change log:
  - v1.0 (2026-04-17): created

7) Rules engine (guardrails that prevent classic dividend mistakes)

7.1 Gross vs net rule

Type: Guardrails
Content:
  - Default: report dividend as GROSS amount per share.
  - If user asks NET: ask for (1) tax residency, (2) account type, (3) broker handling.
  - Always label the figure as Gross/Net explicitly.
Scope: Remember
Valid until: until changed

7.2 Listing confirmation rule

Type: Guardrails
Content:
  - If company has multiple listings (ADR/local), ask which ticker/listing to use.
  - Never mix dates from one listing with currency from another.
Scope: Remember
Valid until: until changed

7.3 FX rule (declared vs paid currency)

Type: Guardrails
Content:
  - If PaymentCurrency differs from declared Currency, show both.
  - If a reference FX rate is mentioned: store FX source + timestamp + rounding.
  - If FX is unknown: do not estimate unless user requests an estimate.
Scope: Remember
Valid until: until changed

7.4 Calendar rule (date sanity)

Type: Guardrails
Content:
  - Validate date order: Declaration <= ExDate <= RecordDate <= PayDate (where applicable).
  - If RecordDate missing, do not invent it.
  - If any date violates order: flag and ask for clarification.
Scope: Remember
Valid until: until changed

8) Dividend edge cases (and how to model them)

These are the cases that break “simple” dividend trackers.

8.1 Special dividends

  • Store DividendType = special.
  • Add Notes: one-off, linked to asset sale, etc.
  • Don’t extrapolate future payments from special dividends.

8.2 Stock splits & adjusted history

  • Create a CorporateAction object (split ratio, effective date).
  • Define whether displayed dividend history is adjusted or raw.

8.3 ADR ratio & fees

  • ADR dividends often show USD amounts + ADR ratio (e.g., 1 ADR = N local shares).
  • Store ADR ratio and note potential depositary fees.

8.4 Partial periods / irregular schedules

  • Model frequency as Policy, not Event.
  • Let Event objects be “truth,” Policy objects be “expectations.”

8.5 Corporate action schema

Schema: CorporateAction.v1
Fields:
  - Company
  - ActionType (split|reverse_split|spin_off|rights_issue)
  - EffectiveDate
  - Ratio (if applicable)
  - AdjustmentRule (how to adjust per-share history)
  - Source
  - AsOf
Rule:
  - If a CorporateAction exists near a dividend, warn about adjusted vs unadjusted figures.

9) Testing harness (unit tests for your knowledge objects)

Testing prevents drift and catches ambiguity early.

9.1 Checklist

  • Required fields present (schema validation).
  • Listing specified (no ADR/local mix).
  • Date ordering sanity.
  • Gross vs net explicitly labeled.
  • Conflicts flagged + explained.

9.2 Test suite (copy/paste)

Dividend KO Test Suite

Test A — Listing ambiguity
- Question: “Next dividend for Vår Energi?”
- Expected: Ask “VAR (Oslo) or VARRY (ADR)?”

Test B — Not announced
- Question: “Next dividend for VAR?” (when not announced)
- Expected: Say “not announced” + next catalyst date (earnings/AGM).

Test C — Net request
- Question: “How much will I receive net?”
- Expected: Ask residency + account type; label gross vs net.

Test D — Conflicting sources
- Input: Provide two different ex-dates from two sources.
- Expected: Flag conflict, prefer Tier1, show both values, ask what to prioritize.

Test E — FX ambiguity
- Question: “Convert to USD” without FX reference
- Expected: Ask for FX date/time or provide estimate only if user requests.

Test F — Corporate action
- Input: Provide a split action near dividend.
- Expected: Warn about adjusted amounts and ask which representation is wanted.

9.3 Self-check prompt

Use the stored knowledge objects and do a self-check:
1) List which knowledge objects you applied (ID/type).
2) Show the answer.
3) Verify: listing specified, gross/net labeled, dates sane, source cited.
If anything is missing, ask me exactly one clarifying question.

10) Knowledge Object Registry (keep your objects organized)

A registry makes your knowledge base manageable: IDs, versions, owners, and expiry.

10.1 Registry schema

Schema: KnowledgeObjectRegistryEntry
Fields:
  - ID
  - Version
  - Type
  - Title
  - Owner
  - Scope (Remember|ChatOnly)
  - ValidUntil
  - Keywords
  - Dependencies (IDs)
  - LastReviewed
  - Notes

10.2 Example registry entries

ID: RULES-DIV-RECONCILE-001 | v1.0 | Procedure | Dividend reconcile rules | Owner: Tore | Scope: Remember | ValidUntil: — | Keywords: dividends, reconcile
ID: MAP-LISTINGS-001        | v1.0 | Definition | Listing map | Owner: Tore | Scope: Remember | Keywords: adr, listings
ID: GUARD-GROSSNET-001      | v1.0 | Guardrails | Gross vs net | Owner: Tore | Scope: Remember | Keywords: tax, withholding

11) Power prompts (get consistent results fast)

11.1 “No assumptions” dividend query

Dividend request (no assumptions):
Company/Ticker: ____
Listing: ____
Question: ____
Rules:
  - Use only authoritative sources I provide.
  - If not announced, say “not announced” and provide next catalyst date.
  - Report gross per-share amount unless I ask for net.
Output:
  - 1-line summary
  - bullets: amount, currency, ex-date, record-date (if available), pay-date
  - include source

11.2 “Apply + verify” prompt

Before answering:
1) List the knowledge objects you will apply.
2) Answer.
3) Run the self-check: listing, gross/net, date sanity, source.
Ask one clarifying question only if needed.

11.3 “Create a KO from this” prompt

Turn the following into a knowledge object with ID, Version, Type, Content, Scope, Source, ValidUntil, and Acceptance criteria:
[PASTE TEXT HERE]
Then propose 3 tests to validate it.

11.4 “Conflict resolver” prompt

Two sources disagree:
Source A: …
Source B: …
Please:
1) classify each source tier,
2) identify conflicts,
3) choose a default (Tier1 preferred),
4) present the answer and flag the discrepancy,
5) ask me which source to prioritize if still uncertain.

Save locally and open in any browser. Copy buttons work offline.