Rewrite AMOS design proposal as product architecture#3
Merged
Conversation
There was a problem hiding this comment.
Pull request overview
This PR rewrites the AMOS design proposal into a comprehensive end-to-end product architecture and implementation guide, and updates the README description to match the new positioning.
Changes:
- Updated README copy to describe the design proposal as an end-to-end product architecture/build guide.
- Reworked
papers/design_proposal.texinto a product architecture document covering theory, runtime protocol, data contracts, security, deployment/ops, testing, and a phased build plan. - Added
longtableusage and updated document headers/metadata/macros to support the new structure.
Reviewed changes
Copilot reviewed 1 out of 3 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
| README.md | Updates the README’s design-proposal description to reflect the rewritten architecture guide. |
| papers/design_proposal.tex | Rewrites the design proposal into a full product architecture and implementation guide; updates formatting/macros and adds new sections/tables. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| \paragraph{Logical identity.} Objects are grouped using source-qualified logical keys issued by an owning connector. Cross-source aliases, renames, merges, and splits require explicit alias or supersession edges with authority and effective intervals. Heuristic matches may propose edges but cannot silently establish governing identity. Multiple approved mappings for the same interval produce a conflict. | ||
| Missing role coverage yields code{needs\_review} or code{reject}. Ambiguous approved metrics yield a clarification request. Conflicting owner definitions block. Insufficient token budget never silently removes policy, schema, metric, or data-state roles; it drops optional evidence first. Restricted-object counts and identifiers are not revealed to unauthorized users. |
| @@ -58,731 +60,674 @@ | |||
| \end{center} | |||
|
|
|||
| \begin{abstract} | |||
| Companies do not need another stateless analytics chatbot. They need a persistent analytical operating system that sits over the company's evolving memory, learns how the business defines and analyzes itself, and automates the complete data-analysis loop from request or signal to verified deliverable. This company memory spans data and schemas, metrics and business ontology, policies and authority, prior incidents and decisions, reviewer corrections, execution history, and output conventions. It is durable and governed outside any one model; each task receives only a bounded, permission-safe active context. | |||
| This document is the product architecture and build guide for amos. It defines the theory, system boundaries, data model, runtime protocol, component interfaces, security model, deployment topology, operating model, and phased implementation plan needed to build amos from an empty repository to a production service. The intended reader is a startup engineering team that must make the system work, operate it safely, and know when each layer is complete. | |||
|
|
||
| The durable advantage is not access to a particular model. It compounds through six assets: (1) company-specific analytical memory accumulated across years of definitions, corrections, and decisions; (2) execution history containing successful plans, failed queries, useful segmentations, and reviewer behavior; (3) governed feedback that survives the task in which it was given; (4) an analytical dependency graph linking claims, metrics, data, documents, code, decisions, and reports; (5) connectors that understand versions, permissions, schema change, and source semantics; and (6) a reliable runtime that repeats, recovers, validates, and preserves work across model upgrades. | ||
| Recency alone does not determine truth. The default authority order is owner-approved $>$ reviewer-approved $>$ user note $>$ model hypothesis $>$ untrusted external content. Effective time determines when a statement applies; recording time determines when amos learned it. Supersession edges explicitly replace one logical version with another. Conflicting owner-approved objects for the same interval block publication until resolved. |
|
|
||
| The threat model includes malicious retrieved content, malicious authorized users, compromised documents, cross-tenant index leakage, permission-revocation races, provenance expansion, multi-turn poisoning, inference through filtered results, and denial of service. Source-system compromise, aggregate inference below source-enforced privacy thresholds, and side channels outside the measured interfaces are documented residual risks. | ||
| For claim $c$, amos records edges to computations, data versions, metrics, schemas, documents, feedback, model outputs, verification records, and review decisions: |
|
|
||
| \subsection{Ideal First Customer and Initial Wedge} | ||
| An atxn record contains: |
| \newblock \emph{International Journal of Digital Curation}, 10(1):298--313, 2015. | ||
|
|
||
| \end{thebibliography} | ||
| \amos becomes a product when persistent company knowledge, model reasoning, tool execution, verification, human judgment, and artifacts are joined by one enforceable operating contract. Typed analytical memory provides durable state. The bounded context compiler supplies only valid and permitted working memory. atxn makes admission, version observation, capabilities, validation, commit, replay, and invalidation explicit. Claim dependencies make conclusions inspectable and change-aware. External enforcement keeps models useful without making them trusted authorities. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Why
The prior proposal mixed product design with research planning and did not provide a sufficiently concrete guide for a startup to build and operate AMOS end to end.
Validation
papers/