Does the implementation preserve the requirement?
Start with the recorded intention and inspect the relevant behavior, including conditions and computed values. Similar names are not enough to establish a match.
AI & IT startup in formation
Understand
your business.
Shape what
comes next.
AI for decisions you can explain. Y-Knowledge connects what a system should do, what has been implemented and the evidence behind it.
Know where the implementation differs. See which questions remain open. Check whether the evidence belongs to the version in front of you. Built on AKDB’s developing knowledge and review tools.
Photo: Headway / Unsplash
A concrete use case. A result you can assess.Read on ↓
01 / The business perspective
Less reconstruction.
A clearer basis to act.
A document says what was intended. Code shows what was built. A test records what was checked. The useful question is whether those three still belong together.
When these pieces drift apart, people repeat investigations, debate old assumptions or rely on checks from a different version. Our aim is to help teams investigate those gaps before they become avoidable rework.
We compare the current effort with a scoped evaluation. Time recovered is capacity, not automatically profit. Setup, review, software and ongoing support all belong in the calculation.
01
The intent
What was meant to happen?
A recorded requirement: existing customers must still be able to use the original sign-in path.
02
The implementation
What does the inspected code do?
Compare the relevant behavior and conditions with the requirement. Leave uninspected areas explicitly open.
03
The evidence
Was this exact version checked?
Bind the result to the version assessed. An earlier passing test does not automatically prove the new delivery.
People make the decision. The basis becomes traceable.
Illustrative review workflow, not a product interface or measured customer result. Suitable components must be qualified before an evaluation.
Explore the technical foundation ↗02 / A practical example
The requirement stayed.
Did the behavior?
A portal gains a new sign-in flow. The requirement still protects an older customer path. Your team needs to check whether the changed implementation preserves that behavior—and whether the test evidence covers this version.
Illustrative scenario, not a client case study.
Follow the full storyCompare what was intended with what was inspected.
AKDB includes a bounded comparison of reviewed behavior. It can distinguish a mismatch from an unresolved comparison. This is not a claim to understand every possible program behavior.
Check the evidence belongs to this delivery.
The acceptance checks bind judgments to exact assessed inputs and delivery evidence. Your reviewer decides what follows; an old green result is not automatically valid for a new version.
Did the review reduce reconstruction and rework?
Compare time spent, answer quality and the effort needed to keep the knowledge current. Continued use needs to make sense against its full cost.
03 / Working together
One project.
A measured start.
Our proposed entry is a bounded evaluation of one software-change case. Suitability, source access, assessment criteria, timing and fees must be agreed before work begins.
Define a worthwhile use case.
Where does missing context cost your team time?
We start with a real task and the people doing it. Together, we identify the relevant sources, record the current effort and agree what a useful result would look like.
Your outcomeA scoped use case, an effort baseline and agreed questions to test.
Evaluate it in your project.
Does the result justify the effort?
A proposed evaluation uses agreed sources and questions. Your team checks answers, source versions and corrections. We compare preparation and review effort with the baseline, including gaps, errors and maintenance. Unsuitable cases stop under criteria agreed in advance.
Your outcomeDocumented findings, remaining limitations and a comparison with the current way of working.
Decide what to take forward.
What would continued use require?
If the evaluation supports it, we define the next scope, operating requirements and ongoing support. Adoption depends on demonstrated value and a suitable product stage, not on completing a demo.
Your outcomeA decision to continue, adapt or stop, with responsibilities and follow-on costs made explicit.
04 / Our principles
Technology opens possibilities.
Responsibility stays human.
People need to understand the basis of a recommendation and the potential consequences of a decision.
Sources, reasoning and open questions therefore belong in the working context. AI can help discover, connect and organise information. People retain responsibility for objectives, professional judgement and consequential approvals.
New tools are introduced where they serve the task. Existing systems, control over data and the requirements of those involved define the boundaries.
Knowledge & provenance
AKDB
Keep sources, relationships, rules and decisions traceable.
Coordination
ContextOps
Coordinate work with bounded responsibilities, handovers and recovery.
Authorised execution
Tools & people
Work within the approved scope and return results for review.
Results, evidence and new understanding
Simplified model of the development approach. AKDB is an engineering preview; this diagram does not represent a finished, integrated product.
05 / Foundations & development
From a knowledge core.
Towards a working tool.
A technical foundation exists. Customer value still needs to be demonstrated. We keep those two things separate.
Make knowledge
useful together.
Understanding should last beyond individual projects and people. It needs to be documented clearly, connected to its sources and open to improvement through everyday work.
Y-Knowledge combines project work with reusable software. The proposed commercial model is a paid, scoped evaluation followed by separately agreed software use and support where the results justify it.
Y-Knowledge is being developed as an independent venture intended for a shared founding team. The company has not yet been legally incorporated.
A working foundation, with clear limits.
Active AKDB development now includes reviewed behavior comparison, source-bound acceptance checks and controlled registration of existing decisions. These implemented components support a more substantial evaluation than search alone. AKDB remains an engineering preview; a complete service and customer outcomes need separate qualification.
Explore the product foundationMade for people, as well as AI tools.
Human-readable results now sit alongside machine-readable records. Native workspace development has also progressed to visible local owner setup and protected access configuration. The direction is a tool people can operate—not a requirement to work through raw data.
Recorded component and local-candidate evidence. Integrated operation and physical-device qualification remain separate; this is not a promise of availability on every device.
06 / Public development record
See what is taking shape.
Explore the technical foundations behind the approach: what the tools do, how they have developed and where their limits stand.
Public documentation, not open-source software. The repository contains descriptions and illustrative examples; the implementation remains proprietary.
Documented position: Repository checked:
Capabilities & maturity
- AKDB · 0.5.0Engineering preview
- Connect decisions, models and sources; assemble task-specific context; inspect change impact and dated diagnostics.
- ContextOpsInternal implementation · unreleased
- Coordinate bounded agent work through external hosts, time-limited work claims, execution records and evidence checks.
- Agent Collaboration PlaneRead layer implemented
- Give different MCP clients access to project knowledge. The wider collaboration model is only partly built.
- Documentation pipelineIn internal use
- Derive published documents from maintained records, with checks for traceability and drift.
Implementation evidence comes from internal and synthetic environments. Customer validation and general production readiness have not yet been demonstrated. Read this snapshot ↗
A dated record of development.
Selected public documentation snapshots, newest first. Dates identify published records, not first availability or production release dates.
0.5.0 · Diagnostics & delivery trace
Dated system observations, links from approved plans to delivered changes, declared impact and proposed remedies extend the knowledge and governance foundation. The public record also describes a container deployment path for the external Agent Host.
Read this snapshot0.4.0 · Models & temporal memory
The record adds project-isolated SysML v2 histories, stakeholder views, assurance cases, time-aware task and plan memory, governed connectors and a PostgreSQL-first operating model.
Read this snapshot0.3.0 baseline · Supervised change
The public status describes a governed pilot path for agent changes, append-only knowledge revisions, recovery evidence and packaging controls. These additions are described as internal implementation beyond the packaged baseline.
Read this snapshotThe first public showcase
The initial public description sets out source-linked architecture knowledge, task-specific context, stale-knowledge signals and change-impact reviews. It does not establish a production release.
Read this snapshot
This is an editorial snapshot, not a live feed. Follow the repository for subsequent changes.
Before we speak
Useful to know.
When is Y-Knowledge relevant?
Our proposed starting point is software vendors and IT-services teams changing existing systems. The question is whether clearer sources and decisions help with an estimate, a handover or a release review. This is an entry hypothesis, not a limit on the company’s future scope.
Is this a ready-to-use software service?
Not yet. AKDB is an engineering preview with separate release and development stages. Source inspection is a possible evaluation subject; complete impact analysis, automatic gap repair and active external integrations are not promised. Operating scope and service commitments need separate qualification.
How does a collaboration start?
Start with a concrete project and the question your team struggles to answer. We discuss what could be tested, what evidence would matter and whether a scoped evaluation is appropriate. There is no assumed subscription or follow-on commitment.
How is confidential information handled?
Before processing any information, we agree what data is needed, who can access it and which environment is appropriate. Neither AI use nor transfer to additional services is assumed.
Let’s start a conversation.
What is your next
change project?
Tell us what you want to change, where context is missing and what a useful result would be. That is enough to begin a focused conversation.
Discuss your project contact@y-knowledge.comInterested in co-founding or a strategic partnership? Explore how we could build together