Nachricht an Herrn Dr. Andreas Auer
Hallo Andreas
Sorry dass ich den letzten Termin so kurzfristig abgesagt habe. Hatte zu diesem Zeitpunkt noch kein klares Bild wie sich Eigen entwickeln soll. Das hat sich inzwischen geändert.
Du findest Informationen über Eigen im restlichen Teil dieser Homepage. Habe allerdings neue Ideen bezüglich "deployment". Mehr dazu später.
Meine Ziele und Motivation: Ich möchte Eigen so schnell wie möglich bei Infineon verwenden und etablieren können. Allerdings ohne dass ich die Art und Weise WIE Eigen funktioniert preisgebe. Eigen wird dieses Wissen hoffentlich verbergen können (da bin ich noch am Arbeiten dran, Teil des workpackage "this week")
Das ganze soll über licensing funktionieren. Was mir wichtig ist dass Infineon unterschreibt dass das Tool mir gehört bevor ich das Tool an Infineon weitergebe.
Ich habe * tagelange screen-recordings die den Entstehungsprozess beschreiben * das wissen das tool innerhalb von einer Woche neu zu bauen * das tool ist eine mächtige Idee die ich einfach umgesetzt habe.
Ich möchte dieses Tool auch außerhalb von Infineon vermarkten.
Benefit für Infineon: Meiner Meinung nach ist Eigen dazu geeignet die AI-Infrastruktur von Infineon MASSIV zu verbessern. Kurzfristig gibt es ein Team in Bukarest mit 2-3 wirklich guten AI-Leuten das massiv von meinen Ansätzen profitieren würde. Den Flow den diese Kollegen entwickelt haben verwenden inzwischen 20-50 Ingenieure die auch sofort davon profitieren würden -> es gibt einen starken "pull" von Infineon.
Das wichtigste für mich momentan: Eine klare Regelung was ich in der Arbeitszeit machen kann und was nicht. Auch wenn es screen-recordings gibt, ist die Zeit-trennung nicht 100% gelungen. Ich kann aber nachweisen dass die IDEE während meiner privaten, in privatzeit Entstandenen Versuche mit Claude AI (gibt es bei Infineon in der Form nicht) entstanden ist.
Ich habe heute schon eine Mail an meinen Chec-Chef geschickt, mit der Bitte dass er mit Infineon-Anwalt mir eine Genehmigung für die nächsten 2 Wochen gibt an Eigen auch während der Arbeitszeit zu arbeiten. Mal schaun ob das was wird. Falls nicht verschiebt sich die timeline natürlich dementsprechend.
Bitte schau dir die proposed timeline gut an. Alles andere sind wie gesagt nur Vorschläge und ein paar Hintergrund-Informationen für dich.
Vielen Dank schonmal für die Hilfe, lg Wandad
What is Eigen?
Complex projects generate knowledge across a growing stack of disconnected tools. Requirements live in one system. Architecture decisions in another. Code in version control. Tasks in a tracker. Documentation in a wiki. Each tool is optimised for its own purpose. None of them connected. None of them queryable as a unified whole.
The cost of this fragmentation compounds over time. New team members re-learn the same knowledge graph manually. Decisions made months ago have no traceable link to the code that implements them. Work items carry titles but not the reasoning behind them.
The AI problem makes this critical. Teams deploying agentic AI are hitting the same ceiling regardless of domain: the agent can perform a task, but it does not know the context behind it. Which requirement does this address? What was decided before this code was written? What has already been tried? Every invocation starts from zero. Agents produce output that is technically correct but contextually wrong — because the context lives across five disconnected tools that no agent can navigate.
This is not a prompting problem. It is a knowledge architecture problem.
Eigen is the missing layer: a structured, cross-referenced knowledge graph that connects any project's artifacts — requirements, designs, code, tests, gaps, work items — and makes all of it navigable by both humans and agents. The domain does not matter. The pattern is universal.
The .eigen File System
An .eigen file is a plain structured document. It contains typed nodes — requirements, RTL specs, test cases, work items, agent roles — with explicit references to nodes in other files. The backend builds the full cross-file graph on load. No database. No server. No migration.
This matters for knowledge transfer in a way that databases and wikis do not.
The .eigen file is the knowledge. Not a representation of knowledge stored elsewhere — the knowledge itself, in a file you can copy, version, diff, archive, and share. When a new engineer joins the project, handing them the .eigen files is handing them the full context graph: every requirement, every RTL link, every gap analysis, every decision node, every agent role that has been trained on that codebase. Not a link to a Confluence page. Not a reading list. The actual connected graph, live and navigable on their machine from day one.
When a team reorganizes, references are relinked. When a project closes, the files are archived — and the knowledge is still there, still queryable, years later. When another team starts a similar project, they copy the relevant .eigen files and start with a populated graph instead of a blank slate.
Version control is native. Every change to the knowledge graph is a commit. Diffs are readable. History is preserved. The knowledge graph has a timeline — something no wiki or requirements tool has ever offered.
Self-Orienting Agents
The most important property of an Eigen work item is its context chain.
A context chain is an ordered list of nodes an agent reads before starting work. Instead of relying on whoever created the task to include the right context in the prompt, the agent navigates the knowledge graph itself — following the chain to understand requirements, architecture decisions, and prior work.
This changes the nature of agent work fundamentally. Agents do not need carefully engineered prompts for each task. They need a well-structured knowledge base and a clear task definition. The rest is navigation.
It also makes agent output more reliable. An agent that understands why a task needs to exist produces better results than one given only a vague specification. An agent that reads the requirement, the design, and the existing gap analysis before starting work produces output that actually closes the gap.
Self-orientation is not a prompt engineering trick. It is a knowledge architecture choice.
Your Eigen, Your Tree
This is where Eigen becomes personal.
Every engineer working with Eigen assembles their own tree — a personal .eigen file that references exactly what they need from across the organisation. Not a copy of the full project graph. Not a view filtered by a dashboard someone else configured. A structure they own and build themselves, containing precisely the nodes that matter to their work.
In practice this looks like: work items assigned to me, linked to the RTL block I own. Test gap nodes from the verification team, connected to the requirements they trace through. Trained agent roles from the shared agent library — a coverage analyst, an RTL diff reader — loaded with context from the architecture team's nodes. A sprint log that references the test cases I am responsible for closing.
All of this lives in a single personal .eigen file. The viewer renders only that tree. The agents spawned from that tree read only the context relevant to it. The engineer is not navigating a 10,000-node project graph — they are navigating their slice of it, shaped by them, for their workflow.
Skills from the verification team. Agents trained on the radar IP. Work items scoped to one block. Tracking structured the way one engineer thinks, not the way the project manager configured the Jira board.
The organisational Eigen graph is the shared foundation. Each engineer's personal tree is a living view on top of it — composable, version-controlled, and entirely their own.
Agent Orchestration
Eigen includes a structured orchestration concept for running multi-agent workflows. This layer — defining how agents collaborate, hand off work, and reach consensus before advancing — is designed and partially implemented. It is not yet production-ready.
What is already available: pre-trained agent roles with a defined training procedure. Agents can be trained on a specific domain and knowledge base, checkpointed, and forked for new tasks without retraining from scratch. This is functional and in use.
Proposed Timeline
Under the assumption the agreement is signed today, my proposed timeline and work-split would look as follows.
Week 1 — Preparation
Bring Eigen to a state I am comfortable handing over: documentation complete, KB structure cleaned up, deployment straightforward.
Week 2 — Integration
Integrate into the Infineon toolchain. This includes adapting the agent layer to work alongside GitHub Copilot and aligning with existing Git and Jama workflows.
Weeks 3–4 — Training and Migration
Thorough onboarding with the Bucharest team. Walk them through the system, demonstrate the benefits on their own material, and support the migration of their existing tooling into Eigen.
In parallel — Evoli Showcase
While the Bucharest onboarding runs, I develop a live Eigen showcase for Evoli (the radar project currently starting up), built around my own work packages. This demonstrates that the pattern generalises beyond chip verification immediately.
Decision Point
After these four weeks, we review what is working, what needs adjustment, and decide how to continue.
Throughout this period, my Evoli deliverables remain unaffected. The integration and training work is structured so it does not compete with ongoing project commitments.
Current State
Eigen is a working prototype under active development. The KB format, backend, visualizer, and spawn system are functional and in use. The orchestration layer — structured agent roles, checkpointing, and task lifecycle management — is designed and partially implemented.
The knowledge base you are currently reading is itself a live Eigen instance. The tool being used to navigate it is the tool being evaluated.
Licensing
IP Ownership and Provenance
Eigen is the sole intellectual property of its creator. It was developed entirely on personal time, using personal hardware — a private computer not connected to any employer's systems. Eigen has never resided on Infineon systems. Documented proof of this provenance exists and is available to legal counsel on both sides.
This is stated as a legal fact, not a negotiating position. Any formal agreement will reflect it.
Evaluation License Terms
A preliminary evaluation license grants:
- The right to run Eigen on two designated project within the licensee's organization for a defined evaluation period (proposed: 30 days, renewable by mutual agreement)
- Access to the Eigen viewer, backend, and orchestration runtime for internal evaluation only
- The right to assess Eigen's suitability for broader deployment
The evaluation license explicitly preserves:
- Full IP ownership by the creator — no transfer, assignment, or implied license beyond the evaluation scope
- Mutual confidentiality obligations: no disclosure of Eigen internals, source code, or project-specific data to third parties
- No sublicense rights — the evaluation is limited to the specified project and team
- No implied acquisition right, right of first refusal, or ongoing obligation — commercial terms are negotiated separately after evaluation concludes
Working-Time Arrangement
Any formal agreement must include explicit contractual language distinguishing Eigen development time from employment obligations. The creator intends to continue employment at Infineon while developing Eigen. Clear boundaries eliminate any basis for future IP disputes arising from ambiguous working hours. This is a standard protective clause that benefits both parties — not an unusual request.
These terms are a framework for a clean legal foundation during a technical evaluation. Questions should be directed through the contact channel below.
Contact
This knowledge base is a private, password-protected evaluation preview. Access was extended to you deliberately.
Reaching Out
Contact is available through the channel through which you received access to this site. Please use it to:
- Schedule a live demonstration on the IBEX RISC-V reference core or on a domain relevant to your organization
- Discuss evaluation license terms or request a formal license draft
- Ask technical questions about the system architecture or the .eigen format
- Establish the working-time arrangement language for any formal agreement
Legal Status
Both the creator's legal counsel and Infineon's legal team have been engaged. This site is part of a deliberate, controlled communication process. Correspondence through this channel is treated accordingly.
Confidentiality
This preview is confidential. Do not share access credentials, forward this URL, or distribute content from this knowledge base to parties not part of this evaluation.