The Memory ktAi Builds

A client uploads a folder. Board resolutions, a share grant agreement, a transfer pricing study, last year’s tax filings, two contracts with a US distributor, three internal memos. Nothing is a question yet. It is the start of an introduction.

The previous essay described why mid-market multinationals with cross-border exposure cannot economically reach partner-grade opinion work, and what kind of system would need to exist to fill that gap. This essay describes what one of those documents actually does to ktAi, and what ktAi does back.

---

The upload triggers a sequence the user does not see. Each document moves through text extraction (with optical character recognition where the document is image-only), through embedding by a model that turns sentences into mathematical vectors, and through a step where a language model reads the document and extracts entities and relationships. Who is named in this document. What dates appear. What amounts. What tax terms. What legal references. Which of these things relate to which others, and how.

The output of this sequence is not a stored file. It is structured knowledge. The document becomes a small graph: nodes for the people and companies and amounts and tax terms it contains, edges for the relationships between them. This graph is private to the user. It is stored in a database that is logically and physically separated from the corresponding graph for any other user.

Over time, as the user uploads more documents, this private graph grows. A board resolution authorizing a share grant becomes connected to the share grant agreement that implements it. A transfer pricing study becomes connected to the intercompany agreements it analyzes. A prior year’s tax filing becomes connected to the positions it documents. The user does not curate these connections. The system extracts them at ingestion and adds them to the graph as new evidence arrives.

This is one of the two maps ktAi maintains for the user.

---

The other map is the one most people imagine when they think about an AI tax system. It is the body of law and authority that any tax position has to be defensible under. Israeli Income Tax Ordinance sections, Real Estate Tax provisions, VAT, ITA circulars, US Internal Revenue Code, Treasury Regulations, Revenue Procedures and Rulings, US-Israel treaty articles, the OECD GloBE rules, judicial interpretations across both jurisdictions. This map is shared across all users of the system. It is built once, updated as the law changes, and queried at every chat turn and every report generation.

ktAi treats this map as structured authority, not as a corpus of text to search. A section of the Code is a node. The regulation that interprets it is a different node, linked. The ruling that applies the regulation to a fact pattern is a third node, linked again. When the system retrieves the section, it can also retrieve what amends it, what interprets it, what cites it, and which version was in force at the time the user’s question is being asked about.

A user’s question almost never lives entirely inside one map or the other. The question is in the user’s map (their facts, their entities, their documents). The answer must be defensible in the system’s map (the law, the regulations, the case authority). The work of ktAi is the work of holding both maps in mind at once.

---

A small example makes the bridging concrete.

The user uploads an Israeli board resolution that mentions a Section 102 employee equity grant. The document is processed; the entity extractor recognizes “Section 102” as a legal reference. In the user’s private graph, a node is created representing the user’s own mention of Section 102. At query time, the system retrieves both: the user-side mention from the user’s graph and the corresponding authoritative node from the system’s graph. The bridging happens at retrieval, not at ingestion. The two graphs remain physically separated, and the analytical layer composes their outputs together.

When the user later asks a question about a proposed change to the company’s equity plan, the system retrieves both. It retrieves the statutory authority (what Section 102 requires, what the ITA circulars say, how the trustee track works, what the holding period implications are). It also retrieves the user’s own prior mentions of Section 102 (what the board has already authorized, what plan documents have been uploaded, what grants have been made and when). The answer is shaped by both. The statutory answer alone would be a research output. The combined answer is closer to advice, because it is anchored to the user’s actual facts.

This is the architecture working as designed. It is not exotic in concept. It is unusual in execution, because making it work requires the user’s graph to actually link to the system’s graph at the right granularity, and most AI systems for tax do not maintain two graphs at all.

---

What the user sees when they ask a question is the result of this dual retrieval running together.

A query enters the system. The system identifies the jurisdictions implicated, retrieves relevant authority from the system’s graph, retrieves relevant context from the user’s graph, retrieves relevant text from the user’s documents directly when text-level recall is helpful, and assembles all of this into the context that the analytical layer consumes. Analysis runs in parallel across the dimensions the question touches: Israeli law, US law, treaty interaction, risk patterns. Disagreement between dimensions is preserved rather than averaged. Citations are anchored to the authority that supports them, not generated as plausible-looking text.

