1) Basics: what “learning” means (2 modes)
A) In-session learning
I can use what you share in this chat to improve answers right now.
B) Cross-session memory
If you explicitly ask me to remember something (and it’s stable/useful), I can store it for future chats.
2) What is a “knowledge object”?
A knowledge object is a structured bundle of facts plus metadata so it can be reused consistently.
- Type: preference / profile / project / decision / definition / dataset / procedure
- Content: the actual facts
- Scope: this chat only vs. remember
- Source: you, a doc, a link, meeting notes
- Validity: time-bound or “until changed”
- Confidence: high/medium/low if uncertain
3) Templates
Use these templates when you want input treated as structured knowledge.
Template 1 — Store as memory
Please remember this as a knowledge object:
Type: Preference | Profile | Project | Decision | Definition | Procedure | Other
Content: …
Scope: Remember for future chats
Source: User
Valid until: (optional date) or “until I change it”
Confidence: High | Medium | Low
Notes/Constraints: (optional)
Template 2 — Use now only (do not store)
Use this as a knowledge object for this conversation only (do not remember):
Type: …
Content: …
Scope: This chat only
Source: …
Valid until: …
Confidence: High | Medium | Low
Template 3 — Versioned object (recommended)
Please remember this as a knowledge object:
ID: PROJECT-___-001
Version: 1.0
Type: Project | Decision | Procedure
Content:
- Goal: …
- Definitions: …
- Inputs: …
- Outputs: …
- Acceptance criteria: …
Scope: Remember for future chats
Source: User
Valid until: …
Change log:
- v1.0 (YYYY-MM-DD): created
4) Advanced uses of knowledge objects (general)
4.1 Layered knowledge (base → overrides)
Use a base object for general rules and a short-lived override for a specific client/task.
Knowledge Object (Base)
Type: Preference
Content: Start with a 3-line summary then a table.
Scope: Remember
Knowledge Object (Override)
Type: Preference
Content: For dividends, always include amount/share + ex-date + pay date + source.
Scope: This chat only
4.2 Schema-driven objects
Define a schema once; create many objects that conform to it.
Schema: DividendEvent
Fields: Ticker, Market, AmountPerShare, Currency, ExDate, RecordDate, PayDate, Source, AsOf
Knowledge Object
Type: DividendEvent
Content:
Ticker: VAR
Market: Oslo Børs
AmountPerShare: 1.209
Currency: NOK
ExDate: 2026-02-03
PayDate: 2026-02-12
Source: Company release
Scope: Remember
4.3 Decision log (auditability)
Store decisions with rationale, owner, and date.
ID: DECISION-DIV-001
Version: 1.0
Type: Decision
Content:
- Decision: Prefer company releases for dividend dates/amounts; use aggregators only as secondary.
- Rationale: Reduces basis risk from stale/incorrect calendar data.
- Owner: Tore
- Date: 2026-04-17
Scope: Remember
Change log:
- v1.0: created
4.4 Guardrails
Encode timezone, currency, sources, and output format.
Type: Guardrails
Content:
- Timezone: Europe/Oslo
- Units: NOK, USD, % yield
- Output format: Summary line + bullets + (optional) table
- Ask if missing: ticker, market/listing, as-of date
Scope: Remember
5) Dividends (advanced): build robust dividend knowledge objects
Dividend questions look simple (“how much per share?”) but often hide complexity: multiple listings, different currencies, withholding tax, corporate actions, record-date rules, and special dividends.
5.1 Dividend schemas (use these as building blocks)
Schema A — DividendEvent (minimum)
Schema: DividendEvent
Fields:
- Ticker (e.g., VAR)
- Market/Listing (e.g., Oslo Børs)
- AmountPerShare
- Currency
- ExDate
- RecordDate (optional)
- PayDate
- DividendType (ordinary/interim/final/special)
- Source (URL/title)
- AsOf (when verified)
- Confidence
Schema B — DividendPolicy (ongoing expectations)
Schema: DividendPolicy
Fields:
- Company
- PayoutFrequency (quarterly/semi/annual)
- CurrencyPreference
- TargetPayout (optional)
- BoardApprovalProcess (AGM/EGM/board)
- TypicalTiming (months/around earnings)
- Caveats (oil price, FCF, leverage)
- Source
- AsOf
5.2 Multi-listing + ADR handling (avoid date/currency mix-ups)
- Always capture the listing (e.g., Oslo Børs vs. OTC ADR). Same company can have different calendars/currencies.
- Add a ListingMap object to translate between tickers.
Please remember this as a knowledge object:
ID: MAP-LISTINGS-001
Version: 1.0
Type: Definition
Content:
- ListingMap:
VAR (Oslo Børs) -> Primary listing
VARRY (OTC ADR) -> ADR; may show different ex/pay dates and USD amounts
- Rule: When asked about a dividend, confirm which listing/ticker the user means.
Scope: Remember
Source: User
Valid until: until changed
5.3 FX conversion rules (when amount is declared in one currency and paid in another)
- Create an FXRule object when a company uses a reference FX rate on a given date/time.
- Store: FX source, timestamp, and rounding rule.
Type: FXRule
Content:
- If dividend is based on a reference FX rate:
* Store: FX source (e.g., Norges Bank), timestamp, and rate date.
* Store: rounding convention (e.g., 3 decimals).
- Output: state both declared currency and payment currency if different.
Scope: Remember
Valid until: until changed
5.4 Tax & withholding (make net vs. gross explicit)
- Define whether your answer is gross or net of withholding tax.
- When net depends on account type or residency, ask for the minimum needed (e.g., “Norwegian resident?” “ASK or ordinary account?”).
Type: Guardrails
Content:
- Dividend amount/share is reported as GROSS unless explicitly stated otherwise.
- If user asks for net amount, ask for:
* tax residency (country)
* account type (ASK/ordinary/pension)
* broker withholding handling (if known)
Scope: Remember
Valid until: until changed
5.5 Corporate actions (splits, spin-offs, special dividends)
Dividend calendars are affected by corporate actions. Use a separate CorporateAction object and link it to DividendEvent objects.
Schema: CorporateAction
Fields:
- ActionType (split/reverse split/spin-off/rights issue)
- EffectiveDate
- AdjustmentRule (how historical dividends should be adjusted)
- Notes
- Source
Rule:
- If a CorporateAction exists around the dividend period, warn and confirm whether amounts are adjusted.
5.6 Provenance + conflict resolution (when sources disagree)
Provenance grading
- Primary: company release / exchange notice
- Secondary: reputable aggregators (may lag)
- Tertiary: blogs, forums
Conflict rules
- If primary exists, use it and cite it.
- If only secondary exists, label as “not confirmed by company release” and give the next catalyst date.
- If dates conflict, present both and ask which source to trust (or default to primary).
Type: Procedure
Content:
- When two dividend sources conflict:
1) Identify which is primary vs secondary.
2) Prefer primary.
3) If user’s question is time-critical, show both values and flag the discrepancy.
4) Ask one clarifying question: “Should I treat the company release as authoritative?”
Scope: Remember
Valid until: until changed
5.7 Dividend testing harness (repeatability)
Use acceptance tests to verify that you’ll get consistent outputs next time.
Dividend knowledge object tests:
Test 1 — Minimal fields:
- Input: ask “next dividend for VAR?”
- Expected: If not announced, answer must say “not announced” + next catalyst date.
Test 2 — Listing ambiguity:
- Input: ask “next dividend for Vår Energi”
- Expected: Ask “VAR (Oslo) or VARRY (ADR)?”
Test 3 — Net vs gross:
- Input: ask “how much will I receive net?”
- Expected: Ask for residency + account type.
Test 4 — Conflicting sources:
- Input: provide two different ex-dates
- Expected: Flag conflict, prefer primary, ask which to prioritize.
Test 5 — Corporate action near ex-date:
- Input: add a stock split knowledge object
- Expected: Warn about adjusted vs unadjusted amounts.
6) How to make a knowledge object (step-by-step)
- Name the purpose (e.g., “Dividend answers for Norwegian tickers”).
- Pick a schema (DividendEvent, DividendPolicy, ListingMap).
- Decide scope: remember vs. this chat only.
- Write content as bullet facts or key/value fields.
- Add guardrails: timezone, currency, net vs gross, conflict handling.
- Add acceptance criteria: define what a correct answer must include.
DividendEvent object (ready to fill)
Use this as a knowledge object for this conversation only (do not remember):
Type: DividendEvent
Content:
Ticker: ____
Market: ____
AmountPerShare: ____
Currency: ____
ExDate: ____
RecordDate: ____
PayDate: ____
DividendType: ordinary|interim|final|special
Source: ____
AsOf: ____
Scope: This chat only
Confidence: High|Medium|Low
7) How to test a knowledge object (checklist + prompts)
- Clarity: is it unambiguous?
- Completeness: do you have ticker + listing + amount + key dates?
- Consistency: does it generate the same structure each time?
- Scope: remember vs. do not remember explicitly set?
- Edge cases: ADR, FX conversion, withholding tax, special dividend, split.
Self-check prompt
Use the stored knowledge objects and do a self-check:
1) List which knowledge objects you are applying.
2) Show the output.
3) Verify it meets the acceptance criteria.
If anything is missing, ask me exactly one clarifying question.
8) Dividend-focused examples
Example — Dividend procedure (robust)
Please remember this as a knowledge object:
ID: PROC-DIV-ROBUST-001
Version: 1.0
Type: Procedure
Content:
- For “next dividend” questions:
1) Confirm ticker + listing.
2) Prefer company release for dates/amount.
3) Return gross amount/share + currency + ex/record/pay.
4) If not announced: say “not announced” + provide next earnings/AGM catalyst.
5) If user asks net: ask residency + account type.
6) If split/special dividend suspected: warn and ask if adjusted amounts are required.
- Output format: 1-line summary + bullets + citations/links.
Scope: Remember
Source: User
Valid until: end of 2026
Change log:
- v1.0 (2026-04-17): created
Example — Watchlist of tickers (so you don’t repeat them)
Please remember this as a knowledge object:
Type: Project
ID: WATCH-DIV-NO-001
Version: 1.0
Content:
- Dividend watchlist tickers: VAR, EQNR, AKRBP
- Default listing: Oslo Børs
- Default timezone: Europe/Oslo
Scope: Remember
Source: User
Valid until: until changed
9) Quick prompts
Ask what I’m using
Before answering, list the knowledge objects you will apply and why (one line each). Then answer.
Force “no assumptions”
Answer using only what’s in the knowledge objects and what I provide. If something is missing, ask.