01
Teams remember what, then lose why
The final choice may survive while its trade-offs, rejected options, and evidence remain scattered across several tools.
Decision history in private development
Ask why the plan changed. Follow the decision history.
Skron is being built for the moment after a plan changes: trace the original decision, the exception, and the work that followed across selected company sources.
The product is not publicly available yet. This page describes the direction and the requirements we intend to meet, not a finished feature list or a public trial.
Company memory
Illustrative product direction
Example question
Why did we change the rollout plan, and what still needs a decision?
Answer with evidence
Skron would separate the current decision from earlier assumptions, note what remains unresolved, and attach each statement to the original work. This illustration shows the intended answer structure, not a live product response.
Current fact
Summarized from the latest approved decision and its follow-up work.
Still unresolved
Shown separately instead of being presented as a settled conclusion.
Sources used
Approved decision · original source
Follow-up work · original source
- Ingestion
- Selected
- An admin chooses sources and history depth
- Evidence
- Cited
- Claims should link back to the original work
- Access
- Inherited
- Answers must stay inside the viewer's source access
The problem
The decision survives. The reasoning gets lost.
A rollout decision can begin in a meeting, change in an issue, and be corrected by a support case. Search finds each piece, but rarely explains which conclusion applies today or why the plan changed.
02
The latest file is not always the latest truth
A document records the plan, but an issue or later discussion records the exception. Reading only one produces a confident but incomplete answer.
03
Every handoff starts with archaeology
New teammates repeat investigations because they do not know the vocabulary, people, or sequence of changes needed to find the original context.
Planned workflow
A decision history should preserve the path, not only the summary.
The intended flow begins with deliberate scope and ends with a source a person can inspect. The product should not silently copy everything and ask the model to make sense of it later.
- 01
Choose what belongs in the memory
An admin chooses repositories, spaces, projects, channels, and history depth. The default is a useful boundary, not every item the company has ever produced.
- 02
Connect work without flattening its history
Skron should preserve dates, authors, links, state changes, and relationships so an answer can distinguish the original plan from what happened later.
- 03
Ask across the permitted memory
A person asks in normal language. Retrieval should combine exact terms, semantic matches, related entities, and the timeline needed for the question.
- 04
Read the answer, then inspect the evidence
The answer separates supported facts from open questions and links each important claim to the material available to that person.
Selected sources, not a new dumping ground
Keep the decision trail attached to the work.
Skron is not meant to replace the systems where work happens. The original source remains the place to read, edit, and govern that work. The planned memory layer connects selected material so a question can follow a changed decision across tools and over time.
What the team built
Follow how a technical or product decision moved from proposal to implementation.
- repositories and change history
- reviews and pull requests
- issues and delivery notes
What the team explained
Keep the written rationale close enough to the resulting work to make both easier to understand.
- wikis and product documents
- research and specifications
- architecture and design records
What the team learned
Bring in the evidence that changed the plan without treating every chat message as permanent company memory.
- selected discussion context
- feedback and investigation notes
- incident and support findings
Admins should choose the sources, scope, and history depth. Full-history chat ingestion is not the default product direction.
Requirements before launch
A decision history must show what changed.
Permission-aware search and citations are baseline expectations in this category. For Skron, they are launch requirements. A polished answer is not useful if a person cannot inspect its basis or if the system crosses an access boundary.
Access is enforced before an answer is composed
Retrieval and the final answer must respect the access a person has in the connected source. Content outside that scope must not influence the response.
Citations lead to the original work
A reader should be able to open the document, change, issue, or selected discussion that supports a claim and judge it in context.
Uncertainty is part of the answer
Conflicting sources, missing context, and unresolved questions should remain visible. Skron should not turn an incomplete record into false certainty.
Questions worth answering
Start with the question behind the change.
The useful unit is not a generic summary. It is a question that normally requires someone to reconstruct a sequence of decisions across several sources.
- “Why did we choose this architecture over the alternatives?”
- “Which customer reports changed the scope of this feature?”
- “What did we already learn from the last failed rollout?”
- “Where does the current policy contradict older documentation?”
Current status
Skron is in private development.
We are validating the retrieval, access, traceability, and operating model before presenting Skron as an available service. Connector names, plans, and dates will be published only when they are real commitments.
- No public account, trial, or production workspace is available today.
- The old Git-hosting demo is not the current Skron product direction.
- This page will change as product decisions become implemented and verifiable.
- The public product will run on Cloudflare infrastructure for resilient access and protection against abusive traffic.
