Sig synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
From a meeting account to private memory
Sig describes a desktop context layer that turns a user's work accounts into private notes and selectively shared team knowledge. This analysis covers the public sig-ai-app/sig-releases repository at commit 314bbea9d1cef911cea0f201eec66a57c2e59020, with an applicability cutoff of 2026-10-14. The evidence is release documentation, product claims and issue-form definitions: SRC-1, README.md, RELEASE_NOTES_v0.1.0-beta.md, ANALYTICS.md and the tracked support forms. The complete tracked text was inspected, but the application implementation, shipped prompts, evaluators and release binaries are unavailable within this frozen source. The boundary is therefore a complete artifact, partial loop, not a whole-system implementation review. No execution trace or causal experiment was supplied (boundary, Source register).
The representative workflow is the explicitly connected meeting capture → private synthesis → organizational draft → human approval → team publication → teammate context sequence. It is not reconstructed by joining unrelated capabilities. The user supplies raw narrative, shorthand and observations. Sig is said to structure that input into a factual record and a separate personal interpretation. The declared durable result is plain markdown in the folder selected during setup (RT-RTE-capture-share, MEM-OBJ-factual-record, MEM-OBJ-personal-layer, workflow account).
This split distinguishes two content roles and their intended visibility. It does not establish two separate files, a formal schema or a truth check. The factual label names the product's intended output, not verified facts. Without concrete inputs, outputs or transformation rules, neither private synthesis nor organizational drafting can be classified as faithful reshaping, checked derivation or a specific conjecture. Imported meeting reports retain unknown source warrant. Starting capture also does not establish the user's approval of every local write (EPI-CLM-factual-layer, EPI-RTE-private-synthesis, EPI-RTE-org-draft).
From private notes to approved organizational content
Sig next prepares a clean organizational version. The human decides what to include, reviews the exact proposed text and clicks send. This is the discriminating admission boundary: private retention can precede approval, while team publication is declared to require a per-content human decision. The proposal and the published team object are distinct; the documents do not establish that their text is unchanged across human selection (EPI-OBJ-org-version, EPI-RTE-share-approval, MEM-OBJ-team-knowledge).
The decision licenses publication, not evidence-consuming acceptance of the meeting claims against a named truth criterion. Withholding approval is a declared veto on the share, not documented rollback of the private note. The gate is a policy claim rather than an inspected invariant. No observed review, executable enforcement point or bypass inventory establishes that it operates as promised. Git is the named background synchronization mechanism; recipient admission, merge conflicts, completion acknowledgment and remote withdrawal remain unresolved (RT-CLM-private-sharing, RT-RTE-capture-share).
The workflow's owners are the human for narrative and publication permission, Sig for structuring and proposal preparation, and git for declared synchronization. This is not established agent-to-agent delegation. There are no disclosed worker contexts, task-return contracts or recovery coordinator. Local note creation and team-context availability are separate delivery milestones; a review-ready draft is not team delivery, and clicking send is not evidence of completed synchronization (workflow account).
From retained material to later use
The strongest supported contribution is a declared design for accumulating inspectable work context while separating private interpretation from deliberately shared organizational text. Users are explicitly allowed to open, copy or delete their local files. Uninstalling Sig leaves captures behind. Those controls give a documentary human-reference path and retention horizon; they do not establish that external edits are adopted by Sig or that deletion retracts remote and cached copies (MEM-OBJ-factual-record, EPI-RTE-local-deletion).
The README claims that team knowledge reaches a teammate's Sig as context immediately and that private history makes later AI work more informed. The actual request boundary, selector inputs, selected portions, token budget and final model-visible payload are not disclosed. Synchronized availability therefore establishes neither automatic context injection nor requested retrieval. Intended advisory context is not demonstrated behavioral influence or correctness. The independently verified memory classifications preserve that distinction: positive findings remain claimed, and unresolved AI read-back and admission paths are not converted into complete inventories or bounded negatives (EPI-RTE-context-use, profile verification).
A separate documented route sends the user's messages directly from Sig to a chosen AI provider, using credentials held in the OS keychain. The source identifies provider families, not pinned model versions. It does not establish that synthesis uses this same route, what retained context any request contains, or whether the personal layer enters provider payloads. Local retention and exclusion from team sharing are consequently not proof of personal-layer network confinement (RT-RTE-provider-message, RT-CMP-ai-provider, RT-CLM-provider-direct).
Reusable skills are advertised as team-shared workflows for recurring tasks, with the same hidden git layer. No skill bodies, loader, execution permissions, recipient activation or revision mechanism are supplied. Distribution is not execution, and a workflow label cannot establish instruction encoding or trace-derived learning (RT-OBJ-skills, RT-RTE-skill-sync).
Separate outbound paths and improvement claims
Team approval does not mediate every outbound path. Provider requests are separate. Analytics is described as automatic usage and crash reporting to PostHog Cloud EU, with allowlist filtering and sanitization claimed before egress. Explicit feedback comments send their text, and there is no current in-app analytics-off toggle. A random install ID groups events from one installation; resetting it is not deletion of earlier events. These policies are not inspected filtering or backend guarantees (RT-RTE-analytics-egress, RT-CLM-telemetry-filter, MEM-OBJ-install-id).
Inspectable public issue forms afford structured product feedback and request a human privacy attestation. They do not adjudicate a diagnosis or admit a product revision. Neither those forms nor diagnostic success counts establish a feedback → accepted repair → later changed application-behavior loop (RT-RTE-product-feedback).
Accumulated context is the supported design contribution; improved future capacity remains unresolved. The advertised claim that months of history make AI “dramatically sharper” has no supplied baseline, task metric, intervention or result comparison. There is no demonstrated learning benefit or component-level causal attribution. Trace-fed learning also remains independently unresolved: automatic admission, qualifying original trace content and a durable later-consumed update chain are not established. This is not evidence that such routes are absent (EPI-CLM-context-payoff, profile verification).
Theory-building, reflection, autonomy and self-improvement remain separate unestablished properties, not a single negative grade. The accepted runtime account discloses no accepted theory or criticism-and-revision loop; the epistemic account does not establish a model update, reflective causal loop or autonomous theory building. At this documentary boundary, no exercised evidence-responsive change to Sig's own behavior-determining organization and subsequent operation depending on that change is shown. Shared skills, accumulated notes and telemetry alone do not establish self-improvement (runtime change admission, epistemic conclusion).
For the scenario of retaining a meeting account and choosing what colleagues may receive, the documentation supplies a coherent separation of private retention, organizational proposal and human publication permission. For scenarios requiring validated factual knowledge, guaranteed privacy enforcement, reliable synchronization or improved downstream answers, the same evidence cannot settle the assessment. Inspectable transformation and gate code would change the architectural account; input/output and payload traces would establish bounded operation and actual consumed context; recovery and retraction traces would clarify delivery and withdrawal; controlled outcome comparisons would address benefit, with attribution no finer than the tested contrast. Independent report and profile verification found no blockers or additional declared limits, but neither judgment closes the application evidence gap (report verification, profile verification).
Source-read log: none. This synthesis uses the supplied accepted members and adds no source evidence.
Limitations
| Limitation | Affected SRC IDs and record citations | Inspected boundary | Conclusion prevented | Evidence that would resolve it |
|---|---|---|---|---|
| Release artifact is not the application loop | SRC-1; boundary, RT-RTE-capture-share | All tracked text at the reviewed commit; binaries, operational prompts and app code unavailable; screenshots not visually inspected | Whole-system implementation coverage, actual activation, enforcement or reliability | Frozen application code and shipped operational content covering producers, admission and consumers; execution evidence for operation |
| Private and organizational transformation semantics are unknown | SRC-1; EPI-RTE-private-synthesis, EPI-RTE-org-draft, MEM-OBJ-factual-record, MEM-OBJ-personal-layer | Documentary capture/synthesis contract; no concrete content instance or evaluator | Factual accuracy, semantic fidelity, derivation or conjecture classification, complete provenance and retained reasons; local admission control | Prompts/code, paired capture and outputs with provenance, local admission rules, and evidence-consuming checking decisions |
| Publication approval and team delivery are only declared | SRC-1; EPI-RTE-share-approval, MEM-OBJ-team-knowledge, RT-CLM-private-sharing | Exact-text review and git-sync documentation | Inspected gate enforcement, truth acceptance, recipient trust, consistency or successful delivery | Gate implementation and alternate paths, review/send/sync traces, recipient admission and conflict protocols; separate truth criterion and decision evidence for truth acceptance |
| Later AI consumption is opaque | SRC-1; EPI-RTE-context-use, RT-RTE-provider-message, RT-CMP-ai-provider | Claimed private/team context and direct provider channel | AI pull/push classification, selector and budget guarantees, exact consumed content, personal-layer provider exclusion and reproducibility | Context assembly rules and model-visible request traces, private-layer filtering, pinned model and endpoint contracts |
| Skills and optional acquisition/maintenance paths remain unresolved | SRC-1; RT-OBJ-skills, RT-RTE-skill-sync, RT-RTE-capture-share | Skill-sharing claims and integration labels; no loader, bodies, Slack/voice content path, end-of-day or compaction protocol | Complete memory-loop inventory, execution authority, classified curation, qualifying trace-fed learning or its bounded absence | Skill bodies, admission/revision and loading code, integration-to-retention-to-consumer routes, original trace inputs and update controls |
| Local controls do not establish propagated withdrawal or recovery | SRC-1; EPI-RTE-local-deletion, MEM-OBJ-team-knowledge, RT-RTE-capture-share | File deletion and uninstall-retention documentation; workflow failure handling unspecified | External-edit adoption, remote retraction, cache invalidation, retries, rollback or dependable resumption | Reload/invalidation implementation, deletion propagation and conflict/recovery protocols with bounded traces |
| Outbound privacy and diagnostics-to-change paths are unverified | SRC-1; RT-CLM-provider-direct, RT-CLM-telemetry-filter, MEM-OBJ-install-id, RT-RTE-product-feedback | Provider/analytics policies and inspectable issue forms; external services not frozen | Universal approval-before-egress, provider confidentiality, sanitizer completeness, backend regional/retention guarantees, or admitted repair from diagnostic intake | Transport/filter code and payload traces, external service contracts/audits, retained acceptance and release records linking feedback to later behavior |
| Benefit and improvement mechanisms lack comparison and operative-update evidence | SRC-1; EPI-CLM-context-payoff, RT-RTE-skill-sync, RT-RTE-analytics-egress, profile verification | Claimed accumulating context and diagnostic intake; no observed run or experiment | Improved future capacity, causal context benefit, theory criticism improving action, reflection, autonomous theory building or exercised self-improvement | Retained theory/criticism and update-consumer evidence for the respective properties; objective-linked changes and later dependent operation for self-improvement; controlled task comparisons for successful benefit |