When confidence is high and citations are clean, the system answers. When confidence is low, when citations cannot be tied back to authority, when the user’s documents do not contain a fact the analysis depends on, the system says so. It identifies what would be needed to answer well. It does not fill the gap.

This is the chat experience, and it is genuinely useful in chat form for ad-hoc questions. The same machinery powers something more structured.

---

When a user requests a compliance analysis rather than a one-off question, the same retrieval architecture runs against a different output shape.

The analytical layer reaches into both maps at once. From the system’s map: what does Israeli law require for transfer pricing documentation this year, what does US Form 150 require, what are the Pillar Two reporting obligations for a company at this revenue tier, what deadlines apply. From the user’s map: what intercompany agreements has the user uploaded, what foreign holdings does the user actually have, what filings has the user made previously, what positions has the user taken.

The output is structured. Requirements with citations. Deadlines with dates. Red flags with supporting evidence. Missing information identified explicitly. The deliverable is not a chat response. It is a document a senior tax professional can review, modify, and sign, with the system’s reasoning visible underneath each conclusion.

This is the difference the architecture is built around. A compliance analysis from a single-document AI tool is a description of what the document says. A compliance analysis from ktAi is a position about the user’s actual obligations, anchored to specific authority on one side and specific user facts on the other.

---

What changes for the user is the shape of how knowledge accumulates.

In a traditional engagement, knowledge of a client’s tax posture lives in the head of the partner who has serviced the client for years. When the partner is unavailable, the knowledge is unavailable. When the partner retires or moves firms, the knowledge moves with them. The client’s company has to brief a new partner from scratch, often paying for the partner to read what the prior partner already knew.

In ktAi, the knowledge lives in the user’s graph. It accumulates as documents are uploaded and questions are asked. A new tax professional joining the engagement can query the user’s accumulated knowledge directly. What documents the company has uploaded. What entities have been extracted. What prior questions have been asked and answered. The knowledge transfer cost is no longer measured in days of briefing. It is measured in the time it takes to ask the right questions.

This does not eliminate the need for senior professional judgment. It changes what senior judgment is applied to. It is no longer applied to original drafting and original briefing. It is applied to reviewing structured analysis against the professional’s own understanding of what is correct, and modifying where modification is warranted. The economic gap between mid-market budgets and partner-grade work product closes from this direction.

---

There are limits worth naming directly, because the architecture is not complete and pretending otherwise would betray the discipline the architecture is supposed to enforce.

The user’s graph today captures entities, relationships between them, and the relationships of entities to legal authority. It does not yet capture corporate structure in the formal sense (parent companies, subsidiaries, ownership percentages with dates) in a way that supports queries like “show me the chain of ownership for this subsidiary.” Building that schema is on the engineering roadmap. Until it is, structural questions of that kind require uploading the relevant document and asking against it specifically.

The system today does not proactively scan uploaded documents and generate unprompted compliance alerts. Compliance analysis runs when the user requests it. Building proactive triggers (a new document upload that contains a treaty reference automatically triggers a treaty-related compliance check) is also engineering work in progress.

Chat conversations are preserved and searchable, but they are not yet distilled into the user’s graph as persistent structured facts. If the user tells the system in chat that the company has changed its fiscal year, that statement is searchable in the conversation, but it is not yet a node in the user’s graph that future analyses can rely on. This is the next layer of accumulation, and it is not yet wired.

Coverage today is Israeli and US tax law, with the bilateral treaty between them. Other corridors are not yet served. Adding a corridor is not a matter of pointing at more documents. It requires ingesting the relevant primary authority into the system’s graph with the same structure that makes the existing graph work, building the bridges between user-side mentions and authority-side nodes, and verifying the analytical layer against test cases drawn from real practice. This is real engineering, and it is on the timeline.

What is in place today is the architecture that makes accumulation possible. Documents become structured knowledge. The user’s knowledge connects to the law. Questions reach into both at once. Compliance work draws on the same machinery. The senior professional reviews what the system has produced rather than producing it from scratch.

The memory the system builds is the actual product. The chat and the compliance reports and the opinion drafts are the outputs of that memory. What is being built is the memory itself.

---

The previous essay laid out the structural case. This one described what ktAi does when a real company brings its documents to the system. The remaining question, which neither essay can answer, is whether the architecture proves out at scale, in practice, against real client work. That answer arrives one report at a time.